[asterisk-dev] PJSIP_AOR and PJSIP_CONTACT Dialplan Functions

[George Joseph]

On Mon, Dec 29, 2014 at 11:08 AM, Matthew Jordan <mjordan at digium.com> wrote:

>
>
> On Mon, Dec 29, 2014 at 11:20 AM, Joshua Colp <jcolp at digium.com> wrote:
>
>> Matthew Jordan wrote:
>>
>> <snip>
>>
>>
>>> 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.
>>>
>>
>> It depends on how you use things and how you need to address them, it's
>> environment and use case specific. Personally I don't need to know if what
>> I'm dialing is available. I send it to everything.
>>
>>
> Really, I was referring more to requiring defining multiple endpoints,
> rather than this specific problem. I agree that there are plenty of cases
> where you might not care about the state of the devices, but I think the
> notion of knowing which devices that have REGISTER'd to you have some state
> is pretty useful.
>
>
> <snip>
>
>
>>
>>
>>> 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.
>>>
>>
>> I'm not sure I'm comfortable saying that. I know it would work for some.
>>
>>
>>> 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.
>>>
>>
>> I'd be down with this.
>>
>>
> So let's say we had something like this:
>
> PJSIP_AOR: provides a comma separated list of contacts
> PJSIP_CONTACT: provides information about a given contact
> PJSIP_ENDPOINT(channels): provides a comma separated list of channel names
> associated with the endpoint
> PJSIP_CHANNEL(channel, property): retrieve a property about a specific
> PJSIP channel
>
> In the aforementioned case, you might have:
>
> ${PJSIP_AOR(alice)} => sip:alice at 10.24.19.55:5060,
> sip:alice at 10.24.19.80:5060
>

Why not...
${PJSIP_CONTACT(sip:alice at 10.24.19.55:5060)} => useful information!
Including useragent. *AND ACTIVE CHANNEL IF ANY.*

Skip the rest if you only need to know if in use.


> ${PJSIP_ENDPOINT(channels)} => PJSIP/alice-00000001,PJSIP/alice-00000002
> ${PJSIP_CHANNEL(PJSIP/alice-00000001,contact)} =>
> sip:alice at 10.24.19.55:5060
> ${PJSIP_CHANNEL(PJSIP/alice-00000002,contact)} =>
> sip:alice at 10.24.19.80:5060
>
> From that, I could conceivably determine which contacts on the AoR are in
> use (or not, depending on what PJSIP_CHANNEL spits back out).
>
> Two issues with this idea:
>
> (1) I'll grant that at that point, I'd really want to be using an AGI, as
> using that much string parsing in dialplan is "fun".
> (2) PJSIP_CHANNEL is kind of annoying. I'd rather use the CHANNEL
> function, except that we need to specify which channel to invoke the
> function on (which is definitely not going to be the caller). I couldn't
> find a better way to do that, but my dialplan-foo may be missing something.
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141229/68a4b2b4/attachment-0001.html>