[VoiceOps] SUBSCRIBE/NOTIFY method for CNAM querying
miconda at gmail.com
Mon Oct 30 04:15:16 EDT 2017
On 30.10.17 06:23, Alex Balashov wrote:
> 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:
> See Chapter 7 - IP-CNAM Speification (page 25).
> This is a weird and, in my opinion, ill-conceived mechanism.
> 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:
> 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
> 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
>  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?
>  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.
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