答复: Re: 答复: Re: 答复: Re: PRACK: Change MUST requirement to include SDP offer in first reliable provisional response

[gao.yang2@xxxxxxxxxx]

Hi

inline:)


Paul Kyzivat <pkyzivat@xxxxxxxxx> 写于 2009-04-08
12:37:40:

> 
> 
> gao.yang2@xxxxxxxxxx wrote:
> > 
> > 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.
> 
> 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.
> 

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


> > Considering UAC, it can judge from the 4xx to terminate the session(such
> > 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.
> 
> > 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. 
> 
> What is so hard?

[Gao] No hard, just complex :)

> 
>    Thanks,
>    Paul
> 
> > Thanks
> > Gao
> > 
> > 
> > 
> > *Paul Kyzivat <pkyzivat@xxxxxxxxx>*
> > 
> > 2009-04-07 20:59
> > 
> >    
> > 收件人
> >    gao.yang2@xxxxxxxxxx
> > 抄送
> >    Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>,
sipping@xxxxxxxx, 
> > sipping-bounces@xxxxxxxx, "Rockson Li (zhengyli)" <zhengyli@xxxxxxxxx>
> > 主题
> >    Re: 答复: Re: [Sipping] PRACK: Change MUST requirement
to include SDP 
> > offer in first reliable provisional response
> > 
> > 
> >    
> > 
> > 
> > 
> > 
> > 
> > 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
> > 
> > 
> > gao.yang2@xxxxxxxxxx wrote:
> >  >
> >  > 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@xxxxxxxxx>*
> >  > 发件人:  sipping-bounces@xxxxxxxx
> >  >
> >  > 2009-04-06 20:16
> >  >
> >  >                
 
> >  > 收件人
> >  >                
 "Rockson Li (zhengyli)" <zhengyli@xxxxxxxxx>
> >  > 抄送
> >  >                
 sipping@xxxxxxxx, Christer Holmberg 
> > <christer.holmberg@xxxxxxxxxxxx>
> >  > 主题
> >  >                
 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@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx]
*On
> >  >  > Behalf Of *Hadriel Kaplan
> >  >  > *Sent:* Tuesday, March 31, 2009 9:50 PM
> >  >  > *To:* Christer Holmberg; sipping@xxxxxxxx
> >  >  > *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@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
> >  >
> >  >
> >  > --------------------------------------------------------
> >  > 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.

_______________________________________________
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