Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt

gao.yang2@zte.com.cn Mon, 18 January 2010 10:26 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 53E203A6836 for <sipcore@core3.amsl.com>; Mon, 18 Jan 2010 02:26:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.635
X-Spam-Level:
X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 xleLpQldp5lu for <sipcore@core3.amsl.com>; Mon, 18 Jan 2010 02:26:31 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 7CBF23A6405 for <sipcore@ietf.org>; Mon, 18 Jan 2010 02:26:30 -0800 (PST)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Mon, 18 Jan 2010 17:52:28 +0800 (CST)
Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.2980680612; Mon, 18 Jan 2010 18:26:21 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o0IAQaXl089381; Mon, 18 Jan 2010 18:26:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn)
In-Reply-To: <4B541854.5010907@ericsson.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006
Message-ID: <OF2A148D6E.F8AF36D4-ON482576AF.0037A224-482576AF.00396120@zte.com.cn>
From: gao.yang2@zte.com.cn
Date: Mon, 18 Jan 2010 18:25:17 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-18 18:26:22, Serialize complete at 2010-01-18 18:26:22
Content-Type: multipart/alternative; boundary="=_alternative 0039611D482576AF_="
X-MAIL: mse1.zte.com.cn o0IAQaXl089381
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt
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, 18 Jan 2010 10:26:33 -0000

Hi Gonzalo,

Yes, I also found that not many people showed interest in it.

By deeply discussion "Re-INVITE handling" draft these days, we find that 
we should clarify how modified media can/should be used. But how modified 
media can/should/may be used is a more basic topic.

This topic has influence on other higher level topics, such as "Re-INVITE 
handling" draft and etc. So, I hope more people could pay attention to it.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : gao.yang2@zte.com.cn
===================================



Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> 
2010-01-18 16:14

收件人
"gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>
抄送
SIPCORE <sipcore@ietf.org>
主题
Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt






Hi Gao,

that is why I wrote the draft about preconditions. However, not many
people showed interest in it at that time.

Cheers,

Gonzalo

gao.yang2@zte.com.cn wrote:
> 
> Hi,
> 
> Maybe clarification of precons has something beyond Re-INVITE handling 
> text.
> 
> As Re-INVITE handling text aims for updating of RFC3261, we may need a 
> detailed normative text for updating RFC3312 & RFC4032. And we can talk 
> topics relating to precons but outside of the scope of Re-INVITE 
> handling text, such as "resuming and suspending for session or for 
> separate stream".
> 
> Two separate text means different maintenance process and lifecycle. If 
> we can guarantee the consistency and integrality of the two text, I 
> think two text would be clear for two (relating) topics.
> 
> 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
> 
> 2010-01-14 16:33
> 
> 
> 收件人
>                SIPCORE <sipcore@ietf.org>
> 抄送
> 
> 主题
>                Re: [sipcore] Question on 
draft-camarillo-sipcore-reinvite-01.txt
> 
> 
> 
> 
> 
> 
> 
> 
> Hi,
> 
> I have put together a new version of the draft:
> 
> 
http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre01a.txt
> 
> Let me know if you have some comments before I submit it.
> 
> Regarding the decision about when a given change in the session state
> has been executed when preconditions are used, I have added a paragraph
> that summarizes our discussions and the following draft:
> 
> 
http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt
> 
> Please, read Section 5.
> 
> Sections 7 and 15 contain new rules to avoid glare situations and race
> conditions. These rules avoid nasty call flows that were able to get the
> UAs out of synch.
> 
> Some time ago, we discussed whether or not unreliable provisional
> responses could refresh the remote target. There are several problems
> with unreliable responses updating remote targets. First, we would need
> to define even more rules to avoid glare situations and race conditions.
> Second, SIP does not provide any ordering for unreliable provisional
> responses. Responses arriving out of order at the UAC could easily get
> both UAs out of synch. Therefore, only reliable responses can refresh
> remote targets, as was specified in RFC 3261 anyway.
> 
> We also discussed the applicability of the target refresh rules to
> initial INVITEs. The rules in the draft cover them as well so I do not
> think we need to add anything else to that end.
> 
> Thanks,
> 
> Gonzalo
> 
> _______________________________________________
> 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.
> 






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