Hello, I apologise for cross-posting this from VoiceOps, and concede that it is an applied and operational question as much as it is a formal one. Nevertheless, any help would be appreciated.
As far as I know, 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][2]. 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:9726840...@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/ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
