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

From: Hisham Khartabil <[email-masked]>
Date: Thu, 2 Apr 2009 12:37:05 +1100

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?

Hisham

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

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Thu, 2 Apr 2009 10:12:19 +0800

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

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 <[email-masked]>:
>> non-200 response would cease re-transmission of the assoicated 
>> reliable 18x response.
>>
>> 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".
>>
>> 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.
>
> 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
> 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
>
_______________________________________________
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: Hisham Khartabil <[email-masked]>
Date: Thu, 2 Apr 2009 13:14:51 +1100

We already know that one. I was asking if there are any others.

Hisham

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Apr 2009 22:47:24 -0400

Well, since we technically allow it to carry SDP and pretty much anything, then a while series of 4xx could be triggered related to body handling issues I guess.  Technically it's supposed to be used like an ACK I think, so "carefully".  But even just with SDP it may, in theory, be too big to reach the UAS.  Or if a pidf-location body is added, for example.

It can also carry a Require/Proxy-Require header and be rejected due to that, not that I can think of why that would realistically ever be an issue for PRACK.

-hadriel

> Sent: Wednesday, April 01, 2009 10:15 PM
> To: Rockson Li (zhengyli)
> Cc: Paul Kyzivat (pkyzivat); [email-masked]; Christer Holmberg
> 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.
> >
> > This list is for NEW development of the application of SIP Use sip-
> [email-masked] for questions on current sip Use [email-masked]
> for new developments of core SIP
> >

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 2 Apr 2009 13:57:56 +1100

2009/4/2 Hadriel Kaplan <[email-masked]>:
>
> Well, since we technically allow it to carry SDP and pretty much anything, then a while series of 4xx could be triggered related to body handling issues I guess.  Technically it's supposed to be used > like an ACK I think, so "carefully".  But even just with SDP it may, in theory, be too big to reach the UAS.  Or if a pidf-location body is added, for example.

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.

If the 1xx carried the offer, then the PRACK would carry the answer,
in which case the UAS cannot reject, but can issue a new offer or tear
down the call. Again, no point in retransmitting the 1xx. The 1xx has
been achnowledged to be received.

> It can also carry a Require/Proxy-Require header and be rejected due to that, not that I can think of why that would realistically ever be an issue for PRACK.

Again, we need to look at what the PRACK is really doing. It is
acknowledging that the 1xx has reached its destination.

Hisham

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Apr 2009 23:11:11 -0400

> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Wednesday, April 01, 2009 10:58 PM
> 

We're talking about theoretically, right?  So theoretically the new offer can be big - bigger than can fit over UDP, for example, and thus be rejected by a proxy on the way to the UAS, and the UAS may never get the PRACK.
Of course this is really just theory anyway, and my guess is if a PRACK delivery fails then the call is on a guaranteed path to failure anyway.

> > It can also carry a Require/Proxy-Require header and be rejected due to
> that, not that I can think of why that would realistically ever be an
> issue for PRACK.
> 

Yes, in hindsight that's probably all we should have ever allowed a PRACK to do.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Apr 2009 23:13:25 -0400

I can't help but think this is really a red herring.  If you think about a PRACK as a glorified ACK, what value does challenging it really give?  I mean you can't challenge an ACK, yet life seems ok.  The dialog identifiers have to match anyway, and exactly how maliciously useful is it for a true MITM to fake PRACK a response??

Besides, the whole discussion of this is rather warped.  The UAS is not in a position to decide whether to stop response re-transmissions, unless it actually *receives* the PRACK.  So if a Proxy challenged it, there's no point in saying the UAS should or shouldn't retransmit responses - of course it will retransmit them, because it doesn't know any better.  And if the PRACK was challenged, the UAC has to send it again with a challenge-response if it can.  Am I missing something?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Tuesday, March 31, 2009 2:40 PM
> 
> Christer Holmberg wrote:
> >
> > Hi,
> >
> > non-200 response would cease re-transmission of the assoicated reliable
> > 18x response.
> >
> > 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.
> >
> 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

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 06:26:54 +0200

Hi, 

>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.
>

Well, rejecting an SDP offer is one use-case we've discussed.

The PRACK could also be rejected due to some overload situation etc.

Regards,

