On Mon, Dec 29, 2014 at 11:08 AM, Matthew Jordan <[email protected]> wrote:
> > > On Mon, Dec 29, 2014 at 11:20 AM, Joshua Colp <[email protected]> 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:[email protected]:5060, > sip:[email protected]:5060 > Why not... ${PJSIP_CONTACT(sip:[email protected]: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:[email protected]:5060 > ${PJSIP_CHANNEL(PJSIP/alice-00000002,contact)} => > sip:[email protected]: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 >
-- _____________________________________________________________________ -- 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
