Re: [Sip-implementors] Reinvite/ACK race
Piece of errata here (always when I'm typing): On Mon, Oct 30, 2017 at 01:11:50PM -0400, Alex Balashov wrote: > Hi, > > I've got a scenario like so: > >UA A -> Proxy P > UA B > > 1. UA A initiates call through Proxy P; > > 2. Dialog is established and confirmed, with Record-Route; > > 3. UA B sends reinvite #1 through P to A; > > 4. UA B sends 2xx reply; In #4, UA A is definitely sending the 2xx reply. -- 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
[Sip-implementors] Reinvite/ACK race
Hi, I've got a scenario like so: UA A -> Proxy P > UA B 1. UA A initiates call through Proxy P; 2. Dialog is established and confirmed, with Record-Route; 3. UA B sends reinvite #1 through P to A; 4. UA B sends 2xx reply; 5. UA B sends end-to-end ACK for reinvite #1 and almost simultaneously sends reinvite #2. The temporal delta is between reinvite #2 and ACK for reinvite #1 on the wire is 3 ms. The issue is that the concurrency characteristics of proxy P are such that its worker threads are very loosely coupled, and there's no synchronisation among them for message ordering. Transport is UDP, naturally. So, the result — for all kinds of stochastic processing and userspace scheduling type reasons — is that the reinvite is forwarded first, before the ACK. That leads to a 500 / 491 scenario UA A. Is there any general guidance on what to do with these scenarios? I looked at RFC 5407 § 3.1.4, which appears to describe a similar, but not identical scenario involving an initial INVITE and subsequent reinvite. As far as I can tell, the recommendation in that standard is "space the messaging out more in time". Switching to TCP would presumably help, since any given flow would involve a single connection to a single worker thread and the transport would guarantee ordering. However, that's not really feasible in this implementation for a host of reasons. Any other thoughts welcome! Cheers, -- 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
Re: [Sip-implementors] SUBSCRIBE-NOTIFY method for CNAM querying
But to clarify my question: Regardless of whether it's a rogue standard from an IETF POV, there 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). -- 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
Re: [Sip-implementors] SUBSCRIBE-NOTIFY method for CNAM querying
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: > > 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
Re: [Sip-implementors] SUBSCRIBE-NOTIFY method for CNAM querying
(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” 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