Christer

2009/4/1 Paul Kyzivat <[email-masked]>:
> important

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 06:31:49 +0200

Hi, 

>Rejecting that offer in the PRACK with a 4xx by the UAS should not impact the assertion that the 1xx has reached its 
>destination.

True. But the UAC doesn't know whether the UAS, or some intermediate, rejected the offer.

>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

>> 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.
>> >
>> >>> 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".
>> >>>
>> >>> 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.
>> >>>
>> >>> thinks that a non-200 response DOES cease the re-transmission of 
>> >>> the associated reliable 18x response, please indicate so.
>> >>
>> credentials.
>> >> 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
>> [email-masked] for questions on current sip Use

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 2 Apr 2009 01:41:40 -0400

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Hadriel Kaplan
>Sent: Thursday, April 02, 2009 8:41 AM
>To: Hisham Khartabil
>Cc: [email-masked]; Paul Kyzivat (pkyzivat); 
>[email-masked]; Holmberg

That's what PRACK does in *most* of the use cases. I think having PRACK
carry an updated offer sdp was allowed/required for precondition call
flow. So in that sense what happens to 18x retransmission when PRACK's
offer is rejected is not a widely used case. But Prack can be rejected
for other reasons, and I think handling in UAC & UAS of a Prack error
should be same, no matter what the cause of error is.

Sanjay 

>[email-masked] for questions on current sip

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 2 Apr 2009 16:53:01 +1100

> True. But the UAC doesn't know whether the UAS, or some intermediate, rejected the offer.

Yeah, that's not the issue. 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.

Hisham

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 08:03:11 +0200

Hi, 

>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

>>> > From: [email-masked] [mailto:[email-masked]] 
>>> > On
>>> Behalf Of Hisham Khartabil
>>> 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.
>>> >
>>> >>> 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.
>>> >>>
>>> > sip-

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 2 Apr 2009 17:07:09 +1100

Are you talking about retransmitting of PRACK or 1xx?

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 08:10:33 +0200

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:[email-masked]] 
Sent: Thursday, April 02, 2009 7:07 AM
To: Christer Holmberg
Cc: Hadriel Kaplan; Rockson Li (zhengyli); Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [Sipping] PRACK: Does non-200 response cease re-transmission ofreliable 18x?

2009/4/2 Christer Holmberg <[email-masked]>:
>>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.
>>
>>>> >>> some people seemed to have an issue with that, so I was asked 
>>>> >>> to "take it to the
>>>> list".
>>>> >>>
>>>> >>> 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.
>>>> >>
>>>> >> used in the original INVITE finally becomes stale by the time 
>>>> >> the PRACK is
>>>> received.
>>>> >>
>>>> >>        Thanks,
>>>> >>        Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 09:10:43 +0200

Hi,
   
>Questions: 
> 
>1. Is this argument arised because that the prack carrys a new offer?  
 
That is what initially triggered thee discussion, but since then I think we have realized that there can be other reasons why a PRACK gets rejected. 

>2. Is there a use-case the prack must contain a new offer?  
 
Not as far as I know. You can always use UPDATE - assuming that you support UPDATE, that is.
 
Regards,
 
Christer

"Christer Holmberg" <[email-masked]> 
发件人:  [email-masked] 

2009-04-02 14:10 

收件人
"Hisham Khartabil" <[email-masked]> 
抄送
[email-masked], "Paul Kyzivat \(pkyzivat\)" <[email-masked]> 
主题
Re: [Sipping] PRACK: Does non-200 response cease re-transmission        ofreliable 18x?

1xx.

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Thu, 2 Apr 2009 15:01:33 +0800

Hi,

  Questions:

收件人
"Hisham Khartabil" <[email-masked]>
抄送
[email-masked], "Paul Kyzivat \(pkyzivat\)" <[email-masked]>
主题
Re: [Sipping] PRACK: Does non-200 response cease re-transmission 
ofreliable 18x?

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:[email-masked]] 
Sent: Thursday, April 02, 2009 7:07 AM
To: Christer Holmberg
Cc: Hadriel Kaplan; Rockson Li (zhengyli); Paul Kyzivat (pkyzivat); 
[email-masked]
Subject: Re: [Sipping] PRACK: Does non-200 response cease re-transmission 
ofreliable 18x?

