[sipcore] 答复: Re: Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft
gao.yang2@zte.com.cn Mon, 07 December 2009 01:07 UTC
Return-Path: <gao.yang2@zte.com.cn>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C143A695E; Sun, 6 Dec 2009 17:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.545
X-Spam-Level:
X-Spam-Status: No, score=-93.545 tagged_above=-999 required=5 tests=[AWL=-3.769, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uUn02z1uCCc; Sun, 6 Dec 2009 17:07:13 -0800 (PST)
Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 93A473A6951; Sun, 6 Dec 2009 17:07:10 -0800 (PST)
Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91102001811080; Mon, 7 Dec 2009 08:43:46 +0800 (CST)
Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 89005.2001811080; Mon, 7 Dec 2009 09:05:55 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id nB716epY013646; Mon, 7 Dec 2009 09:06:43 +0800 (CST) (envelope-from gao.yang2@zte.com.cn)
In-Reply-To: <4B1B5130.1020305@ericsson.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF4A15FB54.3C9F8155-ON48257685.0004F61B-48257685.000615E5@zte.com.cn>
From: gao.yang2@zte.com.cn
Date: Mon, 07 Dec 2009 09:05:43 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-07 09:06:38, Serialize complete at 2009-12-07 09:06:38
Content-Type: multipart/alternative; boundary="=_alternative 000615E148257685_="
X-MAIL: mse2.zte.com.cn nB716epY013646
Cc: SIPCORE <sipcore@ietf.org>, wang.libo@zte.com.cn, sipcore-bounces@ietf.org
Subject: [sipcore] 答复: Re: Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 01:07:15 -0000
Hi, By myself, I think that this issue("Suspending and Resuming modification of session or stream") is not as urgent as the "session state" and "dialog state" issue. While I proposed this thread, there are less people care about it.(In fact, I have in remembrance that only Paul and Christer gave comments(if there are someone else, sorry for it)). And I support your way as "If people want these issues to be clarified, we should by all means do so. However, if people do not really care about these corner cases, we should prioritize other specs." BTW, I think if someday more people want to clarify this issue, http://tools.ietf.org/html/draft-camarillo-sipping-precons-00 is a nice standby and starting. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> 发件人: sipcore-bounces@ietf.org 2009-12-06 14:37 收件人 gao.yang2@zte.com.cn 抄送 SIPCORE <sipcore@ietf.org>, wang.libo@zte.com.cn 主题 Re: [sipcore] Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft Hi, [I am resurrecting this old thread because it did not reach a conclusion.] Originally, preconditions were designed with initial INVITE requests in mind. The idea was to keep the UAS from alerting the callee until the media streams with preconditions were ready to be established (e.g., their QoS was in place). That is, if there were some streams that did not have preconditions, they would not be established until the preconditions for the other streams were met. For example, let us assume an initial INVITE with an audio stream without preconditions and a video stream with QoS preconditions. Until the QoS for the video stream is in place, the audio stream will not be established and the callee will not be alerted. In short, when one or more streams within a session have preconditions, the whole session establishment is suspended until those preconditions are met. When we extended the concept of preconditions to re-INVITEs, we wanted to have similar behavior for initial INVITEs and for re-INVITEs. That is why RFC 4032 talks about about *session* establishment being suspended: http://tools.ietf.org/html/rfc4032#section-3.4 Therefore, the idea was that no changes were applied to any stream until all the preconditions were met. So, the above was our original thinking. However, at present we have a better understanding about the problems with long-lived re-INVITE transactions. If we allow the whole session establishment to be suspended, it would be impossible to change the session parameters of any stream while the UAs were working on meeting the preconditions of other streams. On the other hand, we want to be able to make the changes to one stream conditional to the changes on other stream being executed (e.g., use this new audio codec if you accept adding a video stream to the session; otherwise, keep on using the old audio codec). Before we explore this more deeply, I would like to understand if there is interest in resolving this type of issue. Some time ago I put together a draft dealing with a similar issue (media state during preconditions) but we concluded that, at that point, there was not enough interest for me (or anyone else for that matter) to put more energy into it: http://tools.ietf.org/html/draft-camarillo-sipping-precons-00 If people want these issues to be clarified, we should by all means do so. However, if people do not really care about these corner cases, we should prioritize other specs. Thanks, Gonzalo gao.yang2@zte.com.cn wrote: > > Considering a use case, A and B has a audio only session. Then A send a > Re-INVITE for adding vedio stream( with precondition) and changing codec > or address for audio stream( without preconditon). > > If suspending is effective for whole session, then streams without > precondition should use old parameters while in suspending state. > For the use case, A and B should not use new codec or address for audio > before vedio's preconditon is met. > > If suspending is effective for streams with precondition, the then > streams without preconditio can use new parameters after first O/A > during the Re-INVITE. > For the use case, A and B can use new codec or address for audio before > vedio's preconditon is met. > > > I prefer the first one, as; > 1. To delay using of new parameters for stream without precondition may > arose media clip problem. > 2. Behavior of streams without precondition should be independent of > existence of other streams( with precondition). > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > -------------------------------------------------------- > 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. > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore -------------------------------------------------------- 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.
- [sipcore] 答复: Re: New revision of the re-INVITE h… gao.yang2
- [sipcore] New revision of the re-INVITE handling … Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… OKUMURA Shinji
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… OKUMURA Shinji
- [sipcore] 答复: Re: New revision of the re-INVITE h… gao.yang2
- Re: [sipcore] New revision of the re-INVITE handl… OKUMURA Shinji
- [sipcore] 答复: Re: New revision of the re-INVITE h… gao.yang2
- Re: [sipcore] New revision of the re-INVITE handl… OKUMURA Shinji
- Re: [sipcore] 答复: Re: New revision of the re-INVI… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- Re: [sipcore] New revision of the re-INVITE handl… wang.libo
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Sanjay Sinha (sanjsinh)
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- [sipcore] 答复: Re: New revision of the re-INVITE h… gao.yang2
- Re: [sipcore] 答复: Re: New revision of the re-INVI… Gonzalo Camarillo
- [sipcore] 答复: Re: 答复: Re: New revision of the re-… gao.yang2
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- [sipcore] 答复: Re: New revision of the re-INVITE h… gao.yang2
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Paul Kyzivat
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- Re: [sipcore] New revision of the re-INVITE handl… OKUMURA Shinji
- Re: [sipcore] New revision of the re-INVITE handl… Gonzalo Camarillo
- Re: [sipcore] New revision of the re-INVITE handl… Christer Holmberg
- [sipcore] Suspending and Resuming modification of… gao.yang2
- Re: [sipcore] Suspending and Resuming modificatio… Paul Kyzivat
- [sipcore] 答复: Re: Suspending and Resuming modific… gao.yang2
- Re: [sipcore] 答复: Re: Suspending and Resuming mod… Paul Kyzivat
- [sipcore] 答复: Re: 答复: Re: Suspending and Resuming… gao.yang2
- Re: [sipcore] 答复: Re: 答复: Re: Suspending and Resu… Paul Kyzivat
- [sipcore] 答复: Re: 答复: Re: 答复: Re: Suspending and … gao.yang2
- Re: [sipcore] 答复: Re: Suspending and Resuming mod… Christer Holmberg
- [sipcore] 答复: RE: 答复: Re: Suspending and Resuming… gao.yang2
- Re: [sipcore] 答复: Re: Suspending and Resuming mod… Paul Kyzivat
- [sipcore] 答复: Re: 答复: Re: Suspending and Resuming… gao.yang2
- Re: [sipcore] ??: Re: Suspending and Resuming mod… Christer Holmberg
- Re: [sipcore] Suspending and Resuming modificatio… Gonzalo Camarillo
- [sipcore] 答复: Re: Suspending and Resuming modific… gao.yang2