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

The first place i recall seeing this flow was Broadsoft. It was the sole method you could perform CNAM dips as far back as I can recall which was R13. To carbon date that, other softswitches which would have been contemporaries to Broadsoft in ~2005 when that was state of the art were Sylantro (no such support) and Metaswitch (only SS7 support at the time). My guess is Broadsoft may have defined a de-facto standard by implementing an esoteric mechanism, and forcing their large subset of customers to require it so all the providers supported it and viola a standard is born. If this is true its unlikely you will find any ratified standard. Maybe someone with deeper historical roots than I could shed some light on this, though FWIW this flow has a decidedly broadsoftian feel to it. On 10/30/2017 12:12 PM, Alex Balashov wrote:

Thanks Carlos.

But to clarify my question:

There is clearly is *some* kind of standard out there, as indicated by the number of (big) vendors who implement it in an agreed-upon way.

So, what I'm trying to figure out is what that standard is and where it's defined.

The Neustar documentation contains obvious cut-and-paste from an ABNF spec:

calling-name-request = callee CRLF [ called CRLF ] callee =?Calling-Party? HCOLON addr-spec called =?Called-Party? HCOLON addr-spec addr-spec =SIP URI / SIPS URI / TEL URI

And it does not seem thematically consistent with the general tenor of that document to suddenly break out some ABNF on their own accord. So, this syntax spec comes from *somewhere*, though no citations revealing its provenance are provided.

The same kind of thing is true in all other docs on this topic from other major vendors. None of them reference anything non-generic (e.g. RFC 3265).

So, what's the standard? Is it the Verizon patent? If so, why don't they any vendor docs refer to it by name?

-- Alex

"rogue standard" When future historians ask why communications in the 21st century was such a mess, someone will base their dissertation on that phrase. On 10/30/2017 1:27 PM, Alex Balashov wrote:

Well, there's no IANA event package registration for Event: calling-name. By all accounts it's a rogue standard.

But okay, it's still a standard. Why does nobody cite it? Call it the Broadsoft TRB-VP-791 (Three Ring Binder o' Voodoo^H^H^H^H^H^H^HBest Practices 791).

LONG long ago, I worked for a NETBIOS networking company, and managed to get a joke/easter egg put into the actual code, and actually working. It accidentally became documented and then started being used. I got yelled at, they took it out, and users complained. On Mon, Oct 30, 2017 at 1:53 PM, Alex Balashov <abalashov at evaristesys.com> wrote:

On Mon, Oct 30, 2017 at 01:44:09PM -0700, Ryan Delgrosso wrote:

...

"rogue standard"

When future historians ask why communications in the 21st century was such a mess, someone will base their dissertation on that phrase.

I call it a form of SIP meme laundering. Seed some behaviour somewhere, and pretty soon everyone's doing it, like starting a line to nowhere and finding other people lining up because "surely" it goes somewhere... and then someone shows up to provide something at the head of it, and now it's legit.

Given that it's Broadsoft, I'm pretty sure pets were harmed somehow.

"Whiskers won't know the difference," they said.

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

Simply explain that in accordance with the 1958 COPUOUS treaty (specifically the outer space treaty) all extra-planetary calls are deemed settlement free as no nation may claim sovereignty of any celestial body.... ...or you could simply take the low road and make a beastie boys joke. Either would be perfectly acceptable. On 10/30/2017 7:50 PM, Alex Balashov wrote:

Our Class 4 product supports several rating jurisdiction types:

"inter" [i.e. inter-state] "intra" [i.e. intra-state] "undef" [i.e. indeterminate]

And, if you really, really look further, all the way down:

"intergalactic"

We have received far more seemingly serious questions about the purpose of this than I could have anticipated.

On Mon, Oct 30, 2017 at 04:32:58PM -0400, Mark R Lindsey wrote:

It appears that it was documented by BroadSoft (Sam Hoffpauir, currently VP Engineering) in May 2004

But documented ?d?nde?, though? How did you come by this information? -- 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/

Anyone with a Sansay or Metaswitch which queries CNAM using this standard want to do me a solid and route me a DID to my SIP server? It will need to be configured to query a gateway (which I will specify) for CNAM using the subscribe-notify method. Urgently need to test and all the options thus far are not very useful. I need a live, real-world DID. -- 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/