[asterisk-dev] PJSIP_AOR and PJSIP_CONTACT Dialplan Functions
Matthew Jordan
mjordan at digium.com
Mon Dec 29 11:01:33 CST 2014
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141229/23d4caba/attachment-0001.html>
More information about the asterisk-dev
mailing list