Re: [Sipping] non-200 response to PRACK (was: Re: PRACK: Change MUST requirement to include SDP offer in first reliable provisional response)

["Christer Holmberg" <christer.holmberg at ericsson.com>]



Hi,

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

>   
>Ok, so where is all that defined? 
> 
> [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.  

 

Yes, but where is it specified that it is "non-rejectable"?

 
 
>>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... :) 
> 
>[Gao] I am not sure we are talking the same thing :) 
>I mean that some people do not want modification here.  

 

You are saying that a PRACK can never be rejected.

 

Regards,

 

Christer

 

 
  
  
  
  
 



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

>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.  
 
Every request is rejectable, no matter how much or little usage you have in it.
 
Regards,

Christer

---

From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of gao.yang2 at zte.com.cn
Sent: Tuesday, April 07, 2009 4:33 AM
To: Paul Kyzivat
Cc: sipping-bounces at ietf.org; sipping at ietf.org; Christer Holmberg
Subject: [Sipping] 答复: Re: PRACK: Change MUST requirement to include SDP offer in first reliable provisional response


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 Kyzivat <pkyzivat at cisco.com>
发件人:  sipping-bounces at ietf.org

2009-04-06 20:16

收件人	"Rockson Li (zhengyli)" <zhengyli at cisco.com>
抄送	sipping at ietf.org, Christer Holmberg <christer.holmberg at ericsson.com>
主题	Re: [Sipping] PRACK: Change MUST requirement to include SDP offer in        first reliable provisional response

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:
> 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:* sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] *On 
> 
Behalf Of *Hadriel Kaplan
> *Sent:* Tuesday, March 31, 2009 9:50 
PM
> *To:* Christer Holmberg; sipping at ietf.org
> *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
> 
> 
 
> 
>  
> 
> 
> 
------------------------------------------------------------------------
> 
> _______________________________________________
> Sipping mailing 
list  https://www.ietf.org/mailman/listinfo/sipping
> This list is 
for NEW development of the application of SIP
> Use 
sip-implementors at cs.columbia.edu for questions on current sip
> Use 
sip at ietf.org 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 at cs.columbia.edu 
for questions on current sip
Use sip at ietf.org for new developments of core 
SIP


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


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


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


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