[asterisk-dev] PJSIP_AOR and PJSIP_CONTACT Dialplan Functions

George Joseph george.joseph at fairview5.com
Mon Dec 22 13:13:56 CST 2014


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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141222/66bd36d6/attachment-0001.html>


More information about the asterisk-dev mailing list