[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] PJSIP_AOR and PJSIP_CONTACT Dialplan Functions
From: George Joseph <george.joseph () fairview5 ! com>
Date: 2014-12-29 18:14:42
Message-ID: CAHKv19DT-Vqy96jmNhesiD3RXTvAWGTEmf70vBh1C7Hmad9_zw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Dec 29, 2014 at 11:08 AM, Matthew Jordan <mjordan@digium.com> wrote:
>
>
> On Mon, Dec 29, 2014 at 11:20 AM, Joshua Colp <jcolp@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@10.24.19.55:5060,
> sip:alice@10.24.19.80:5060
>
Why not...
${PJSIP_CONTACT(sip:alice@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@10.24.19.55:5060
> ${PJSIP_CHANNEL(PJSIP/alice-00000002,contact)} =>
> sip:alice@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
>
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, \
2014 at 11:08 AM, Matthew Jordan <span dir="ltr"><<a \
href="mailto:mjordan@digium.com" target="_blank" \
onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=mjorda \
n@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return \
false;">mjordan@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, \
2014 at 11:20 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" \
target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf \
=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return \
false;">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Matthew Jordan wrote:<br> <br>
<snip><span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
If we have to define multiple endpoint definitions, then the usefulness<br>
of having multiple contacts bound to an AoR diminishes substantially. It<br>
may be that people are confusing the concept of a device with that of a<br>
user profile - but if that's the case, then I'm not sure why I would<br>
ever want to bother with multiple contacts on an AoR.<br>
</blockquote>
<br></span>
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.<br> \
<br></blockquote><div><br></div><div>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.<br></div><div><br> </div><div><snip><br> \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span> <br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
In basic scenarios, however, we do have a match between the inbound<br>
Contact header in the INVITE request and what was provided by that<br>
device's REGISTER request.<br>
</blockquote>
<br></span>
I'm not sure I'm comfortable saying that. I know it would work for \
some.<span><br> <br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
It is possible, however, to not require Asterisk to make this decision<br>
in the first place. If there was a way to obtain:<br>
* What channels are associated with an endpoint (which we should know)<br>
* The Contact headers provided by those channels<br>
<br>
Then, conceivably, the dialplan could be used to determine which<br>
contacts on the AoR map to what Contacts were provided by the channels.<br>
If there isn't a one-to-one mapping, it at least becomes the domain of<br>
the person building the system to resolve the discrepancy, and not<br>
something that Asterisk itself has to figure out.<br>
</blockquote>
<br></span>
I'd be down with this.<br>
<br clear="all"></blockquote></div><br></div><div class="gmail_extra">So let's \
say we had something like this:<br><br>PJSIP_AOR: provides a comma separated list of \
contacts<br></div><div class="gmail_extra">PJSIP_CONTACT: provides information about \
a given contact<br></div><div class="gmail_extra">PJSIP_ENDPOINT(channels): provides \
a comma separated list of channel names associated with the \
endpoint<br>PJSIP_CHANNEL(channel, property): retrieve a property about a specific \
PJSIP channel<br><br>In the aforementioned case, you might have:<br><br></div><div \
class="gmail_extra">${PJSIP_AOR(alice)} => <a \
href="http://sip:alice@10.24.19.55:5060" \
target="_blank">sip:alice@10.24.19.55:5060</a>,<a \
href="http://sip:alice@10.24.19.80:5060" \
target="_blank">sip:alice@10.24.19.80:5060</a></div></div></blockquote><div><br></div><div>Why \
not... </div><div>${PJSIP_CONTACT(<a href="http://sip:alice@10.24.19.55:5060" \
target="_blank">sip:alice@10.24.19.55:5060</a>)} => useful information! Including \
useragent. <b>AND ACTIVE CHANNEL IF ANY.</b></div><div><br></div><div>Skip the rest \
if you only need to know if in use.<br></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div \
class="gmail_extra">${PJSIP_ENDPOINT(channels)} => \
PJSIP/alice-00000001,PJSIP/alice-00000002<br></div><div \
class="gmail_extra">${PJSIP_CHANNEL(PJSIP/alice-00000001,contact)} => <a \
href="http://sip:alice@10.24.19.55:5060" \
target="_blank">sip:alice@10.24.19.55:5060</a><br>${PJSIP_CHANNEL(PJSIP/alice-00000002,contact)} \
=> <a href="http://sip:alice@10.24.19.80:5060" \
target="_blank">sip:alice@10.24.19.80:5060</a><br></div><div \
class="gmail_extra"><br></div><div class="gmail_extra">From that, I could conceivably \
determine which contacts on the AoR are in use (or not, depending on what \
PJSIP_CHANNEL spits back out).<br></div><div class="gmail_extra"><br></div><div \
class="gmail_extra">Two issues with this idea:<br></div><div \
class="gmail_extra"><br></div><div class="gmail_extra">(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".<br></div><div class="gmail_extra">(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.<span class="HOEnZb"><font \
color="#888888"><br></font></span></div><span class="HOEnZb"><font \
color="#888888"><div class="gmail_extra"><br>-- <br><div><div dir="ltr"><div>Matthew \
Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive \
NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a \
href="http://digium.com" target="_blank">http://digium.com</a> & <a \
href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div> \
</div></font></span></div> <br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" \
target="_blank">http://www.api-digital.com</a> --<br> <br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" \
target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div></div>
--
_____________________________________________________________________
-- 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic