<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">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 class=""><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 class="">
<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 class=""><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">sip:alice@10.24.19.55:5060</a>,<a href="http://sip:alice@10.24.19.80:5060">sip:alice@10.24.19.80:5060</a><br></div><div class="gmail_extra">${PJSIP_CONTACT(<a href="http://sip:alice@10.24.19.55:5060">sip:alice@10.24.19.55:5060</a>)} => useful information! Including useragent.<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">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">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.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><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></div>