Re: [sipcore] About RFC3911(Join header)'s potential error:

gao.yang2@zte.com.cn Wed, 06 October 2010 16:16 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 62F913A71A5 for <sipcore@core3.amsl.com>; Wed, 6 Oct 2010 09:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.236
X-Spam-Level:
X-Spam-Status: No, score=-98.236 tagged_above=-999 required=5 tests=[AWL=-0.601, 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 jUWG7uV5rqDO for <sipcore@core3.amsl.com>; Wed, 6 Oct 2010 09:16:09 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id BADE03A6F9D for <sipcore@ietf.org>; Wed, 6 Oct 2010 09:16:01 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Thu, 7 Oct 2010 00:14:35 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 79135.3772637948; Thu, 7 Oct 2010 00:14:37 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o96GH7aC002939; Thu, 7 Oct 2010 00:17:07 +0800 (CST) (envelope-from gao.yang2@zte.com.cn)
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C7F@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: <OF76696484.1E59638A-ON482577B4.00584A3A-482577B4.00596B84@zte.com.cn>
From: gao.yang2@zte.com.cn
Date: Thu, 07 Oct 2010 00:14:41 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-07 00:16:44, Serialize complete at 2010-10-07 00:16:44
Content-Type: multipart/alternative; boundary="=_alternative 00596B81482577B4_="
X-MAIL: mse2.zte.com.cn o96GH7aC002939
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] About RFC3911(Join header)'s potential error:
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: Wed, 06 Oct 2010 16:16:22 -0000

I'd like to emphasize that I also think there should be no 
conference/mixing resources for the showed use case, as I said in the 
previous mail.

But I think what we said was not defined clearly in the RFC3911. And I 
also think it is hardly to do any deduction to get the rules we discussed.

So, it is not a question like "how should it be?", but a question like 
"where is it defined".

Thanks,

Gao

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



"Worley, Dale R (Dale)" <dworley@avaya.com> 
发件人:  sipcore-bounces@ietf.org
2010-10-01 04:23

收件人
Paul Kyzivat <pkyzivat@cisco.com>, "gao.yang2@zte.com.cn" 
<gao.yang2@zte.com.cn>
抄送
"sipcore@ietf.org" <sipcore@ietf.org>
主题
Re: [sipcore] About RFC3911(Join header)'s potential error:






________________________________________
From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of 
Paul Kyzivat [pkyzivat@cisco.com]

I think the works you are concerned about already are consistent with
the scenario you raise. Specifically,

> and assign any mixing or conferencing resources necessary to complete 
the join

includes the case where no mixing or conferencing resources are necessary.
_______________________________________________

I think that Paul is correct here.  If two dialogs go to a server and are 
joined at the server, and both dialogs are sendonly at the server, then 
"mixing" is very simple: the one source (generated by the server) is 
duplicated as RTP to each dialog's remote end.

In practice, one might say that this "does not allocate mixing resources". 
 OTOH, for some implementations, this duplication of the media stream may 
require the allocation of a mixing resource, if no other component of the 
server can perform the duplication.

I do not see this as a problem that needs to be solved.

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