On Mon, Dec 29, 2014 at 10:01 AM, Matthew Jordan <[email protected]> wrote:
> > > 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 > Maybe a simple xref container hashed by contact that contains the channel id. It's populated by any INVITE whether incoming or outgoing? > > 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. > >
-- _____________________________________________________________________ -- 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
