<div dir="ltr">Alex,<div><br></div><div>For what it is worth, since you mentioned Sansay as one of the vendors, the Sansay SBC supports both SIP methods for CNAM queries: INVITE/3XX Redirect and <span style="font-size:12.7272720336914px">SUBSCRIBE-NOTIFY. </span><span style="font-size:12.7272720336914px">As for "why did it get to be preferred over redirects" the answer is likely coming from the CNAM provider(s) and their original support for SIP.</span></div><div><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div><div>Carlos Perez</div><div>Sansay, Inc.</div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Oct 30, 2017 at 5:10 AM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Content-Type is application/calling-name-info, I believe.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
-- Alex<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> On Oct 30, 2017, at 4:15 AM, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
><br>
>> On 30.10.17 06:23, Alex Balashov wrote:<br>
>> Hello,<br>
>><br>
>> SIP redirects are the generally accepted transport for generic data<br>
>> queries (e.g. LRN dips, CNAM) over SIP. However, there is another<br>
>> method, which is used by Metaswitch, Sansay, and possibly some other<br>
>> softswitch vendors: the SUBSCRIBE-NOTIFY method.<br>
>><br>
>> This is one in which an ephemeral presence subscription (i.e. with an<br>
>> Expires: value of 0) is created by the querying switch, and the CNAM<br>
>> gateway returns a NOTIFY some time later containing the CNAM data reply<br>
>> some time later in its body. The most complete explanation, including<br>
>> some limited insight into design rationales, is available from Neustar,<br>
>> who offer this query method:<br>
>><br>
>> <a href="https://www.neustar.biz/resources/cnam/data-services-lidb-user-guide.pdf" rel="noreferrer" target="_blank">https://www.neustar.biz/<wbr>resources/cnam/data-services-<wbr>lidb-user-guide.pdf</a><br>
>><br>
>> See Chapter 7 - IP-CNAM Speification (page 25).<br>
>><br>
>> This is a weird and, in my opinion, ill-conceived mechanism[1].<br>
>> Nevertheless, it is widely implemented.<br>
>><br>
>> What I can't seem to figure out is where the formal definition of the<br>
>> standard comes from. It's certainly not an IETF RFC. The Metaswitch CFS<br>
>> provides a hint:<br>
>><br>
>> MetaSphere CFS and Metaswitch MGC support performing Caller Name Database<br>
>> (CNAM) lookups by sending SUBSCRIBE messages to a database server, and<br>
>> receiving NOTIFYs containing the caller name.<br>
>><br>
>> The specification of this interface is non-Metaswitch proprietary<br>
>> information. However, example message flows are shown in A.4.16.<br>
>><br>
>> Whose proprietary information?<br>
>><br>
>> I found this Verizon patent:<br>
>><br>
>> <a href="https://www.google.com/patents/US20080240383" rel="noreferrer" target="_blank">https://www.google.com/<wbr>patents/US20080240383</a><br>
>><br>
>> But it appears to be concerned with an adaptation layer of this to the<br>
>> ISCP side, though I only skimmed it. And if this is the patent in<br>
>> question, why don't any footnotes in vendor docs refer to it? The<br>
>> footnotes cite the SIP event pub-sub framework (RFC 3265) and little<br>
>> else.<br>
>><br>
>> What the heck is it? And why did it get to be preferred over redirects<br>
>> for some vendors, especially given that it invokes — but ultimately<br>
>> foregoes — most of the bureaucracy of the event subscription mechanism,<br>
>> in a way that's seemingly contradictory.<br>
>><br>
>> -- Alex<br>
>><br>
>> [1] For one, it uses attributes in the encapsulated payload which look like<br>
>> headers, but aren't headers:<br>
>><br>
>> Calling-Name-Status: available<br>
>> Calling-Name: “Joe Smith” <<a href="mailto:sip%3A9726840623@cnam-subscriber.com"><span>sip:<span title="Click to dial 9726840623"><span></span>9726840623</span>@cnam-</span><wbr>subscriber.com</a>;user=phone><br>
>> Presentation-Indicator: allowed<br>
>><br>
>> Why bother with an encapsulated body, then?<br>
><br>
> What is the content-type?<br>
>><br>
>> [2] More objectively, a SUBSCRIBE creates a dialog. But if the lifetime<br>
>> of the subscription is zero (expires immediately), presumably the dialog<br>
>> it creates also ends immediately. Why, then, does the NOTIFY have to be<br>
>> structured as an in-dialog NOTIFY (i.e. same From/To tags as the<br>
>> SUBSCRIBE)?<br>
>><br>
> This is the mechanism for one-shot NOTIFY me request. I don't recall if<br>
> there is an interval of time required within which the NOTIFY should be<br>
> sent, but practically is like "send me the state of what I requested via<br>
> NOTIFY immediately after you handled the SUBSCRIBE". It could be same<br>
> like for ACKs.<br>
><br>
> Cheers,<br>
> Daniel<br>
><br>
> --<br>
> Daniel-Constantin Mierla<br>
> <a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - <a href="http://www.asipto.com" rel="noreferrer" target="_blank">www.asipto.com</a><br>
> Kamailio World Conference - <a href="http://www.kamailioworld.com" rel="noreferrer" target="_blank">www.kamailioworld.com</a><br>
><br>
______________________________<wbr>_________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/voiceops</a><br>
</div></div></blockquote></div><br></div></div>