Subject: Re: [Sipping] PRACK: Change MUST requirement to include SDP offer in first reliable provisional response

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Mon, 6 Apr 2009 12:52:57 +0800

I totally agree with Hadriel's insight here.

It should have been avoided to put too many jobs into PRACK, 

I miss KISS(Keep It Simple and Stupid) principle 

Regards,

-Rockson

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Tuesday, March 31, 2009 9:50 PM
To: Christer Holmberg; [email-masked]
Subject: Re: [Sipping] PRACK: Change MUST requirement to include SDP
offer in first reliable provisional response

In hindsight I'm thinking we probably also shouldn't have made the SDP
answer (or another offer) required or even possible in the PRACK either.
I think it should have been for one and only one purpose: to acknowledge
receipt of the provisional response.  

-hadriel

---

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

Hi,

We discussed that at one point.

However, I think that is more related to how-to-reject-an-offer-in-PRACK
thread. This is about whether the first reliable provisional response
must contain an SDP offer.

Regards,

Christer 

	From: Rockson Li (zhengyli) [mailto:[email-masked]] 
	Sent: 6. huhtikuuta 2009 7:53
	To: Hadriel Kaplan; Christer Holmberg; [email-masked]
	Subject: RE: [Sipping] PRACK: Change MUST requirement to include
SDP offer in first reliable provisional response

	Regards,

	-Rockson

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hadriel Kaplan
	Sent: Tuesday, March 31, 2009 9:50 PM
	To: Christer Holmberg; [email-masked]
	Subject: Re: [Sipping] PRACK: Change MUST requirement to include
SDP offer in first reliable provisional response

	In hindsight I'm thinking we probably also shouldn't have made
the SDP answer (or another offer) required or even possible in the PRACK
either.  I think it should have been for one and only one purpose: to
acknowledge receipt of the provisional response.  

	-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Apr 2009 08:16:24 -0400

I think I also agree. There are a lot of things that in hindsight we 
probably would have done differently. But that is water over the dam. We 
are where we are.

	Paul

Rockson Li (zhengyli) wrote:
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Hadriel Kaplan
> *Sent:* Tuesday, March 31, 2009 9:50 PM
> *To:* Christer Holmberg; [email-masked]
> *Subject:* Re: [Sipping] PRACK: Change MUST requirement to include SDP 
> In hindsight I’m thinking we probably also shouldn’t have made the SDP 
> answer (or another offer) required or even possible in the PRACK 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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: [email-masked]
Date: Tue, 7 Apr 2009 08:31:05 +0800

I also agree it.

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2009-04-06 20:16

收件人
"Rockson Li (zhengyli)" <[email-masked]>
抄送
[email-masked], Christer Holmberg <[email-masked]>
主题
Re: [Sipping] PRACK: Change MUST requirement to include SDP offer in first 
reliable provisional response

                 Paul

--------------------------------------------------------
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: Tue, 7 Apr 2009 09:32:45 +0800

More points of view to this question:

By RFC3262: 
1. "Retransmissions of the reliable provisional response cease when a 
matching PRACK is received by the UA core."

2. "If the PRACK does match an unacknowledged reliable provisional 
response, it MUST be responded to
   with a 2xx response."

So, when UAs receive a matching PRACK, it will stop re-transmit the 
reliable provisional response(18x). And the response
to PRACK MUST be 2xx.

It is simple and clear. And when UAs receive non-2xx response to PRACK, it 
is clear that the other side do not receive the
PRACK. It can send a new PRACK(CSeq++, the same RAck).

And now, we can use PRACK to send "precondition notification" and "codec 
refine". When we need to issue session modification like adding codec, 
adding/removing media streams, we MUST using Re-INVITE/UPDATE.

I think we should not re-write RFC3262 to allow the UA to reject the 
PRACK.

收件人

                 Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 09:43:22 +0200

Hi,
 
I think we already a while ago agreed on the principle that it shall be possible to send a non-200 response to a PRACK (not only for offer/answer, but possibly also due to other reasons).
 
And, in that case, why would an intermeidate be allowed to reject a PRACK, but not the UAS?
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 07, 2009 4:33 AM
To: Paul Kyzivat
Cc: [email-masked]; [email-masked]; Christer Holmberg
Subject: [Sipping] 答复: Re: PRACK: Change MUST requirement to include SDP offer in first reliable provisional response

By RFC3262: 
1. "Retransmissions of the reliable provisional response cease when a matching PRACK is received by the UA core." 

2. "If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to 
   with a 2xx response." 

So, when UAs receive a matching PRACK, it will stop re-transmit the reliable provisional response(18x). And the response 
to PRACK MUST be 2xx. 

It is simple and clear. And when UAs receive non-2xx response to PRACK, it is clear that the other side do not receive the 
PRACK. It can send a new PRACK(CSeq++, the same RAck). 

