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:[email protected] <mailto:sip%[email protected]>>;tag=4C7yY1pu6qOjZEp.-IReIZaUgqOy7uGI To: "Alice" <sip:[email protected] <mailto:sip%[email protected]>> Call-ID: 0TUzqDV9dXHdkCvsi5SFRMQ7cQE7KhEZ CSeq: 25921 REGISTER User-Agent: Digium D40 Contact: "Alice" <sip:[email protected]: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:[email protected]:5060;ob Unknown nan Contact: alice/sip:[email protected]:5060;ob Unknown nan ParameterName : ParameterValue ==================================================== authenticate_qualify : false contact : sip:[email protected]:5060;ob contact : sip:[email protected]: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:[email protected] <mailto:sip%[email protected]> SIP/2.0 Via: SIP/2.0/UDP 10.24.19.55:5060;rport;branch=z9hG4bKPj0kj1kgnhZ72XiDvrxVw9ciYhHkod5WC8 Max-Forwards: 70 From: "Alice" <sip:[email protected] <mailto:sip%[email protected]>>;tag=a32sglRf96mIv0HiCCBLiuGqiKetDeXK To: <sip:[email protected] <mailto:sip%[email protected]>> Contact: "Alice" <sip:[email protected]: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:[email protected] <mailto:sip%[email protected]>", 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:[email protected]:21276;rinstance=b94f74903a174265> While a call gives: Contact: <sip:[email protected]: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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
