Paul, I'm not a SIP standards expert by any stretch, but yours is the interpretation I tend to favour and which sits best with me.
Since in-dialog requests are originated by the dialog parties, timing issues belong with them, not with intermediate proxies IMHO. On October 31, 2017 10:50:45 AM EDT, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: >On 10/31/17 8:44 AM, Liviu Chircu wrote: >> Hi Alex, >> >> IMO, building logic into the proxy which encourages/mends the proper >> sequencing of UDP messages does nothing more than to hide the >underlying >> problem, i.e. "UDP does not guarantee message sequencing in the first > >> place" *. There is also a subtle point to be made here: your proxy's >> loosely coupled/parallelized way of handling the two transactions is >> effectively breaking the RFC some % of the time, since the proxy's TU >is >> generating a new INVITE while another INVITE transaction is in >progress >> (strictly judging by the network timestamps). > >One can argue that the proxy is doing nothing wrong and perhaps being >helpful by exposing bugs in handling of reordered UDP messages. > > Thanks, > Paul > >> * From this angle, the only sane thing left to do is to have the >proxy >> retry the re-INVITE for UASs who are properly responding with 491 and > >> propagate any other 4xx/5xx error replies back to the UAC (UA B in >our >> case) in the hope that they retry their re-INVITE. >> >> Best regards, >> >> Liviu Chircu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> >> On 30.10.2017 19:11, 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; >>> >>> 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 >>> >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Alex -- Sent via mobile, please forgive typos and brevity. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
