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

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

 



1xx.

The retransmitting of PRACK will of course cease when the respone (whatever the response code is) is received. 

When I talk about "UAC sending a new PRACK" I don't mean re-transmit the previous PRACK. I am talking about generating a PRACK, which hopefully is less likely to be rejected.

-----Original Message-----
From: Hisham Khartabil [mailto:hisham.khartabil@xxxxxxxxx] 
Sent: Thursday, April 02, 2009 7:07 AM
To: Christer Holmberg
Cc: Hadriel Kaplan; Rockson Li (zhengyli); Paul Kyzivat (pkyzivat); sipping@xxxxxxxx
Subject: Re:  PRACK: Does non-200 response cease re-transmission ofreliable 18x?

Are you talking about retransmitting of PRACK or 1xx?

2009/4/2 Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>:
>
> Hi,
>
>>>>If the 1xx carried and answer, then the PRACK would carry an offer.
>>>>Rejecting that offer in the PRACK with a 4xx by the UAS should not 
>>>>impact the assertion that the 1xx has reached its destination.
>>>>Therefore no point in retransmitting the 1xx.
>>>
>>>True. But the UAC doesn't know whether the UAS, or some intermediate, rejected the offer.
>>
>>Yeah, that's not the issue.
>
> That IS the issue. If it wasn't, I think most people would agree that the re-transmission is ceased - at least nobody has said otherwise in the previous e-mail discussions we've had on this.
>
>>Of course the UAS will retransmit in this case. It hasnt seen the 
>>PRACK. The issue is if the UAS does receive the PRACK but rejects it.
>>
>>In my opinion, unless the UAS responds with a 401, the PRACK has served its purpose.
>
> I agree with you, and the way 3262 is written is more or less says that the re-transmission of the 18x stops when the PRACK is received - before you know what the final response is going to be.
>
> But, again, the problem with that solution is that the UAC cannot be sure whether the UAS actually received the PRACK, and therefor the proposed solution is that it sends a new PRACK in case of a non-200 response.
>
> Regards,
>
> Christer
>
>
>
>
>>
>>>Again, we need to look at what the PRACK is really doing. It is acknowledging that the 1xx has reached its destination.
>>
>> As Hadriel said: I wish that was all it was doing.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>
>>>> -----Original Message-----
>>>> From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On 
>>>> Behalf Of Hisham Khartabil
>>>> Sent: Wednesday, April 01, 2009 10:15 PM
>>>> To: Rockson Li (zhengyli)
>>>> Cc: Paul Kyzivat (pkyzivat); sipping@xxxxxxxx; Christer Holmberg
>>>> Subject: Re:  PRACK: Does non-200 response cease 
>>>> re-transmission ofreliable 18x?
>>>>
>>>> We already know that one. I was asking if there are any others.
>>>>
>>>> Hisham
>>>>
>>>> 2009/4/2 Rockson Li (zhengyli) <zhengyli@xxxxxxxxx>:
>>>> >
>>>> >
>>>> > -----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
>>>
>>
>
_______________________________________________
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