[VoiceOps] SUBSCRIBE/NOTIFY method for CNAM querying
abalashov at evaristesys.com
Mon Oct 30 08:10:02 EDT 2017
Content-Type is application/calling-name-info, I believe.
> On Oct 30, 2017, at 4:15 AM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>> 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.
> 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
More information about the VoiceOps