2009/4/2 Christer Holmberg <[email-masked]>:
> 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.
> 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.

---

From: [email-masked]
Date: Thu, 2 Apr 2009 15:41:41 +0800

Hi Christer,

  Thanks for your answers.

  Is the other scenario raised by Paul below? 

     -> INVITE
     <- 180rel
     -> PRACK
     <- 401
  And are there any other cases?IMO, only prack with new offer could cause 
this problem.

  Also another question:

  Is the flows below valid according to recent arguments?

  UAC                  UAS
   |----invite(SDP)--->|
   |<--- 183(SDP)------|
   |-----prack(SDP)--->|
   |<--- 200(SDP)------|
 
      flow 1
UAC                  UAS
   |----invite-------->|
   |<--- 183-----------|
   |-----prack(SDP)--->|
   |<--- 200(SDP)------|
 
      flow 2

Regards,
Eric

2009-04-02 15:10

收件人
<[email-masked]>
抄送
"Hisham Khartabil" <[email-masked]>, "Paul Kyzivat (pkyzivat)" 
<[email-masked]>, <[email-masked]>, <[email-masked]>
主题
RE: [Sipping] PRACK: Does non-200 response cease re-transmission 
ofreliable 18x?

Hi,
   
>1. Is this argument arised because that the prack carrys a new offer?  
 
That is what initially triggered thee discussion, but since then I think 
we have realized that there can be other reasons why a PRACK gets 
rejected. 

>2. Is there a use-case the prack must contain a new offer?  
 
Not as far as I know. You can always use UPDATE - assuming that you 
support UPDATE, that is.
 
Regards,
 
Christer

收件人

1xx.

-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]] 
Sent: Thursday, April 02, 2009 7:07 AM
To: Christer Holmberg
Cc: Hadriel Kaplan; Rockson Li (zhengyli); Paul Kyzivat (pkyzivat); 
[email-masked]

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 09:49:51 +0200

Hi,

>And are there any other cases?IMO, only prack with new offer could
cause this problem. 
 
A SIP request can be rejected e.g. because the UAS is overloaded. 
 
I don't we can assume that a PRACK will never be rejected, and as long
as it may be rejected we need to know how to handle it.

>Is the flows below valid according to recent arguments? 
 
Assuming the 200 is the PRACK response, yes.
 
>    |----invite-------->| 
 
Not valid. If the INVITE does not contain SDP, a reliable answer must
contain SDP. We are currently discussing whether the FIRST reliable
response must contain SDP, or whether that rule can be related. But,
that is a separate thread.
 
Regards,
 
Christer

---

From: [email-masked]
Date: Thu, 2 Apr 2009 16:11:08 +0800

Hi,

> I don't we can assume that a PRACK will never be rejected, and as 
> long as it may be rejected we need to know how to handle it.

If UAS is overloaded, the UAS may have difficult in proceeding all message
such as invite, 180, update ,prack...Then omitting the prack may be 
implemented 
by the UAS.

Regards,
Eric

> Not valid. If the INVITE does not contain SDP, a reliable answer 
> must contain SDP. We are currently discussing whether the FIRST 
> reliable response must contain SDP, or whether that rule can be 
> related. But, that is a separate thread.
> 
> Regards,
> 
> Christer
> 
>

---

From: Brett Tate <[email-masked]>
Date: Thu, 2 Apr 2009 05:28:13 -0700

> That's a good scenario. Any others?

See RFC 3262 tables 1 and 2: 100, 407, 415, 420, 500, 503, and etcetera.

In case anyone cares to glance at them, there were numerous discussions early last year which led to the PRACK 488 open issues being added to the draft-ietf-sipping-sip-offeranswer-06.

http://www.ietf.org/mail-archive/web/sipping/current/msg15031.html

http://www.ietf.org/mail-archive/web/sipping/current/msg15146.html

> 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.

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.

Similarly the UAC doesn't know if the UAS allowed the PRACK to be fully processed if a non-481 failure response (such as 401, 500, 503, 415, 420, and 488) was returned.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Apr 2009 11:22:41 -0400

> that is a separate thread.

Hmm. That flow is a consequence of changing that rule that I had not 
previously considered.

