<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 29, 2014 at 10:01 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=mjordan@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 22, 2014 at 1:13 PM, George Joseph <span dir="ltr"><<a href="mailto:george.joseph@fairview5.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=george.joseph@fairview5.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">george.joseph@fairview5.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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Dec 22, 2014 at 12:01 PM, 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=mjordan@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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Dec 22, 2014 at 12:53 PM, Joshua Colp <<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>> wrote:<br>
> Currently within PJSIP there is no mechanism for the dialplan to examine<br>
> things at an AOR or contact level. The depth to which you can venture is<br>
> simply the endpoint.<br>
><br>
> In practice this can be annoying if you would like to examine things and<br>
> change an outgoing INVITE (to add a header for auto answer, for example). To<br>
> aid with this I'd like to propose two new dialplan functions: PJSIP_AOR and<br>
> PJSIP_CONTACT.<br>
><br>
> The PJSIP_AOR dialplan function would take the name of an AOR and return the<br>
> same information as "pjsip show aor". It would also make available a comma<br>
> separated list of contacts currently bound to the AOR (be it externally<br>
> added or configured).<br>
><br>
> Assumption:<br>
> An endpoint and AOR exist with the name "blink". A softphone is registered<br>
> to the AOR.<br>
><br>
> Example:<br>
> ${PJSIP_AOR(blink,mailboxes)} would return "1000" assuming it was configured<br>
> with "1000".<br>
><br>
> Example:<br>
> ${PJSIP_AOR(blink,contact)} would return<br>
> "blink/sip:38725691@192.168.137.1:53015;transport=TCP"<br>
><br>
> The PJSIP_CONTACT dialplan function would take in the name of a contact as<br>
> returned by PJSIP_AOR. It would make available the same information as<br>
> "pjsip show contact" as well user agent if available.<br>
><br>
> Example:<br>
> ${PJSIP_CONTACT(blink/sip:38725691@192.168.137.1:53015;transport=TCP,user_agent)}<br>
> would return "Blink 0.9.1.2 (Windows)"<br>
><br>
> While both of these help to query for information if you follow the<br>
> endpoint->aor->contact path there is currently no way, within a pre-dial<br>
> handler, to know what contact (if any) is being used. I'd like to extend the<br>
> ${CHANNEL()} implementation with two additional options, aor and contact,<br>
> which would provide this information.<br>
><br>
> Assumption:<br>
> An outgoing channel using Dial(PJSIP/blink) is created.<br>
><br>
> Example:<br>
> ${CHANNEL(aor)} would return "blink"<br>
><br>
> Example:<br>
> ${CHANNEL(contact)} would return<br>
> "blink/sip:38725691@192.168.137.1:53015;transport=TCP"<br>
><br>
> This assumes that the channel has been dialed using an AOR which resolved<br>
> into a contact. If an explicit contact has been provided (which is done with<br>
> PJSIP_DIAL_CONTACTS) then only contact would return a value.<br>
><br>
> This would allow the pre-dial handler to query for additional information<br>
> about the contact being dialed in order to do things.<br>
><br>
<br>
I think this gets 90% of the way towards what people (such as X-Rob,<br>
who filed ASTERISK-24341) were looking for.<br>
<br>
I don't think this quite addresses the use case of "I want to create<br>
an outbound INVITE request to all contacts on an AoR that do not<br>
currently have an active channel/media session associated with them" -<br>
since we have no way to query through the CHANNEL function what<br>
previous dial attempts resulted in.<br>
<br>
It feels like there should be a mechanism that we could provide that<br>
would have this information:<br>
* We know what contacts we are going to send outbound INVITE requests to<br>
* We know when those INVITE requests succeed and/or fail<br>
* And we know when the overall dialog established by those INVITE<br>
requests are done<br>
<br></blockquote><div><br></div></div></div><div>What you still don't know is if that contact is in use because it made an outgoing call.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What technical hurdles do you see with providing this?<br>
<span><font color="#888888"><br></font></span></blockquote></span></div></div></div>
<br clear="all"></blockquote></div><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regardless, I'm wondering if we aren't excluding the simple case due to outliers.<br><br></div><div class="gmail_extra">Say, for example, I have the following configuration:<br><br>[aor-multiple-template](!)<br>type=aor<br>support_path=yes<br>max_contacts=10<br><br>[auth-basic-template](!)<br>type=auth<br>auth_type=userpass<br><br>[endpoint-basic-template](!)<br>type=endpoint<br>context=default<br>allow=!all,g722,ulaw,alaw,gsm<br>ice_support=yes<br><br></div><div class="gmail_extra">[alice](aor-multiple-template)<br><br>[alice](auth-basic-template)<br>username=alice<br>password=alice<br><br>[alice](endpoint-basic-template)<br>callerid=Alice <1000><br>aors=alice<br>auth=alice<br><br></div><div class="gmail_extra">And let's say I have two phones that are sending REGISTER requests as "alice". As an example:<br><br><--- Received SIP request (837 bytes) from UDP:<a href="http://10.24.19.55:5060" target="_blank">10.24.19.55:5060</a> ---><br>REGISTER sip:<a href="http://10.24.16.171:5060" target="_blank">10.24.16.171:5060</a> SIP/2.0<br>Via: SIP/2.0/UDP 10.24.19.55:5060;rport;branch=z9hG4bKPj7-14slYhyfi45xtar3q7VBUbSsm4pUXK<br>Max-Forwards: 70<br>From: "Alice" <<a href="mailto:sip%3Aalice@10.24.16.171" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=sip%3Aalice@10.24.16.171&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">sip:alice@10.24.16.171</a>>;tag=4C7yY1pu6qOjZEp.-IReIZaUgqOy7uGI<br>To: "Alice" <<a href="mailto:sip%3Aalice@10.24.16.171" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=sip%3Aalice@10.24.16.171&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">sip:alice@10.24.16.171</a>><br>Call-ID: 0TUzqDV9dXHdkCvsi5SFRMQ7cQE7KhEZ<br>CSeq: 25921 REGISTER<br>User-Agent: Digium D40<br>Contact: "Alice" <sip:alice@10.24.19.55:5060;ob><br>Expires: 300<br>Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS<br>Authorization: Digest username="alice", realm="asterisk", nonce="1419871835/cfd27346038b4c30606ae6678141c047", uri="sip:<a href="http://10.24.16.171:5060" target="_blank">10.24.16.171:5060</a>", response="8744d3d86786048a551cb45916e683b6", algorithm=md5, cnonce="UCHty95Pp6K80bq8Yjp-AikA0ZJ5Nsk8", opaque="357ef62640b1d668", qop=auth, nc=00000001<br>Content-Length: 0<br><br></div><div class="gmail_extra">Sure, I only have a single endpoint defined, but since I "know" that both of these endpoints are going to support a subset of the codecs that are configured on my endpoint definition, that's really immaterial.<br><br></div><div class="gmail_extra">Once both have registered, I have the following aor for Alice:<br><br> Aor: <Aor..............................................> <MaxContact><br> Contact: <Aor/ContactUri.................................> <Status....> <RTT(ms)..><br> =========================================================================================<br><br> Aor: alice 10<br> Contact: alice/sip:alice@10.24.19.55:5060;ob Unknown nan<br> Contact: alice/sip:alice@10.24.19.80:5060;ob Unknown nan<br><br><br> ParameterName : ParameterValue<br> ====================================================<br> authenticate_qualify : false<br> contact : sip:alice@10.24.19.55:5060;ob<br> contact : sip:alice@10.24.19.80:5060;ob<br> default_expiration : 3600<br> mailboxes : <br> max_contacts : 10<br> maximum_expiration : 7200<br> minimum_expiration : 60<br> outbound_proxy : <br> qualify_frequency : 0<br> remove_existing : false<br> support_path : true<br><br><br></div><div class="gmail_extra">What does this look like when one of them sends an inbound INVITE request to Asterisk?<br><br><--- Received SIP request (1357 bytes) from UDP:<a href="http://10.24.19.55:5060" target="_blank">10.24.19.55:5060</a> ---><br>INVITE <a href="mailto:sip%3A1000@10.24.16.171" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=sip%3A1000@10.24.16.171&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">sip:1000@10.24.16.171</a> SIP/2.0<br>Via: SIP/2.0/UDP 10.24.19.55:5060;rport;branch=z9hG4bKPj0kj1kgnhZ72XiDvrxVw9ciYhHkod5WC8<br>Max-Forwards: 70<br>From: "Alice" <<a href="mailto:sip%3Aalice@10.24.16.171" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=sip%3Aalice@10.24.16.171&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">sip:alice@10.24.16.171</a>>;tag=a32sglRf96mIv0HiCCBLiuGqiKetDeXK<br>To: <<a href="mailto:sip%3A1000@10.24.16.171" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=sip%3A1000@10.24.16.171&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">sip:1000@10.24.16.171</a>><br>Contact: "Alice" <sip:alice@10.24.19.55:5060;ob><br>Call-ID: b2h.6IW7ZB7bHV48UgjZF9NcpAfFEIZB<br>CSeq: 19647 INVITE<br>Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS<br>Supported: replaces, 100rel, timer, norefersub<br>Session-Expires: 1800<br>Min-SE: 90<br>User-Agent: Digium D40<br>Authorization: Digest username="alice", realm="asterisk", nonce="1419871992/a8c7a8e171e37ca8a6a85a6a0dc10eb1", uri="<a href="mailto:sip%3A1000@10.24.16.171" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=sip%3A1000@10.24.16.171&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">sip:1000@10.24.16.171</a>", response="42dbbf0d040bbad82d32ae2823d483bd", algorithm=md5, cnonce="VrrCt1ULwaThKD9CGh73WhXNqFA-Rxvh", opaque="6e13a13a61a99a6f", qop=auth, nc=00000001<br>Content-Type: application/sdp<br>Content-Length: 430<br><br>v=0<br>o=- 115243281 115243281 IN IP4 10.24.19.55<br>s=digphn<br>c=IN IP4 10.24.19.55<br>t=0 0<br>a=X-nat:0<br>m=audio 4028 RTP/AVP 0 8 9 111 18 58 118 58 96<br>a=rtcp:4029 IN IP4 10.24.19.55<br>a=rtpmap:0 PCMU/8000<br>a=rtpmap:8 PCMA/8000<br>a=rtpmap:9 G722/8000<br>a=rtpmap:111 G726-32/8000<br>a=rtpmap:18 G729/8000<br>a=rtpmap:58 L16/16000<br>a=rtpmap:118 L16/8000<br>a=rtpmap:58 L16-256/16000<br>a=sendrecv<br>a=rtpmap:96 telephone-event/8000<br>a=fmtp:96 0-15<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Note that my Contact header in the received INVITE request does match the Contact header used by the phone to REGISTER.<br><br>Does it have to? No, a SIP ALG could have "helped me". If NAT was being used, we could have multiple Contact headers with the same private IP address being used by multiple phones (although in that case, it feels like what would be stored in the AOR would be the received IP address, and not the address in the Contact anyway).<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">It is possible, however, to not require Asterisk to make this decision in the first place. If there was a way to obtain:<br></div><div class="gmail_extra">* What channels are associated with an endpoint (which we should know)<br></div><div class="gmail_extra">* The Contact headers provided by those channels<br></div></div></blockquote><div><br></div><div>Maybe a simple xref container hashed by contact that contains the channel id. It's populated by any INVITE whether incoming or outgoing?</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">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.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div></font></span></div></blockquote><div><br></div></div></div></div>