[asterisk-dev] PJSIP_AOR and PJSIP_CONTACT Dialplan Functions

Mon Dec 29 11:20:04 CST 2014

Matthew Jordan wrote:

<snip>

>
> If we have to define multiple endpoint definitions, then the usefulness
> of having multiple contacts bound to an AoR diminishes substantially. It
> may be that people are confusing the concept of a device with that of a
> user profile - but if that's the case, then I'm not sure why I would
> ever want to bother with multiple contacts on an AoR.

It depends on how you use things and how you need to address them, it's 
environment and use case specific. Personally I don't need to know if 
what I'm dialing is available. I send it to everything.

> Regardless, I'm wondering if we aren't excluding the simple case due to
> outliers.
>
> Say, for example, I have the following configuration:
>
> [aor-multiple-template](!)
> type=aor
> support_path=yes
> max_contacts=10
>
> [auth-basic-template](!)
> type=auth
> auth_type=userpass
>
> [endpoint-basic-template](!)
> type=endpoint
> context=default
> allow=!all,g722,ulaw,alaw,gsm
> ice_support=yes
>
> [alice](aor-multiple-template)
>
> [alice](auth-basic-template)
> username=alice
> password=alice
>
> [alice](endpoint-basic-template)
> callerid=Alice <1000>
> aors=alice
> auth=alice
>
> And let's say I have two phones that are sending REGISTER requests as
> "alice". As an example:
>
> <--- Received SIP request (837 bytes) from UDP:10.24.19.55:5060
> <http://10.24.19.55:5060> --->
> REGISTER sip:10.24.16.171:5060 <http://10.24.16.171:5060> SIP/2.0
> Via: SIP/2.0/UDP
> 10.24.19.55:5060;rport;branch=z9hG4bKPj7-14slYhyfi45xtar3q7VBUbSsm4pUXK
> Max-Forwards: 70
> From: "Alice" <sip:alice at 10.24.16.171
> <mailto:sip%3Aalice at 10.24.16.171>>;tag=4C7yY1pu6qOjZEp.-IReIZaUgqOy7uGI
> To: "Alice" <sip:alice at 10.24.16.171 <mailto:sip%3Aalice at 10.24.16.171>>
> Call-ID: 0TUzqDV9dXHdkCvsi5SFRMQ7cQE7KhEZ
> CSeq: 25921 REGISTER
> User-Agent: Digium D40
> Contact: "Alice" <sip:alice at 10.24.19.55:5060;ob>
> Expires: 300
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
> REFER, MESSAGE, OPTIONS
> Authorization: Digest username="alice", realm="asterisk",
> nonce="1419871835/cfd27346038b4c30606ae6678141c047",
> uri="sip:10.24.16.171:5060 <http://10.24.16.171:5060>",
> response="8744d3d86786048a551cb45916e683b6", algorithm=md5,
> cnonce="UCHty95Pp6K80bq8Yjp-AikA0ZJ5Nsk8", opaque="357ef62640b1d668",
> qop=auth, nc=00000001
> Content-Length:  0
>
> Sure, I only have a single endpoint defined, but since I "know" that
> both of these endpoints are going to support a subset of the codecs that
> are configured on my endpoint definition, that's really immaterial.
>
> Once both have registered, I have the following aor for Alice:
>
>        Aor: <Aor..............................................> <MaxContact>
>      Contact: <Aor/ContactUri.................................>
> <Status....> <RTT(ms)..>
>   =========================================================================================
>
>        Aor:  alice                                               10
>      Contact:  alice/sip:alice at 10.24.19.55:5060;ob
> Unknown               nan
>      Contact:  alice/sip:alice at 10.24.19.80:5060;ob
> Unknown               nan
>
>
>   ParameterName        : ParameterValue
>   ====================================================
>   authenticate_qualify : false
>   contact              : sip:alice at 10.24.19.55:5060;ob
>   contact              : sip:alice at 10.24.19.80:5060;ob
>   default_expiration   : 3600
>   mailboxes            :
>   max_contacts         : 10
>   maximum_expiration   : 7200
>   minimum_expiration   : 60
>   outbound_proxy       :
>   qualify_frequency    : 0
>   remove_existing      : false
>   support_path         : true
>
>
> What does this look like when one of them sends an inbound INVITE
> request to Asterisk?
>
> <--- Received SIP request (1357 bytes) from UDP:10.24.19.55:5060
> <http://10.24.19.55:5060> --->
> INVITE sip:1000 at 10.24.16.171 <mailto:sip%3A1000 at 10.24.16.171> SIP/2.0
> Via: SIP/2.0/UDP
> 10.24.19.55:5060;rport;branch=z9hG4bKPj0kj1kgnhZ72XiDvrxVw9ciYhHkod5WC8
> Max-Forwards: 70
> From: "Alice" <sip:alice at 10.24.16.171
> <mailto:sip%3Aalice at 10.24.16.171>>;tag=a32sglRf96mIv0HiCCBLiuGqiKetDeXK
> To: <sip:1000 at 10.24.16.171 <mailto:sip%3A1000 at 10.24.16.171>>
> Contact: "Alice" <sip:alice at 10.24.19.55:5060;ob>
> Call-ID: b2h.6IW7ZB7bHV48UgjZF9NcpAfFEIZB
> CSeq: 19647 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
> REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800
> Min-SE: 90
> User-Agent: Digium D40
> Authorization: Digest username="alice", realm="asterisk",
> nonce="1419871992/a8c7a8e171e37ca8a6a85a6a0dc10eb1",
> uri="sip:1000 at 10.24.16.171 <mailto:sip%3A1000 at 10.24.16.171>",
> response="42dbbf0d040bbad82d32ae2823d483bd", algorithm=md5,
> cnonce="VrrCt1ULwaThKD9CGh73WhXNqFA-Rxvh", opaque="6e13a13a61a99a6f",
> qop=auth, nc=00000001
> Content-Type: application/sdp
> Content-Length:   430
>
> v=0
> o=- 115243281 115243281 IN IP4 10.24.19.55
> s=digphn
> c=IN IP4 10.24.19.55
> t=0 0
> a=X-nat:0
> m=audio 4028 RTP/AVP 0 8 9 111 18 58 118 58 96
> a=rtcp:4029 IN IP4 10.24.19.55
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:111 G726-32/8000
> a=rtpmap:18 G729/8000
> a=rtpmap:58 L16/16000
> a=rtpmap:118 L16/8000
> a=rtpmap:58 L16-256/16000
> a=sendrecv
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-15
>
>
> Note that my Contact header in the received INVITE request does match
> the Contact header used by the phone to REGISTER.