Allowing flow 2 would cause all sorts of trouble. If the restriction on 
offer in first reliable provisional is to be relaxed it must be sure to 
state that the first offer must then be in *some* reliable provisional, 
and until that is sent there can be no offer sent another way (PRACK or 
UPDATE).

Just opening that question is enough to make me more concerned about 
relaxing the constraint.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Apr 2009 11:31:14 -0400

While there may be cases when it would be ok to stop retransmitting the 
reliable provisional after rejecting the PRACK, I am very reluctant to 
start special casing this. That just adds complexity and the potential 
for implementation screwups, and for what benefit? Since everybody seems 
to agree that the case will rarely arise, the cost of the extra 
retransmissions will also arise rarely. So if there is even one case 
where the prack might be rejected by the UAS, continuing the 
retransmissions in that case seems the conservative thing to do.

And if we are talking about backward compatibility, this won't affect 
any UAS that currently lacks a code path to reject a PRACK.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 18:57:13 +0200

Hi, 

previously considered.
>Allowing flow 2 would cause all sorts of trouble. If the restriction on
offer in first reliable provisional is to be 
>relaxed it must be sure to state that the first offer must then be in
*some* reliable provisional, and until that is sent 
>there can be no offer sent another way (PRACK or UPDATE).
>
relaxing the constraint.

I am not proposing to allow flow 2, and I don't think relaxing the rule
would allow it either. The rule would say that if the INVITE does not
contain an SDP offer the SDP offer must be carried in a reliable
response. The PRACK can only contain an SDP offer if the UAC has receied
an SDP answer.

Regards,

Christer

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 3 Apr 2009 09:22:01 +1100

> 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 over analyse its response.

> Similarly the UAC doesn't know if the UAS allowed the PRACK to be fully processed if a non-481 failure response (such as 401, 500, 503, 415, 420, and 488) was returned.

What's fully processed? Don't confuse the offer/answer when the 1xx
PRACK. The PRACK is to acknowledge that a 1xx has been received. If
the PRACK carries SDP, then let your offer/answer state machine handle
it. So:

- If the UAC sent a offer, it needs an answer regardless which message
carries that answer
- If the UAC sent an answer, then if needs to send an answer if it
received an offer. It can carry that answer in any message it is
sending back.

Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Apr 2009 19:07:51 -0400

> received an offer. It can carry that answer in any message it is

Its not true that it can send an answer in any message it is sending back.

I started out with that belief many years ago, at the beginning of the 
process that led to the o/a draft. After *much* discussion and reading 
of the tea leaves in RFCs, it was concluded (for good reason) that 
offers and answers can only be carried in certain patterns of messages.

But that is off the subject of this current thread.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 3 Apr 2009 09:30:23 +0200

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.
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?

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 3 Apr 2009 12:10:11 +0200

Adam, I think you also had an issue regarding the proposal that a
non-200 response would not cease the re-transmission of 18x?

Since we ran out of time at the meeting I never really understood what
the issue was, so could you please repeat it?

Thanks!

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Fri, 3 Apr 2009 05:15:01 -0700

> >> 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 response to a PRACK.  The PRACK has 
> >> served its purpose.
> >
> > 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. 

It is if the UAC would like successfully deliver a PRACK.

> The only reason a PRACK has a response is because you 
> had to fit it into one of the state machines defined in
> RFC3261. 

It was to remain backward compatible to the RFC2543 concerning proxy interactions.  Proxies (and other middle boxes) compliant with RFC3261 (or RFC2543) can return failure responses such as 407, 500, 503, 415, 420, and 488.

> That doesn't mean we go a over analyze its response.

The analyses is no more complex than typical in dialog response beyond recognition that the call might fail if the UAC does try a little harder to successfully deliver the PRACK.  If a failure is received, the UAC needs to decide if it can and/or should resubmit the request with higher cseq (or fork request per rfc3263 upon 503).

> > Similarly the UAC doesn't know if the UAS allowed the PRACK 
> > to be fully processed if a non-481 failure response (such as 
> > 401, 500, 503, 415, 420, and 488) was returned.
> 
> What's fully processed?

1) Stopped 18x retries.

