[VoiceOps] SUBSCRIBE/NOTIFY method for CNAM querying

[Daniel-Constantin Mierla]

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