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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

-----Original Message-----
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Hisham Khartabil
Sent: Thursday, April 02, 2009 9:37 AM
To: Paul Kyzivat (pkyzivat)
Cc: sipping@xxxxxxxx; Christer Holmberg
Subject: Re:  PRACK: Does non-200 response cease re-transmission ofreliable 18x?

That's a good scenario. Any others?

The point of the PRACK is to indicate to the UAS that the 1xx it sent was received successfully. Unless its a 401 to the PRACK, I don't see any other reason why the UAS should continue retransmitting the 1xx if its sent a non 2xx reponse to a PRACK. The PRACK has served its purpose.

Having said that, what other reasons would a UAS reject a PRACK?
[RL] authentication.
https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-March/022095.html

Hisham

2009/4/1 Paul Kyzivat <pkyzivat@xxxxxxxxx>:
>
>
> Christer Holmberg wrote:
>>
>> Hi,
>>
>> One of the PRACK related issues presented in SFO is whether a PRACK 
>> non-200 response would cease re-transmission of the assoicated 
>> reliable 18x response.
>>
>> Based on the mail discussions we've had I proposed that the non-200 
>> response DOES NOT ceasee the re-transmission. However, some people 
>> seemed to have an issue with that, so I was asked to "take it to the list".
>>
>> The main justification why a non-200 response would not cease the 
>> re-transmission is because an intermediate may reject the PRACK, in 
>> which case the UAS will never receive it (read: the UAS will continue 
>> to re-transmit the reliable 18x). So, when the UAC receives the PRACK 
>> non-200 response it should send a new PRACK, which hopefully will 
>> reach the UAS and trigger a 200 response.
>>
>> So, anyone who does not agree with the justification aboive, and 
>> thinks that a non-200 response DOES cease the re-transmission of the 
>> associated reliable 18x response, please indicate so.
>
> I agree with Christer here. Another scenario where this would be 
> important
> is:
>
> -> INVITE
> <- 180rel
> -> PRACK
> <- 401
>
> It this case it is essential to retry the PRACK with updated credentials.
> Certainly the UAS doesn't want to consider the 180 to have been 
> acknowledged in this case, since it might have been from a MiTM.
>
> This could come about in the case of a reINVITE, where the nonce used 
> in the original INVITE finally becomes stale by the time the PRACK is received.
>
>        Thanks,
>        Paul
> _______________________________________________
> 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/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


[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux