Alex, For what it is worth, since you mentioned Sansay as one of the vendors, the Sansay SBC supports both SIP methods for CNAM queries: INVITE/3XX Redirect and SUBSCRIBE-NOTIFY. As for "why did it get to be preferred over redirects" the answer is likely coming from the CNAM provider(s) and their original support for SIP. Carlos Perez Sansay, Inc. On Mon, Oct 30, 2017 at 5:10 AM, Alex Balashov <abalashov at evaristesys.com> wrote:
Content-Type is application/calling-name-info, I believe.
-- Alex
On Oct 30, 2017, at 4:15 AM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
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: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 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 at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops