[asterisk-dev] PJSIP_AOR and PJSIP_CONTACT Dialplan Functions
George Joseph
george.joseph at fairview5.com
Mon Dec 29 11:12:58 CST 2014
On Mon, Dec 29, 2014 at 10:01 AM, Matthew Jordan <mjordan at digium.com> wrote:
>
>
> On Mon, Dec 22, 2014 at 1:13 PM, George Joseph <
> george.joseph at fairview5.com> wrote:
>
>>
>>
>> On Mon, Dec 22, 2014 at 12:01 PM, Matthew Jordan <mjordan at digium.com>
>> wrote:
>>
>>> On Mon, Dec 22, 2014 at 12:53 PM, Joshua Colp <jcolp at digium.com> 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:38725691 at 192.168.137.1: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:38725691 at 192.168.137.1: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:38725691 at 192.168.137.1: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:alice at 10.24.16.171
> >;tag=4C7yY1pu6qOjZEp.-IReIZaUgqOy7uGI
> To: "Alice" <sip:alice 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", 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 --->
> INVITE sip:1000 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
> >;tag=a32sglRf96mIv0HiCCBLiuGqiKetDeXK
> To: <sip:1000 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", 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141229/d6203bec/attachment-0001.html>
More information about the asterisk-dev
mailing list