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