And now, we can use PRACK to send "precondition notification" and "codec refine". When we need to issue session modification like adding codec, 
adding/removing media streams, we MUST using Re-INVITE/UPDATE. 

I think we should not re-write RFC3262 to allow the UA to reject the PRACK. 

2009-04-06 20:16 

收件人
"Rockson Li (zhengyli)" <[email-masked]> 
抄送
[email-masked], Christer Holmberg <[email-masked]> 
主题
Re: [Sipping] PRACK: Change MUST requirement to include SDP offer in        first reliable provisional response

                Paul

---

From: [email-masked]
Date: Tue, 7 Apr 2009 16:32:39 +0800

"Christer Holmberg" <[email-masked]> 
2009-04-07 15:43

收件人
<[email-masked]>, "Paul Kyzivat" <[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: [Sipping] 答复: Re:  PRACK: Change MUST requirement to include SDP 
offer in        first reliable provisional response

Hi,
 
I think we already a while ago agreed on the principle that it shall be 
possible to send a non-200 response to a PRACK (not only for offer/answer, 
but possibly also due to other reasons).

[Gao] Then, it is a modification of RFC3262.
 
And, in that case, why would an intermeidate be allowed to reject a PRACK, 
but not the UAS?

[Gao]  I think, by RFC3262, it is not suitable to put too much usage in 
the PRACK to make it rejectable.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Tuesday, April 07, 2009 4:33 AM
To: Paul Kyzivat
Cc: [email-masked]; [email-masked]; Christer Holmberg
Subject: [Sipping] 答复: Re: PRACK: Change MUST requirement to include SDP 
offer in first reliable provisional response

By RFC3262: 

收件人
"Rockson Li (zhengyli)" <[email-masked]> 
抄送
[email-masked], Christer Holmberg <[email-masked]> 
主题
Re: [Sipping] PRACK: Change MUST requirement to include SDP offer in  
first reliable provisional response

                Paul

--------------------------------------------------------
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: Tue, 7 Apr 2009 10:53:22 +0200

Hi,
 
>[Gao] Then, it is a modification of RFC3262.  
 
Yes.
 
>[Gao]  I think, by RFC3262, it is not suitable to put too much usage in the PRACK to make it rejectable.  
 
Every request is rejectable, no matter how much or little usage you have in it.
  
Regards, 
  
Christer 

By RFC3262: 

2009-04-06 20:16 

收件人

               Paul

---

From: [email-masked]
Date: Tue, 7 Apr 2009 17:07:44 +0800

I mean rejectable in app-level. 491 is beneath app-level.
And precondition notification is not a rejectable usage in app-level.

BTW, I saw some points of view (just today and yesterday) which want to 
make it simple.

2009-04-07 16:53

收件人
<[email-masked]>
抄送
<[email-masked]>, "Paul Kyzivat" <[email-masked]>, 
<[email-masked]>
主题
RE: non-200 response to PRACK (was:  Re:  PRACK: Change MUST requirement 
to include SDP offer in first reliable provisional response)

Hi,

Yes.

Every request is rejectable, no matter how much or little usage you have 
in it.
  
Regards, 
  
Christer 

By RFC3262: 

收件人

               Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 12:36:28 +0200

Hi,

>And precondition notification is not a rejectable usage in app-level.  
 
Ok, so where is all that defined?
 
>BTW, I saw some points of view (just today and yesterday) which want to make it simple.  
 
I also want to make it simple.
 
Saying that something must never happen is a very simple solution. We sould do that for other things also, and our specs would become very short... :)
 
Regards,
 
Christer

Hi, 

Yes. 

  
Regards, 
 
Christer 

By RFC3262: 

2009-04-06 20:16 

收件人

              Paul

---

From: [email-masked]
Date: Tue, 7 Apr 2009 19:05:31 +0800

2009-04-07 18:36

收件人
<[email-masked]>
抄送
<[email-masked]>, "Paul Kyzivat" <[email-masked]>, 
<[email-masked]>
主题
RE: [Sipping] 答复: RE: non-200 response to PRACK (was:  Re:  PRACK: 
Change MUST requirement to include SDP offer in first reliable provisional 
response)

Hi,

[Gao] By RFC3312:  The offerer generates a transaction
   status table, identical to its local status table, and sends it to
   the answerer in the offer.  The answerer uses the information of this
   transaction status table to update its local status table.  The
   answerer also updates the transaction status table fields that were
   out of date and returns this table to the offerer in the answer.  The
   offerer can then update its local status table with the information
   received in the answer.  After this offer/answer exchange, the local
   status tables of both user agents are synchronised. 

The precondition state is just notification/updating, not negotiating.
 
make it simple.  

Saying that something must never happen is a very simple solution. We 
sould do that for other things also, and our specs would become very 
short... :)

[Gao] I am not sure we are talking the same thing :)
I mean that some people do not want modification here.
 
Regards,
 
Christer

Hi, 

Yes. 

  
Regards, 
 
Christer 

By RFC3262: 

收件人

              Paul

---

From: [email-masked]
Date: Tue, 7 Apr 2009 19:07:42 +0800

You attended the last IETF meeting.

And what about the "rollback of Re-INVITE issue"?

Thanks.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 13:33:17 +0200

Hi,
 
>The precondition state is just notification/updating, not negotiating.  
 
And where is it said that a notification/updating request cannot be rejected?
 
I have nothing against recommending that PRACKs are only used for notifications etc, but I don't think that will ensure that a PRACK is never rejected.

>I mean that some people do not want modification here.  
 
I am only talking based on agreements we have made. If the group decides to change those agreements - fine.
  
Regards, 
  
Christer 

Hi, 

Yes. 

 
Regards, 

Christer 

By RFC3262: 

2009-04-06 20:16 

收件人

             Paul

---

From: [email-masked]
Date: Tue, 7 Apr 2009 19:40:46 +0800

2009-04-07 19:33

收件人
<[email-masked]>
抄送
"Paul Kyzivat" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
主题
RE: RE: [Sipping] 答复: RE: non-200 response to PRACK (was:  Re:  PRACK: 
Change MUST requirement to include SDP offer in first reliable provisional 
response)

Hi,

>The precondition state is just notification/updating, not negotiating.  
 
And where is it said that a notification/updating request cannot be 
rejected?
 
I have nothing against recommending that PRACKs are only used for 
notifications etc, but I don't think that will ensure that a PRACK is 
never rejected.

[Gao] RFC3262 defines that when UA recv PRACK, it must send 2xx.  As 
RFC3262 defined so, UA MUST NOT send PRACK with rejectable usage.
And as "draft-ietf-sipping-sip-offeranswer" recommending  that PRACKs are 
only used for usage that would not be rejected, I think thing is OK.

make it simple.   
>I mean that some people do not want modification here.  
 
I am only talking based on agreements we have made. If the group decides 
to change those agreements - fine.

[Gao] OK.
  
Regards, 
  
Christer 

Hi, 

Yes. 

 
Regards, 

Christer 

By RFC3262: 

收件人

             Paul

---

From: [email-masked]
Date: Tue, 7 Apr 2009 19:59:12 +0800

Adding something about rejecting.

*pure* preconditon notification is just refreshing state table defined in 
RFC3312. So, *pure* preconditon notification can not be rejected by 
RFC3312.

And I think others in session *modification request* can be rejected, 
including "codec refine"(though "codec refine" almost not be rejected).

收件人
<[email-masked]>
抄送

Hi,

 

make it simple.   

Regards, 
  
Christer 

Hi, 

Yes. 

 
Regards, 

Christer 

By RFC3262: 

收件人

             Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 7 Apr 2009 05:01:42 -0700

> RFC3262 defines that when UA recv PRACK, it must send 2xx.

That is one interpretation of RFC 3262; however other interpretations exist.  The following discusses 2 common interpretations.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Apr 2009 08:59:45 -0400

We could write in an RFC that lead must be turned into gold, but when it
came time to implement that it would be discovered that it wasn't
feasible to always follow the RFC.

The quotes below reflect a similar degree of naivety in 3262, at least
regarding the responses to PRACK. Plenty of examples have been given of
cases where it is inappropriate to return a 200 response.

The statement that retransmissions shall cease when the matching PRACK
is received is, IMO, predicated on the assumption that a 200 will always
be returned. Once you reverse that assumption, then you must also
reconsider this statement.

	Thanks,
	Paul

[email-masked] wrote:
> It is simple and clear. And when UAs receive non-2xx response to PRACK, 
> it is clear that the other side do not receive the
> *Paul Kyzivat <[email-masked]>*

---

From: [email-masked]
Date: Wed, 8 Apr 2009 10:37:11 +0800

I do not think it is naivety of RFC3262.

In theory, there are cases that UAS(PRACK's UAS) should return non-2xx, as 
there is no explicit regulation of what can be in PRACK or not.

But as UAS MUST return 2xx, then we can deduce that it is UAC's obligation 
to make sure UAS will accept the PRACK. If UAS do not obey this, UAC can 
terminate the session. And if UAS want to issue a modification of session 
which may be rejected by UAC, it can use UPDATE later. 

Considering UAC, it can judge from the 4xx to terminate the session(such 
as 481), or send a new PRACK.

And the process mentioned above just obeys RFC3262, and it practical 
enough for the usage. 
I can accept the UAC judging from the 4xx to terminate the session(such as 
481), or send a new PRACK. But I think considering the UAS rejecting the 
PRACK and retransmiting 18x(100rel) would make the problem too complex. 

Thanks 
Gao

2009-04-07 20:59

收件人
[email-masked]
抄送
Christer Holmberg <[email-masked]>, [email-masked], 
[email-masked], "Rockson Li (zhengyli)" <[email-masked]>
主题
Re: 答复: Re: [Sipping] PRACK: Change MUST requirement to include SDP 
offer in first reliable provisional response

                 Thanks,
                 Paul

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Apr 2009 00:37:40 -0400

[email-masked] wrote:
> In theory, there are cases that UAS(PRACK's UAS) should return non-2xx, 
> as there is no explicit regulation of what can be in PRACK or not.
> 
> But as UAS MUST return 2xx, then we can *deduce* that it is UAC's 
> obligation to make sure UAS will accept the PRACK. If UAS do not obey 
> this, UAC can terminate the session. And if UAS want to issue a 
> modification of session which may be rejected by UAC, it can use UPDATE 
> later.

You have an opinion of what the UAS needs to do to resolve the
inadequacies of 3262, and I have a different opinion about that. That is
why we are discussing it. And I expect there are yet other opinions.
That is why we are discussing it.

IMO there are cases where a non-2xx response is called for, and
terminating the session is an unreasonable remedy. The one I have given
is where an Authorization header is included but the nonce has expired.
There is no other way for the UAC to learn that it needs a new nonce,
and having the session fail in that case is unreasonable. I'm sure there
are other cases as well.

> as 481), or send a new PRACK.

If you acknowledge that the UAS may have need to send a non-2xx
response, and the UAC may then want to retransmit the PRACK, then it
seems you are agreeing with me.

> I can accept the UAC *judging from the 4xx to terminate the session(such 
> as 481), or send a new PRACK. But I think considering the UAS rejecting 
> the PRACK and retransmiting 18x(100rel) would make the problem too 
> complex. *

What is so hard?

	Thanks,
	Paul

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

---

From: [email-masked]
Date: Wed, 8 Apr 2009 13:22:55 +0800

Hi

inline:)

> and having the session fail in that case is unreasonable. I'm sure there

[Gao] If we adding more usage to PARCK, I'm sure there are other cases as 
well too.
My point is that we can do the thing with another UPDATE, while not the 
PRACK.

I think this is not a dialectic problem, it is just choice. So, I would 
not stick to my personal ponit of view if people want to making PRACK with 
more usage.

> > complex. 

[Gao] No hard, just complex :)

> >  >  > Sipping mailing list 
https://www.ietf.org/mailman/listinfo/sipping

> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> 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.
system.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Apr 2009 07:39:41 +0200

What PRACK usages are we adding??? 
 
We are talking about being allowed to send a non-200 response to a PRACK, and how to deal with it.
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 8. huhtikuuta 2009 8:23
	To: Paul Kyzivat
	Cc: Christer Holmberg; [email-masked]; [email-masked]; Rockson Li (zhengyli)
	Subject: 答复: Re: 答复: Re: 答复: Re: [Sipping] PRACK: Change MUST requirement to include SDP offer in first reliable provisional response

	Hi 
	
	inline:) 

	> and having the session fail in that case is unreasonable. I'm sure there
	
	[Gao] If we adding more usage to PARCK, I'm sure there are other cases as well too. 
	My point is that we can do the thing with another UPDATE, while not the PRACK. 
	
	I think this is not a dialectic problem, it is just choice. So, I would not stick to my personal ponit of view if people want to making PRACK with more usage.

---

From: Brett Tate <[email-masked]>
Date: Wed, 8 Apr 2009 04:17:54 -0700

> Considering UAC, it can judge from the 4xx to terminate 
> the session (such as 481), or send a new PRACK.

The PRACK 481 should not automatically terminate the dialog usage.

Since avoiding the sending of PRACK 481 (after sending PRACK 488 and similar failure responses) is an open issue within draft-ietf-sipping-sip-offeranswer-10 section 6.1, I thought that I'd mention the RFC 3262 text and potentially missing RFC 5057 text concerning PRACK 481.

RFC 3262 section 3 indicates to send PRACK 481 similar to sending CANCEL 481.  The 481 should not automatically terminate the usage since the UAS is not necessarily indicating that the dialog does not exist.

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

Unfortunately RFC 5057 section 5.1 note 8 only appears to discuss the special consideration for CANCEL instead of also discussing PRACK.

"The 481 response to a CANCEL request has to be treated differently.  For CANCEL, a 481 means the UAS can't find a matching transaction.  A 481 response to a CANCEL affects only the CANCEL transaction.  The usage associated with the INVITE is not affected."

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Apr 2009 08:04:27 -0400

