(disclaimer: while I know quite a bit about SIP I know nothing about
these CNAM query mechanisms. AFAIK none of these mechanisms are covered
by IETF standards.)
On 10/30/17 1:25 AM, Alex Balashov wrote:
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.
Can you provide a reference to a specification for how this is done?
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).
It looks like Neustar is acting as a quasi-standard for this mechanism.
Unfortunately I find no formal registration of this event package in the
IANA Event Types registry, so it is a rogue definition and thus using it
is a spec violation.
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?
Based on your own reference, looks like it is Neustar's.
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?
This isn't my definition so I can only speculate, but there is need for
*some* syntax for the payload. This is the syntax that was chosen. If
you already have a SIP parser, then it should be easy to write a parser
for this too. If *you* were defining the event package then you might
make a different choice.
If you are asking why not just use these as SIP headers in the NOTIFY,
then the answer is that they aren't SIP headers, and you could never get
them approved as such.
[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)?
That is just the way the event mechanism is defined. It is a degenerate
form of a subscription with a longer expiration, and hence follows all
the same rules. Defining different rules would have just make
implementations more difficult.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
