Hi Paul, On Mon, Oct 30, 2017 at 11:04:40AM -0400, Paul Kyzivat wrote:
> > 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? My inspiration for this particular statement is RFC 4694. Every LNP-query-over-SIP implementation I've seen in the wild returns a 3xx redirect of some description (though exact status code does vary) with a Contact that looks like this: Contact: <sip:orig_ruri_dest;npdi;rn=14045551...@orig.ruri.domain:port> > > 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. > > [...] > > > Whose proprietary information? > > Based on your own reference, looks like it is Neustar's. I'm not sure that's true. While Neustar's documentation is more elaborate than that of most service providers and softswitch vendors who offer this query mechanism, it is not substantially more authoritative. In other words, if I had linked to another vendor's documentation and you never saw Neustar's, you would most likely have concluded that the other vendor is the de facto pusher of this standard. > > 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. No, but if you're going off script (that is, off spec) anyway, surely some custom X- headers in the reply would have made life simpler. I agree that this is a splitting-hairs objection. > 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. Most standard subscriptions for ordinary presence-type applications seem to generate an immediate NOTIFY with a current state. I'm not sure if this is required by the standard offhand. One could argue that such a NOTIFY in this scenario represents fulfilment of that very case, I suppose. -- Alex -- 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/ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
