On Mon, Dec 22, 2014 at 1:13 PM, George Joseph <[email protected]> wrote:
> > > On Mon, Dec 22, 2014 at 12:01 PM, Matthew Jordan <[email protected]> > wrote: > >> On Mon, Dec 22, 2014 at 12:53 PM, Joshua Colp <[email protected]> wrote: >> > Currently within PJSIP there is no mechanism for the dialplan to examine >> > things at an AOR or contact level. The depth to which you can venture is >> > simply the endpoint. >> > >> > In practice this can be annoying if you would like to examine things and >> > change an outgoing INVITE (to add a header for auto answer, for >> example). To >> > aid with this I'd like to propose two new dialplan functions: PJSIP_AOR >> and >> > PJSIP_CONTACT. >> > >> > The PJSIP_AOR dialplan function would take the name of an AOR and >> return the >> > same information as "pjsip show aor". It would also make available a >> comma >> > separated list of contacts currently bound to the AOR (be it externally >> > added or configured). >> > >> > Assumption: >> > An endpoint and AOR exist with the name "blink". A softphone is >> registered >> > to the AOR. >> > >> > Example: >> > ${PJSIP_AOR(blink,mailboxes)} would return "1000" assuming it was >> configured >> > with "1000". >> > >> > Example: >> > ${PJSIP_AOR(blink,contact)} would return >> > "blink/sip:[email protected]:53015;transport=TCP" >> > >> > The PJSIP_CONTACT dialplan function would take in the name of a contact >> as >> > returned by PJSIP_AOR. It would make available the same information as >> > "pjsip show contact" as well user agent if available. >> > >> > Example: >> > ${PJSIP_CONTACT(blink/sip:[email protected]:53015 >> ;transport=TCP,user_agent)} >> > would return "Blink 0.9.1.2 (Windows)" >> > >> > While both of these help to query for information if you follow the >> > endpoint->aor->contact path there is currently no way, within a pre-dial >> > handler, to know what contact (if any) is being used. I'd like to >> extend the >> > ${CHANNEL()} implementation with two additional options, aor and >> contact, >> > which would provide this information. >> > >> > Assumption: >> > An outgoing channel using Dial(PJSIP/blink) is created. >> > >> > Example: >> > ${CHANNEL(aor)} would return "blink" >> > >> > Example: >> > ${CHANNEL(contact)} would return >> > "blink/sip:[email protected]:53015;transport=TCP" >> > >> > This assumes that the channel has been dialed using an AOR which >> resolved >> > into a contact. If an explicit contact has been provided (which is done >> with >> > PJSIP_DIAL_CONTACTS) then only contact would return a value. >> > >> > This would allow the pre-dial handler to query for additional >> information >> > about the contact being dialed in order to do things. >> > >> >> I think this gets 90% of the way towards what people (such as X-Rob, >> who filed ASTERISK-24341) were looking for. >> >> I don't think this quite addresses the use case of "I want to create >> an outbound INVITE request to all contacts on an AoR that do not >> currently have an active channel/media session associated with them" - >> since we have no way to query through the CHANNEL function what >> previous dial attempts resulted in. >> >> It feels like there should be a mechanism that we could provide that >> would have this information: >> * We know what contacts we are going to send outbound INVITE requests to >> * We know when those INVITE requests succeed and/or fail >> * And we know when the overall dialog established by those INVITE >> requests are done >> >> > What you still don't know is if that contact is in use because it made an > outgoing call. > > >> What technical hurdles do you see with providing this? >> >> > 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. 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 ---> REGISTER sip: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]>;tag=4C7yY1pu6qOjZEp.-IReIZaUgqOy7uGI To: "Alice" <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", 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 ---> INVITE 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]>;tag=a32sglRf96mIv0HiCCBLiuGqiKetDeXK To: <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]", 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. 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). 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. 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. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://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
