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:9726840...@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 _______________________________________________ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
