2009/4/3 Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>: > > 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" 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." 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). Hisham > > Even if it's not the UAC's "problem", the UAC can help to ensure that > the UAS really gets the PRACK. > > I agree that we shouldn't start to analyse responses in detail. The > proposal is simply that a non-200 response does not cease the > re-transmission of the reliable 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
