[VoiceOps] SUBSCRIBE/NOTIFY method for CNAM querying

[Alex Balashov]

Content-Type is application/calling-name-info, I believe.

-- Alex

> On Oct 30, 2017, at 4:15 AM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> Hello,
> 
> 
>> On 30.10.17 06:23, Alex Balashov wrote:
>> Hello,
>> 
>> SIP redirects are the generally accepted transport for generic data
>> queries (e.g. LRN dips, CNAM) over SIP. However, there is another
>> method, which is used by Metaswitch, Sansay, and possibly some other
>> softswitch vendors: the SUBSCRIBE-NOTIFY method. 
>> 
>> This is one in which an ephemeral presence subscription (i.e. with an
>> Expires: value of 0) is created by the querying switch, and the CNAM
>> gateway returns a NOTIFY some time later containing the CNAM data reply
>> some time later in its body. The most complete explanation, including
>> some limited insight into design rationales, is available from Neustar,
>> who offer this query method:
>> 
>>   https://www.neustar.biz/resources/cnam/data-services-lidb-user-guide.pdf
>> 
>>   See Chapter 7 - IP-CNAM Speification (page 25).
>> 
>> This is a weird and, in my opinion, ill-conceived mechanism[1].
>> Nevertheless, it is widely implemented.
>> 
>> What I can't seem to figure out is where the formal definition of the
>> standard comes from. It's certainly not an IETF RFC. The Metaswitch CFS
>> provides a hint:
>> 
>>   MetaSphere CFS and Metaswitch MGC support performing Caller Name Database
>>   (CNAM) lookups by sending SUBSCRIBE messages to a database server, and
>>   receiving NOTIFYs containing the caller name.
>> 
>>   The specification of this interface is non-Metaswitch proprietary 
>>   information. However, example message flows are shown in A.4.16.
>> 
>> Whose proprietary information? 
>> 
>> I found this Verizon patent:
>> 
>>   https://www.google.com/patents/US20080240383
>> 
>> But it appears to be concerned with an adaptation layer of this to the
>> ISCP side, though I only skimmed it. And if this is the patent in
>> question, why don't any footnotes in vendor docs refer to it? The
>> footnotes cite the SIP event pub-sub framework (RFC 3265) and little
>> else. 
>> 
>> What the heck is it? And why did it get to be preferred over redirects
>> for some vendors, especially given that it invokes — but ultimately
>> foregoes — most of the bureaucracy of the event subscription mechanism,
>> in a way that's seemingly contradictory.
>> 
>> -- Alex
>> 
>> [1] For one, it uses attributes in the encapsulated payload which look like 
>> headers, but aren't headers:
>> 
>>   Calling-Name-Status: available
>>   Calling-Name: “Joe Smith” <sip:9726840623 at cnam-subscriber.com;user=phone>
>>   Presentation-Indicator: allowed
>> 
>> Why bother with an encapsulated body, then? 
> 
> What is the content-type?
>> 
>> [2] More objectively, a SUBSCRIBE creates a dialog. But if the lifetime
>> of the subscription is zero (expires immediately), presumably the dialog
>> it creates also ends immediately. Why, then, does the NOTIFY have to be
>> structured as an in-dialog NOTIFY (i.e. same From/To tags as the
>> SUBSCRIBE)?
>> 
> This is the mechanism for one-shot NOTIFY me request. I don't recall if
> there is an interval of time required within which the NOTIFY should be
> sent, but practically is like "send me the state of what I requested via
> NOTIFY immediately after you handled the SUBSCRIBE". It could be same
> like for ACKs.
> 
> Cheers,
> Daniel
> 
> -- 
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
> Kamailio World Conference - www.kamailioworld.com
>