[VoiceOps] SUBSCRIBE/NOTIFY method for CNAM querying

[Alex Balashov]

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? 

[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)?

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/