[VoiceOps] SUBSCRIBE/NOTIFY method for CNAM querying

Daniel-Constantin Mierla miconda at gmail.com
Mon Oct 30 04:15:08 EDT 2017


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
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.


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

More information about the VoiceOps mailing list