Hi, >>>>The UAC is unaware if the PRACK has served its purpose since it >>>>doesn't know if rejected by middle box or the UAS >>>>performing the retries. >>>> >>>That's not the UAC's problem. The only reasone a PRACK has >>>a response is because you had to fit it into one of the state >>>machines defined in RFC3261. That doesnt mean we go a sover analyse >>>its response. >> >>So, how do you propose that we solve the issue if the PRACK was >>rejected by an intermediate, and the UAS never got it? > >That's already solved in RFC3262. Read Section 3: > >"The reliable provisional response is passed to the transaction layer >periodically with an interval that starts at T1 seconds and doubles >for each retransmission" > >and > >"Retransmissions of the reliable provisional response cease when a >matching PRACK is received by the UA core" > >and > >"If a PRACK request is received by the UA core that does not match any >unacknowledged reliable provisional response, the UAS MUST >respond to the PRACK with a 481 response. If the PRACK does match an >unacknowledged reliable provisional response, it MUST be responded to >with a 2xx response" Yes. >and > >"If a reliable provisional response is retransmitted for 64*T1 seconds >without reception of a corresponding PRACK, the UAS SHOULD >reject the original request with a 5xx response." Yes. >But I guess your issue is with the following text in section 4: > >"Note that the PRACK is like any other non-INVITE request within a >dialog. In particular, a UAC SHOULD NOT retransmit the PRACK request >when it receives a retransmission of the provisional response being >acknowledged, although doing so does not create a protocol error." > >You want the UAC to retransmit the PRACK. Or the UAC can >remvoe state of the 1xx it PRACKed and treat the >retrasmission of the 1xx as a new one (I haven't thought this >one through properly though). We are NOT talking about re-transmitting the PRACK. We are talking about generating a NEW PRACK (ie a NEW SIP transaction), but for the SAME reliable provisional response. Regards, Christer _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
