[VoiceOps] SUBSCRIBE/NOTIFY method for CNAM querying

[Carlos Perez]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20171030/a228ef7c/attachment.html>