Outbound SIP registrations are a commonly used practice in Asterisk. They allow an upstream server, such as one in use by an ITSP, to know where you are and to route calls to you. This is easy to configure and see in practice. Where many people have difficulty though is identifying calls from that upstream server. This is important to do as it allows you to restrict what you allow accessible to the outside world. In res_pjsip this operation is called “endpoint identification”. Given an incoming message identify who they are and what endpoint is associated with them. Every message received by res_pjsip goes through this, none are spared. Traditionally what has been done in both chan_sip and res_pjsip is that the source IP address of the incoming message is used to determine who they are. For a single upstream server this works fine but an ITSP might have multiple servers spanning many IP addresses.
In the case of chan_sip you’d have to do something like:
[inbound-configuration](!) type=peer context=incoming-itsp disallow=all allow=ulaw insecure=host,port [inbound1](inbound-configuration) host=94.100.23.82 [inbound2](inbound-configuration) host=94.100.23.83 [inbound3](inbound-configuration) host=94.100.23.84 [inbound4](inbound-configuration) host=94.100.23.85 [inbound5](inbound-configuration) host=94.100.23.86
For res_pjsip this has been improved to allow subnet masks:
[itsp] type=endpoint disallow=all allow=ulaw context=incoming-itsp [itsp] type=identify match=94.100.23.82/29
However if your ITSP adds servers in other regions with different IP addressing and you don’t keep track you may find that a subset of your calls are not able to be received.
The “line” option to outbound registrations in res_pjsip helps to eliminate this in some cases.
Take a look at the following registration:
REGISTER sip:5201@axion.jcn-network.com:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.1.11:5060;rport;branch=z9hG4bKPj584c63bb-274d-4569-8dfb-019c97acfcd1 From: <sip:blah@10.24.18.124>;tag=e2ba7a2b-fef5-4327-89fe-6a45054b158d To: <sip:blah@10.24.18.124> Call-ID: 488377c5-7972-44d4-9a20-587bb9d71566 CSeq: 37098 REGISTER Contact: <sip:s@172.16.1.11:5060> Expires: 60 Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER, REGISTER Max-Forwards: 70 User-Agent: Asterisk PBX GIT-13-fcb6c17M Content-Length: 0
As you can see it’s pretty normal. It’s talking to axion.jcn-network.com and adding a Contact of ‘sip:s@172.16.1.11:5060’ to AOR ‘5201’.
With line support enabled the registration turns into the following:
REGISTER sip:5201@axion.jcn-network.com:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.1.11:5060;rport;branch=z9hG4bKPj2de354fa-afa5-44cc-8438-857f4648edf3 From: <sip:blah@10.24.18.124>;tag=fba0eb38-f38c-4370-ad5e-0cb5d6a8db75 To: <sip:blah@10.24.18.124> Call-ID: efccf504-5a86-4959-93d3-eb4b7ae2c3ac CSeq: 43666 REGISTER Contact: <sip:s@172.16.1.11:5060;line=vqqgygs> Expires: 60 Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER, REGISTER Max-Forwards: 70 User-Agent: Asterisk PBX GIT-13-fcb6c17M Content-Length: 0
A new parameter is added to the Contact: line=vqqgygs. This is important because the remote server is supposed to call us using the Contact we provide to them. Therefore if they send us a call and preserve the parameter we are able to establish a relationship between an incoming call and the outbound registration. This eliminates any need for IP based matching.
So how do you configure it? Pretty easily, actually. The following options can be added to an outbound registration (type=registration section) to enable line support.
line=yes endpoint=<name of endpoint to use for incoming calls>
If your upstream server preserves the line information then any incoming calls will be automatically identified as the provided endpoint. No extra work required! If they don’t preserve it I’m afraid you will have to use the IP based matching mechanism. While servers are supposed to preserve the information not all do.