2) Considers 18x with offer (or answer) SDP successfully delivered to avoid queuing subsequent INVITE 18x, INVITE 2xx, and etcetera.

3) Honored PRACK delivered content adjustments per whatever the specifications allow.

---

From: Adam Roach <[email-masked]>
Date: Fri, 03 Apr 2009 13:39:03 -0500

> non-200 response would not cease the re-transmission of 18x?

I agree that a UAC can't *count* on a non-200 response stopping the 
provisional retransmission, since the error may have come from an 
intermediary. Of course, if the error has an obvious recovery path (e.g. 
407), then the UAC should attempt recovery (largely because it doesn't 
know whether the error came from the UAS or from an intermediary).

However, if the PRACK makes it all the way to the UAS, reliability has 
been achieved. Continued retransmission of the provisional response by 
the UAS at that point provides no benefit. It does, however, consume 
gratuitous bandwidth. (The UAS does need to deal with the possibility 
that the UAC will re-attempt the PRACK, however).

Otherwise, you just have the UAS yelling, "I Want My Acknowledgment!" 
and the UAC yelling back "You Have Your Acknowledgment!" over and over.

/a

---

From: Brett Tate <[email-masked]>
Date: Fri, 3 Apr 2009 12:08:23 -0700

> However, if the PRACK makes it all the way to the UAS, 
> reliability has been achieved. Continued retransmission 
> of the provisional response by the UAS at that point 
> provides no benefit.

It clearly indicates "I Still Want My Acknowledgment!".  However I have no problem with UAS optionally stopping the retries (if PRACK passes authorization) and continue to time awaiting the new PRACK. 

> Otherwise, you just have the UAS yelling, "I Want My 
> Acknowledgment!" and the UAC yelling back "You Have 
> Your Acknowledgment!" over and over.

The UAC does not yell back "You Have Your Acknowledgment!" upon receiving a 18x retry.  Per rfc3262 section 4, the 18x must be discarded.

If appropriate and able to yell back again upon receiving a PRACK failure response, UAC should do so regardless of the UAS retrying the 18x (i.e. indicating "I Still Want My Acknowledgment!").

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 4 Apr 2009 00:23:17 +0200

Hi, 

>I agree that a UAC can't *count* on a non-200 response stopping the
provisional retransmission, since the error may have 
>come from an intermediary. Of course, if the error has an obvious
recovery path (e.g. 
>407), then the UAC should attempt recovery (largely because it doesn't
know whether the error came from the UAS or from 
>an intermediary).
been achieved. Continued retransmission of the 
>provisional response by the UAS at that point provides no benefit. It
does, however, consume gratuitous bandwidth. (The 
>UAS does need to deal with the possibility that the UAC will re-attempt
the PRACK, however).
>and the UAC yelling back "You Have Your Acknowledgment!" over and over.

I guess it doesn't hurt if the UAS chooses to stop the re-transmission
in case it sends a non-200 response.

But, in thaht case the UAS needs to "remember" for which 18x it sent a
non-200 response to the PRACK, and be able to deal with a new PRACK
(sent by the UAC which received the non-200 response) as if the 18x had
NOT yet been acknowledged.

Regards,

Christer

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 6 Apr 2009 09:37:29 +1000

> 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

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Apr 2009 07:27:19 +0200

Hi,
 
>>>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?
> 
>unacknowledged reliable provisional response, the UAS MUST 
>respond to the PRACK with a 481 response.  If the PRACK does match an

Yes. 

>without reception of a corresponding PRACK, the UAS SHOULD 
>reject the original request with a 5xx response."

Yes.

>"Note that the PRACK is like any other non-INVITE request within a
>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

---

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

> that the UAC will re-attempt the PRACK, however).

Adam's response seems to be the obvious solution to this problem.  The
only thing I would clarify is that if the UAC sends a PRACK which
receives a 4xx response, and the UAS *didn't* send the response, the UAC
will discover this directly by receiving another copy of the reliable
provisional response, and then the UAC will then know that it has to
send a new PRACK acknowledging that reliable provisional resopnse.

I admit that this may have complicated interactions with the
offer/answer model, but otherwise, it seems straightforward, and indeed,
it seems to be the only solution.

But perhaps I am overlooking something.

Dale