[email-masked] wrote:
> 
> Please see the previous mail:
> 
> as UAS MUST return 2xx, then we can *deduce* that it is UAC's obligation 
> to make sure UAS will accept the PRACK.

I think that in general we can presume that the UAC doesn't *expect*
that its PRACK will be rejected. Yet the PRACK can fail for no fault on
the part of the UAC, and no fault on the part of the UAS either.

I've already given the example of authorization failure.

Its simply a faulty spec that presumes it can ignore the possibility of
errors. All we are trying to do is *fix* that so that things will
continue to function in a predictable way in the face of an error.

Would you honestly recommend that the UAS return a 200 when it has not
been able to process the PRACK due to an error?

	Thanks
	Paul

> *"Christer Holmberg" <[email-masked]>*
> 
> 2009-04-08 13:39
> 
> 	
> 收件人
> 	<[email-masked]>, <[email-masked]>, "Rockson Li (zhengyli)" 
> <[email-masked]>
> 主题
> 	RE: Re: 答复: Re: 答复: Re: [Sipping] PRACK: Change MUST requirement to 
> include SDP offer in first reliable provisional response
> 
> 
> 	
> 
> 
> 
> 
> 
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* 8. huhtikuuta 2009 8:23*
> To:* Paul Kyzivat*
> Cc:* Christer Holmberg; [email-masked]; [email-masked]; 
> Rockson Li (zhengyli)*
> Subject:* 答复: Re: 答复: Re: 答复: Re: [Sipping] PRACK: Change MUST 
> requirement to include SDP offer in first reliable provisional response
> 
> 
> Hi
> 
> inline:)
> 
> 
> not stick to my personal ponit of view if people want to making PRACK 
> with more usage.
> 
> 
> is confidential. Recipients named above are obligated to maintain 
> secrecy and are not permitted to disclose the contents of this 
> communication to others.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Apr 2009 08:12:26 -0400

Brett,

That's a good point. What would you like to see done about it?

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 8 Apr 2009 05:50:12 -0700

Hi Paul,

Concerning PRACK 488 text within draft-ietf-sipping-sip-offeranswer, I don't have a strong opinion as long as RFC 3262 is adequate to avoid interoperability problems upon sending/receiving PRACK 481. 

If needed to avoid interoperability problems, the draft should indicate that UAS should avoid sending PRACK 481 if receives PRACK resubmit with higher cseq (and appropriate content modifications) attempting to obtain a PRACK 2xx after UAS sent prior PRACK 488.  Concerning resubmitting PRACK because of 488, the draft should highlight that a 481 may be received by UAC; it should highlight that the 481 is potentially because of prior PRACK satisfying the UAS instead of the dialog usage being unknown.

Concerning RFC 5057, I'd like the errata for section 5.1 note 8 to discuss PRACK 481 applying to transaction (similar to CANCEL) instead of usage.  However my comment is mainly for interoperability reasons since RFC 5057 is informational (i.e. it did not update RFC 3262).

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, April 08, 2009 8:12 AM
> To: Brett Tate
> Cc: [email-masked]
> Subject: Re: [Sipping] PRACK 481 (was RE: 答复: Re: 答复: Re: PRACK: Change
> MUST requirement to include SDP offer in first reliable provisional
> response)
> 
> Brett,
> 
> > Since avoiding the sending of PRACK 481 (after sending PRACK 488 and
> similar failure responses) is an open issue within draft-ietf-sipping-sip-
> offeranswer-10 section 6.1, I thought that I'd mention the RFC 3262 text
> and potentially missing RFC 5057 text concerning PRACK 481.
> >
> > RFC 3262 section 3 indicates to send PRACK 481 similar to sending CANCEL
> 481.  The 481 should not automatically terminate the usage since the UAS
> is not necessarily indicating that the dialog does not exist.
> >
> > "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."
> >
> > Unfortunately RFC 5057 section 5.1 note 8 only appears to discuss the
> special consideration for CANCEL instead of also discussing PRACK.
> >
> > "The 481 response to a CANCEL request has to be treated differently.
> For CANCEL, a 481 means the UAS can't find a matching transaction.  A 481
> response to a CANCEL affects only the CANCEL transaction.  The usage
> associated with the INVITE is not affected."
> >

---

From: [email-masked]
Date: Wed, 8 Apr 2009 13:42:43 +0800

as UAS MUST return 2xx, then we can deduce that it is UAC's obligation to 
make sure UAS will accept the PRACK.

收件人

We are talking about being allowed to send a non-200 response to a PRACK, 
and how to deal with it.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] 
Sent: 8. huhtikuuta 2009 8:23
To: Paul Kyzivat
Cc: Christer Holmberg; [email-masked]; [email-masked]; Rockson 
Li (zhengyli)
Subject: 答复: Re: 答复: Re: 答复: Re: [Sipping] PRACK: Change MUST 
requirement to include SDP offer in first reliable provisional response

