To be clearer, your wrong and you have your head up a horse's tail end ----- Original Message ----- From: sipping-bounces@xxxxxxxx <sipping-bounces@xxxxxxxx> To: sipping@xxxxxxxx <sipping@xxxxxxxx> Sent: Sun Apr 05 22:07:03 2009 Subject: Fwd: PRACK: Does non-200 response ceasere-transmissionofreliable 18x? Hi All, Please read Martin's private response to my email. Just wanted to show the community his professionalism. I don't know this person and have never interacted with him, yet he calls me names and responds unprofessionally. Hisham ---------- Forwarded message ---------- From: DOLLY, MARTIN C, ATTLABS <mdolly@xxxxxxx> Date: 2009/4/6 Subject: Re: PRACK: Does non-200 response cease re-transmissionofreliable 18x? To: hisham.khartabil@xxxxxxxxx Because your an acedemic, at best ----- Original Message ----- From: Hisham Khartabil <hisham.khartabil@xxxxxxxxx> To: DOLLY, MARTIN C, ATTLABS Sent: Sun Apr 05 21:58:31 2009 Subject: Re: PRACK: Does non-200 response cease re-transmissionofreliable 18x? why are you calling me an a-hole? 2009/4/6 DOLLY, MARTIN C, ATTLABS <mdolly@xxxxxxx>: > What do you know? > > ----- Original Message ----- > From: Hisham Khartabil <hisham.khartabil@xxxxxxxxx> > To: DOLLY, MARTIN C, ATTLABS > Sent: Sun Apr 05 21:50:57 2009 > Subject: Re: PRACK: Does non-200 response cease re-transmissionofreliable 18x? > > Excuse me? > > 2009/4/6 DOLLY, MARTIN C, ATTLABS <mdolly@xxxxxxx>: >> No a-hole >> >> ----- Original Message ----- >> From: sipping-bounces@xxxxxxxx <sipping-bounces@xxxxxxxx> >> To: Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> >> Cc: sipping@xxxxxxxx <sipping@xxxxxxxx>; Brett Tate <brett@xxxxxxxxxxxxx> >> Sent: Sun Apr 05 19:37:29 2009 >> Subject: Re: PRACK: Does non-200 response cease re-transmissionofreliable 18x? >> >> 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 >> > _______________________________________________ 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 _______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
