On Mon, Dec 29, 2014 at 11:20 AM, Joshua Colp <jc...@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
${PJSIP_CONTACT(sip:alice@10.24.19.55:5060)} => useful information!
Including useragent.
${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