Hi 

inline:) 

> > intended solely for the use of the individual or entity to whom they 
are 

system.

---

From: [email-masked]
Date: Thu, 9 Apr 2009 09:45:04 +0800

Hi,

I just mean:

All the usage can be used in PRACK, we call it Set.
By current RFC3262, can be used in PRACK, we call it SubSet1.
SubSet1 is very small. And if we do usage beyond SubSet1, the termination 
of session is acceptable (for me).
So, I recommend that the UAS return a 200 when it has not been able to 
process the PRACK due to an error, then terminate the session.

About authorization, I think, we can do authorization in PRACK(It is a 
choice, not mandatory thing.), but we should do not do it in PRACK by 
current RFC3262.

If people want to enrich SubSet1, I think it is needed to modify RFC3262 
and find a way to solve the problem.

Thanks
Gao

BTW: the mail thread is bigger than 40KB, I just send a mail bigger than 
40KB.
Propose people cut the mail short :)

---

From: [email-masked]
Date: Thu, 9 Apr 2009 09:37:58 +0800

Hi,

I just mean:

Thanks
Gao

> > [Gao] If we adding more usage to PARCK, I'm sure there are other cases 

> > as well too.
> >  > > is received is, IMO, predicated on the assumption that a 200 will 

> > always
> >  > >  > 1. "Retransmissions of the reliable provisional response cease 

> > when a
> >  > >  > It is simple and clear. And when UAs receive non-2xx response 
to 
> > PRACK,
> >  > >  > refine". When we need to issue session modification like 
adding 
> > codec,
> >  > >  > I think we should not re-write RFC3262 to allow the UA to 
reject 
> > the
> >  > >  >                  Re: [Sipping] PRACK: Change MUST requirement 
to
> >  > >  > probably would have done differently. But that is water over 
the 
> > dam. We
> >  > >  >  > In hindsight I’m thinking we probably also shouldn’t have 

> > made the SDP
> >  > > maintain secrecy and are not permitted to disclose the contents 
of 
> > this
> >  > > originator of the message. Any views expressed in this message 
are 
> > those
mail 
are 
system.
system.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 06:56:40 +0200

Propose people use an appropriate subject.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 9. huhtikuuta 2009 4:45
	To: Paul Kyzivat
	Cc: [email-masked]; [email-masked]; Christer Holmberg
	Subject: [Sipping] 答复: Re: 答复: RE: Re: 答复: Re: 答复: Re: PRACK: Change MUST requirement to include SDP offer in first reliable provisional response

	Hi, 
	
	I just mean: 
	
	All the usage can be used in PRACK, we call it Set. 
	By current RFC3262, can be used in PRACK, we call it SubSet1. 
	SubSet1 is very small. And if we do usage beyond SubSet1, the termination of session is acceptable (for me). 
	So, I recommend that the UAS return a 200 when it has not been able to process the PRACK due to an error, then terminate the session. 
	
	About authorization, I think, we can do authorization in PRACK(It is a choice, not mandatory thing.), but we should do not do it in PRACK by current RFC3262. 
	
	If people want to enrich SubSet1, I think it is needed to modify RFC3262 and find a way to solve the problem. 
	
	Thanks 
	Gao 

	BTW: the mail thread is bigger than 40KB, I just send a mail bigger than 40KB. 
	Propose people cut the mail short :)

---

From: [email-masked]
Date: Thu, 9 Apr 2009 13:18:38 +0800

Hi,

Thanks for your remind :)

But the two subject has association: this one is your proposed subject's 
precondition.

If we can accept all 200OK of PRACK, non-200 lead to termination of 
session, why next?

2009-04-09 12:56

