Subject: Re: [Sipping] PRACK: Does non-200 response cease re-transmissionofreliable 18x?

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sun, 5 Apr 2009 20:57:11 -0400

Do you operate a network, that has to interoperate with everything...rethink your response. 

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Christer Holmberg <[email-masked]>
Cc: [email-masked] <[email-masked]>; Brett Tate <[email-masked]>
Sent: Sun Apr 05 19:37:29 2009
Subject: Re: [Sipping] PRACK: Does non-200 response cease re-transmissionofreliable 18x?

2009/4/3 Christer Holmberg <[email-masked]>:
>
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 10 Apr 2009 15:53:56 -0400

> everything...rethink your response. 

Could you explicate this?  I admit that I don't have experience
operating a large-scale network, so it is not clear to me the
constraints that such a network places on solutions to this problem.

Dale