Re: PRACK: Does non-200 response cease re-transmission ofreliable 18x?

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 [email protected] for questions on current sip
Use [email protected] for new developments of core SIP