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

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 30 September 2010 20:11 UTC

Return-Path: <dworley@avaya.com>
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 837A53A6E09 for <sipcore@core3.amsl.com>; Thu, 30 Sep 2010 13:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.273
X-Spam-Level:
X-Spam-Status: No, score=-101.273 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, 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 O3xq5dhqsCez for <sipcore@core3.amsl.com>; Thu, 30 Sep 2010 13:11:21 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E13F33A6CED for <sipcore@ietf.org>; Thu, 30 Sep 2010 13:11:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,261,1283745600"; d="scan'208";a="240607277"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 Sep 2010 16:12:07 -0400
X-IronPort-AV: E=Sophos;i="4.57,261,1283745600"; d="scan'208";a="521820445"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Sep 2010 16:12:07 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 30 Sep 2010 16:12:06 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>, Paul Kyzivat <pkyzivat@cisco.com>
Date: Thu, 30 Sep 2010 16:08:01 -0400
Thread-Topic: [sipcore] About Join and Replaces Headers: //Replaces header's extension
Thread-Index: ActeXgV5vGgJym83QV6ylHhWCwRK9wCfSmGu
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C7E@DC-US1MBEX4.global.avaya.com>
References: <4CA09B25.8080808@cisco.com>, <OF7C6A063D.BE785268-ON482577AB.00567364-482577AB.00587E45@zte.com.cn>
In-Reply-To: <OF7C6A063D.BE785268-ON482577AB.00567364-482577AB.00587E45@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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, 30 Sep 2010 20:11:23 -0000

________________________________________
From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of gao.yang2@zte.com.cn [gao.yang2@zte.com.cn]

Nowadays, I am considering requirements about media streams tranfering between user's UEs, such as transfering active video stream from one normal UE to one HD(High Definitive) device.

This function is similar to 3GPP's IUT(Inter UE Transfer). But I'd like to seek a end to end solution, with out SCC_AS's 3pcc call control.

I think we could do one potential extension for Replaces header, as:

The Replaces header could be added with a indication.
For examle, transfer video to HD device, while save the audio at the orignal device:
The new party(new device) send a INVITE(the Offer with video stream) with Replaces header, with the indication. Then the UAS of this INVITE can just transfer the media streams(video) to the new session, and save the other streams in the origianl session (by a new Re-INVITE to just mute the transfered media streams).
________________________________________

However, you must beware that in SIP which rendering devices of a UA are used to render particular media streams is under the control of the user of the UA, not of the remote UAs that it communicates with.  Therefore, while an incoming INVITE/Replaces may provide HD video, it is not the choice of the sender of the INVITE/Replaces that the HD video stream be rendered on the HD video device.  (Indeed, the sender of the INVITE/Replaces has no certain knowledge that the recipient UA possesses an HD video device.)  It is the choice of the user of the recipient UA (or more likely, his configuration of the UA) that determines that the offered HD video stream is to be rendered on a particular rendering device.

Within that architecture, there can be no use for such an indication on the Replaces header.

Dale