That's dependent on the environment and SIP implementation. If you strip 
out user parameters from your comparison and treat it strictly user+IP 
address+port you get closer. For example my X-Lite gives this on a REGISTER:

Contact: <sip:blink at 172.16.1.165:21276;rinstance=b94f74903a174265>

While a call gives:

Contact: <sip:blink at 172.16.1.165:21276>

>
> Does it have to? No, a SIP ALG could have "helped me". If NAT was being
> used, we could have multiple Contact headers with the same private IP
> address being used by multiple phones (although in that case, it feels
> like what would be stored in the AOR would be the received IP address,
> and not the address in the Contact anyway).

Not even a SIP ALG. If you are going through NAT the source IP 
address+port of subsequent traffic may differ from the REGISTER 
(although the source IP address+port of the REGISTER may/will still be 
valid).

>
> In basic scenarios, however, we do have a match between the inbound
> Contact header in the INVITE request and what was provided by that
> device's REGISTER request.

I'm not sure I'm comfortable saying that. I know it would work for some.

>
> It is possible, however, to not require Asterisk to make this decision
> in the first place. If there was a way to obtain:
> * What channels are associated with an endpoint (which we should know)
> * The Contact headers provided by those channels
>
> Then, conceivably, the dialplan could be used to determine which
> contacts on the AoR map to what Contacts were provided by the channels.
> If there isn't a one-to-one mapping, it at least becomes the domain of
> the person building the system to resolve the discrepancy, and not
> something that Asterisk itself has to figure out.

I'd be down with this.

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org