Hi Ankur, Question is to handle next reliable 180 (provisional) response.
Regards, Mohit On 3/15/16, ankur bansal <abh.an...@gmail.com> wrote: > Hi Mohit , > > The phrase you mentioned mostly refers to scenario where Rseq not in > sequence then next prov response should be cached/discarded. > But original question here is if next prov response should be handled by > UAC in case it lands before 200ok PRACK of last response. > Correct me if don't understood your point. > > @JC, > As UAS has acknowledged first reliable 18x by sending 200ok PRACK ,its fine > from UAS side to trigger another reliable 18x > . > I think UAC can handle this subsequent 18x properly assuming UAS follows > RFC3262 and would have trigger reliable 18x > only after acknowledging first(as its MUST for UAS). > > OR > > May be it can be cached waiting for PRACK response.In case 481 comes for > PRACK instead of 200 ok then also UAC got initial sequence number to be > sure that subsequent comes in order.So no impact of what response comes for > PRACK > > So i dont see any harm in handling it immediately rather than caching > (where in worst scenario of 481 also no impact) > > But dont think its mentioned anywhere explicitly .May be others can provide > some reference for this . > > Regards > Ankur Bansal > > On Tue, Mar 15, 2016 at 4:13 PM, Mohit Soni <mohitsoni2...@gmail.com> > wrote: > >> Hi, >> >> RFC3262 states following under section 4 "UAC Behaviour" >> >> "Handling of subsequent reliable provisional responses for the same >> initial request follows the same rules as above, with the following >> difference: reliable provisional responses are guaranteed to be in >> order. As a result, if the UAC receives another reliable provisional >> response to the same request, and its RSeq value is not one higher >> than the value of the sequence number, that response MUST NOT be >> acknowledged with a PRACK, and MUST NOT be processed further by the >> UAC. An implementation MAY discard the response, or MAY cache the >> response in the hopes of receiving the missing responses." >> >> So, you can discard or cache 180. >> >> >> Regards, >> Mohit >> >> >> On 3/15/16, JC <jc.hu...@tom.com> wrote: >> > Hi, >> > >> > >> > >> > There is one SIP call scenario that one SIP UA sends one reliable 183 >> > to >> > one >> > SIP device, and the UA receives the PRACK, then, it sends 200OK of >> > PRACK >> > and >> > one new reliable 180 immediately. All the messages are sent over UDP, >> > due >> > to >> > the network issue, the SIP device receives the 2nd reliable 180 ahead >> > of >> > PRACK's 200OK. Now, I find the SIP device can't handle the case, and I >> have >> > to prove that current case should be handled by it well. >> > >> > >> > >> > I looked through RFC3262 and not find it clarify the case clearly. So, >> > is >> > there any other RFC or SPEC which describe it? >> > >> > >> > >> > Thanks, >> > >> > JC >> > >> > _______________________________________________ >> > 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 >> > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
