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 protected]>
发件人: <[email protected]>
2009-04-07 15:43
收件人
<[email protected]>, Paul Kyzivat <[email protected]>
抄送
<[email protected]>, <[email protected]>
主题
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).
And, in that case, why would an intermeidate be allowed to reject a PRACK,
but not the UAS?
Regards,
Christer
From: [email protected] [mailto:[email protected]] On Behalf
Of [email protected]
Sent: Tuesday, April 07, 2009 4:33 AM
To: Paul Kyzivat
Cc: [email protected]; [email protected]; 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 <[email protected]>
发件人: [email protected]
2009-04-06 20:16
收件人
"Rockson Li (zhengyli)" <[email protected]>
抄送
[email protected], Christer Holmberg <[email protected]>
主题
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:* [email protected] [mailto:[email protected]] *On
> Behalf Of *Hadriel Kaplan
> *Sent:* Tuesday, March 31, 2009 9:50 PM
> *To:* Christer Holmberg; [email protected]
> *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 [email protected] for questions on current sip
> Use [email protected] 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 protected] for questions on current sip
Use [email protected] 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.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] 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.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.