收件人
<[email-masked]>, "Paul Kyzivat" <[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE:  [Sipping] non-200 response to PRACK

Subject: [Sipping] 答复: Re: 答复: RE: Re: 答复: Re: 答复: Re: PRACK: 
response

Hi, 

I just mean: 

Thanks 
Gao

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 07:56:50 +0200

Hi,
 
>But the two subject has association: this one is your proposed subject's precondition. 
>
>If we can accept all 200OK of PRACK, non-200 lead to termination of session, why next? 

Sure. If we decide that a non-200 response would terminate the session we don't need to worry about whether a non-200 response terminates the re-transmission of the reliable response or not.

But, I don't think we have an agreement on that. The current agreement is that it IS allowed to send a non-200 response, so therefor I think it is also ok to discuss how the re-transmission would be affected.

And, even if we would agree that a non-200 response would terminate the session, I still think it would be an update to RFC3262. We would also need to describe HOW the session is terminated, ie by error responses, BYE/CANCEL etc. You cannot now assume that the UAS will send an error response to the INVITE, and terminate the session that way, if e.g. the error response to the PRACK was sent by an intermediate. And, you cannnot assume that an intermediate which sends an error response to a PRACK would start sending BYEs/CANCELs. The intermeidate may not have any knowledge of PRACK - it rejects it e.g. due to overload.

Regards,

Christer

		收件人

	Hi, 
	
	I just mean: 

	
	
	Thanks 
	Gao

---

From: [email-masked]
Date: Thu, 9 Apr 2009 14:06:41 +0800

"Christer Holmberg" <[email-masked]> 写于 2009-04-09 
13:56:50:

> Sure. If we decide that a non-200 response would terminate the 
> session we don't need to worry about whether a non-200 response 
> terminates the re-transmission of the reliable response or not.
> 
> But, I don't think we have an agreement on that. The current 
> agreement is that it IS allowed to send a non-200 response, so 
> therefor I think it is also ok to discuss how the re-transmission 
> would be affected.
> 

[Gao] Is the agreement you mentioned reached during the IETF meeting?

> 
> And, even if we would agree that a non-200 response would terminate 
> the session, I still think it would be an update to RFC3262. We 
> would also need to describe HOW the session is terminated, ie by 
> error responses, BYE/CANCEL etc. You cannot now assume that the UAS 
> will send an error response to the INVITE, and terminate the session
> that way, if e.g. the error response to the PRACK was sent by an 
> intermediate. And, you cannnot assume that an intermediate which 
> sends an error response to a PRACK would start sending BYEs/CANCELs.
> The intermeidate may not have any knowledge of PRACK - it rejects it
> e.g. due to overload.
> 

[Gao] Yes. But it is just complementarity, not overthrow.

> On Behalf Of [email-masked]
>    Subject: [Sipping] 答复: Re: 答复: RE: Re: 答复: Re: 答复: Re: 
> PRACK: Change MUST requirement to include SDP offer in first 
>    SubSet1 is very small. And if we do usage beyond SubSet1, the 
> termination of session is acceptable (for me). 
>    So, I recommend that the UAS return a 200 when it has not been 
> able to process the PRACK due to an error, then terminate the session. 
> 
>    About authorization, I think, we can do authorization in PRACK(It
> is a choice, not mandatory thing.), but we should do not do it in 
> PRACK by current RFC3262. 
> 
>    If people want to enrich SubSet1, I think it is needed to modify 
> RFC3262 and find a way to solve the problem. 
> 
>    Thanks 
>    Gao 
> 
> 
>    ZTE Information Security Notice: The information contained in 
> this mail is solely property of the sender's organization. This mail
system.
>    ZTE Information Security Notice: The information contained in 
> this mail is solely property of the sender's organization. This mail
system.

---

From: [email-masked]
Date: Thu, 9 Apr 2009 14:20:03 +0800

Hi,

Yes. But I did not mean automatically.

The process of termination of session should obey RFC3261.

IMO, BYE is *recommended*. Cancel would terminate other forking branch.

How to do it is just complementarity of RFC3262, not overthrow of it.
And I am not sure that really we need to give out a detail process for 
behaviour of violation of *MUST NOT*.

Gao

Brett Tate <[email-masked]> 
发件人:  [email-masked]
2009-04-08 19:17

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[Sipping] PRACK 481  (was RE:  答复: Re: 答复: Re:  PRACK: Change MUST 
requirement to include SDP offer in first reliable provisional response)

Since avoiding the sending of PRACK 481 (after sending PRACK 488 and 
similar failure responses) is an open issue within 
draft-ietf-sipping-sip-offeranswer-10 section 6.1, I thought that I'd 
mention the RFC 3262 text and potentially missing RFC 5057 text concerning 
PRACK 481.

"The 481 response to a CANCEL request has to be treated differently.  For 
CANCEL, a 481 means the UAS can't find a matching transaction.  A 481 
response to a CANCEL affects only the CANCEL transaction.  The usage 
associated with the INVITE is not affected."

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 08:26:21 +0200

Hi, 

	>[Gao] Is the agreement you mentioned reached during the IETF meeting? 

I would need to double check exactly what was agreed when.

At least we decided during an IETF meeting that it should be allowed to reject a PRACK SDP offer using a 4xx response. I think we then later on the list realized that a PRACK can be rejected for other reasons also.

Of course we can change previously made agreements (we have done that before - for good and bad), but I think we should have good reasons to do so.

Regards,

Christer

---

From: [email-masked]
Date: Thu, 9 Apr 2009 14:59:51 +0800

> I would need to double check exactly what was agreed when.

[Gao] :)

