Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension

gao.yang2@zte.com.cn Thu, 07 October 2010 08:03 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 726373A6E0A for <sipcore@core3.amsl.com>; Thu, 7 Oct 2010 01:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.195
X-Spam-Level:
X-Spam-Status: No, score=-100.195 tagged_above=-999 required=5 tests=[AWL=1.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kWHvLoYSGFBF for <sipcore@core3.amsl.com>; Thu, 7 Oct 2010 01:03:49 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 908833A6DFA for <sipcore@ietf.org>; Thu, 7 Oct 2010 01:03:48 -0700 (PDT)
Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Thu, 7 Oct 2010 16:03:34 +0800 (CST)
Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 79135.1967002180; Thu, 7 Oct 2010 16:02:27 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9784up6078575; Thu, 7 Oct 2010 16:04:56 +0800 (CST) (envelope-from gao.yang2@zte.com.cn)
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B21FFC79CE4@DC-US1MBEX4.global.avaya.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006
Message-ID: <OF612A5B34.E2443323-ON482577B5.002940DB-482577B5.002C3DA2@zte.com.cn>
From: gao.yang2@zte.com.cn
Date: Thu, 07 Oct 2010 16:01:11 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-07 16:04:44, Serialize complete at 2010-10-07 16:04:44
Content-Type: multipart/alternative; boundary="=_alternative 002C3D98482577B5_="
X-MAIL: mse3.zte.com.cn o9784up6078575
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension
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: Thu, 07 Oct 2010 08:03:50 -0000

> If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the 
> original dialog (between UAs X and Y) *must* be terminated by X when
> it accepts the INVITE-with-Replaces.

I knew it. But my proposal here is to do extension for the Replaces 
header. And you may refer to the first mail of this thread for details. 
 
> What UA Z should do is send an INVITE-with-Join to X 

I MUST point out that Join header's semantics is not proper for this use 
case.

> (offering only video), 

By my experience, INVITE-with-Join(only downlink video) *could* be treated 
as a video duplication request. But how about INVITE-with-Join(only 
bidirectional video)? 
In fact, no like audio stream, there's no physical meaning for video 
streams' mixing. So, if UA Z send an INVITE-with-Join, with only 
bidirectional video, UA X may not know how to handle it.(So, I feel that 
RFC3911 need clarification!)

> and then UA Y should do a re-INVITE to remove its video 
> stream from its dialog with X (leaving the audio stream). 

Let's analyse what would happen after UA Y sending a re-INVITE to remove 
it's video stream from it's dialog. As the use case of 
"INVITE-with-Join(only bidirectional video)" is meaning, as I showed in 
the previous section, we may analyse a similar one: "INVITE-with-Join(only 
downlink video)" .

Not like audio mixing, the session can be downgraded from three-party to 
two-party, when one leave the session. If the vedio between X and Y is 
over, I think the duplicated one between X and Z would lose it's vedio 
source.

Gao

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