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? 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