> At least we decided during an IETF meeting that it should be allowed
> to reject a PRACK SDP offer using a 4xx response. I think we then 
> later on the list realized that a PRACK can be rejected for other 
> reasons also.
> 
[Gao] If UAC(of PRACK) is introspective enough(deducing from the *MUST* 
2xx of UAS), I think there would be very infrequence of 4xx.

I still think it is not obligatory modification, but a choice.

And if someone find a case, in which we MUST using PRACK to do something 
rejectable, then it is a obligatory modification of RFC3262. 

> Of course we can change previously made agreements (we have done 
> that before - for good and bad), but I think we should have good 
> reasons to do so.
> 
> Regards,

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 10:03:06 +0200

Hi,

	>[Gao] If UAC(of PRACK) is introspective enough(deducing from the *MUST* 2xx of UAS), I think there would be very infrequence of 4xx. 

I think 4xx already now is quite infrequent. But we still need to know how to deal with it when it happens.

	>I still think it is not obligatory modification, but a choice. 

What is?

	>And if someone find a case, in which we MUST using PRACK to do something rejectable, then it is a obligatory modification of RFC3262. 

I think at least Paul and Brett has indicated that there are cases when it is useful to be able to reject the PRACK.

Personally I think it's bad protocol design to say that one *MUST* send a 200 response - no matter what.

Regards,

Christer

---

From: [email-masked]
Date: Thu, 9 Apr 2009 16:18:16 +0800

16:03:06:

>    >[Gao] If UAC(of PRACK) is introspective enough(deducing from the
> *MUST* 2xx of UAS), I think there would be very infrequence of 4xx. 
> 
> I think 4xx already now is quite infrequent. But we still need to 
> know how to deal with it when it happens.
> 

[Gao] You can see my *answer* to Brett's mail.

>    >And if someone find a case, in which we MUST using PRACK to do 
> something rejectable, then it is a obligatory modification of RFC3262. 
> 
> I think at least Paul and Brett has indicated that there are cases 
> when it is useful to be able to reject the PRACK.

[Gao] I am sure we can find many usages *can* be used in PRACK and there 
usages really rejectable.
But as we do not MUST do it as that, so we can leave it alone.

But as I said in previous mail, if we want to enrich *SubSet1(usages 
suitable in PRACK)*, then the work is needful.

> send a 200 response - no matter what.

[Gao] IMO, it is not elegant one, but no that bad :)
Perhaps because of reductionism. And the author really bypass the topic 
current talked.

---

From: Brett Tate <[email-masked]>
Date: Thu, 9 Apr 2009 05:12:21 -0700

> How to do it is just complementarity of RFC3262, not overthrow of it.

I was attempting to emphasis how PRACK 481 should be interpreted instead of how the UAC should release things.  My apologies if "not automatically" added to the confusion; the use of "not automatically" was to indicate that UAC may still initiate termination when UAS is not indicating that it should.

The PRACK 481 has the same meaning as CANCEL 481.  Thus the PRACK 481 should not automatically cause the UAC to initiate termination of the dialog usage (by sending BYE, sending CANCEL, exploding, or other means).

RFC 3262 section 3: "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."

RFC 3261 section 9.2: "If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist)."

RFC 5057 section 5.1 note 8: "The 481 response to a CANCEL request has to be treated differently.  For CANCEL, a 481 means the UAS can't find a matching transaction.  A 481 response to a CANCEL affects only the CANCEL transaction.  The usage associated with the INVITE is not affected."

> And I am not sure that really we need to give out a detail process 
> for behaviour of violation of *MUST NOT*. 

What "MUST NOT"?  The following two quotes clearly indicate PRACK 481 and other PRACK failure responses can be sent.

RFC 3262 section 3: "PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261."

RFC 3262 section 3: "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."

---

From: [email-masked]
Date: Mon, 13 Apr 2009 08:06:02 +0800

Hi,

Why you answer the mail you have answered? :)

And the newer mails(on 2009-04-09) you have not answered yet.

Thanks.

Gao

Christer Holmberg <[email-masked]> 
发件人:  <[email-masked]>
2009-04-07 15:43

收件人
<[email-masked]>, Paul Kyzivat <[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
Re: [Sipping]   答复: Re:  PRACK: Change MUST requirement to include SDP 
offer in        first reliable provisional response

Hi,

 
Regards,
 
Christer

By RFC3262: 

收件人

                Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 13 Apr 2009 16:08:36 +0200

Hi,

>The precondition state is just notification/updating, not negotiating.  
 
Yes, but where is it specified that it is "non-rejectable"?

>I mean that some people do not want modification here.  
 
You are saying that a PRACK can never be rejected.
 
Regards,
 
Christer

  

Hi, 

Yes. 

 
Regards, 

Christer 

By RFC3262: 

2009-04-06 20:16 

收件人

             Paul