Re: [MEDIACTRL] SIP Control Framework - Issues

Diego B <diegob@mailvision.com> Tue, 07 August 2007 07:05 UTC

Return-path: <mediactrl-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJ8M-0005g6-9i; Tue, 07 Aug 2007 03:05:38 -0400
Received: from mediactrl by megatron.ietf.org with local (Exim 4.43) id 1IIJ8K-0005fm-K7 for mediactrl-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 03:05:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJ8H-0005fL-3C for mediactrl@ietf.org; Tue, 07 Aug 2007 03:05:33 -0400
Received: from zimbra.mailvision.net ([212.143.248.123] helo=mvimap.mailvision.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIJ8B-0006BB-4k for mediactrl@ietf.org; Tue, 07 Aug 2007 03:05:33 -0400
Received: from localhost (localhost [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id 18746768E64; Tue, 7 Aug 2007 09:03:45 +0300 (IDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 tagged_above=-10 required=5 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599]
Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVXsAWACVwEP; Tue, 7 Aug 2007 09:03:37 +0300 (IDT)
Received: from diego-bs-computer.local (unknown [192.168.0.194]) by mvimap.mailvision.net (Postfix) with ESMTP id 564BA768E63; Tue, 7 Aug 2007 09:03:37 +0300 (IDT)
Message-ID: <46B819B5.8080202@mailvision.com>
Date: Tue, 07 Aug 2007 10:05:25 +0300
From: Diego B <diegob@mailvision.com>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Chris Boulton <cboulton@ubiquity.net>
Subject: Re: [MEDIACTRL] SIP Control Framework - Issues
References: <D8A411E49D63A648BFA87E44904FEDCF06864B@gbnewp0758m.eu.ubiquity.net>
In-Reply-To: <D8A411E49D63A648BFA87E44904FEDCF06864B@gbnewp0758m.eu.ubiquity.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: mediactrl@ietf.org
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Control BOF Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
Errors-To: mediactrl-bounces@ietf.org

Hi;
I agree with your reflections.
In the SDP case, there is something MMUSIC have to handle or agree ?

Regards
Diego B

Chris Boulton wrote:
>
> There are a couple of issues to discuss for the next version of the 
> SIP Control Framework and it would be extremely useful to get the Work 
> Groups input.
>
> - SIP option tag in SIP Control Framework
>
> The draft currently defines a SIP option tag for negotiation of the 
> core SIP Control Framework 
> (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-05.txt). 
> If the group decides to proceed down this route we will need to hand 
> this over to the SIP work group and its experts. On reflection, I feel 
> that this might not be an appropriate use of a Sip option tag. I have 
> taken MSRP 
> (http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-19.txt) 
> as the driving example. It also used SDP to convey a media type that 
> defines its support + connection details. I personally think that we 
> should remove the SIP option tag from the SIP Control Framework and 
> rely on SDP negotiation.
>
> - SIP ‘Control-Packages’ header in SIP Control Framework
>
> The current version of the draft uses a Control-Packages SIP header to 
> negotiate the actual extension packages that can be used on a Control 
> Channel. This work would also need to be handed over to the SIP 
> working group. On reflection it is (in my opinion) not the best place 
> to negotiate this information. I suspect it should be done within the 
> control channel itself (either re-using or defining a new primitive) 
> once the channel is set up. This also allows packages to be 
> dynamically added/removed from the session without causing SIP 
> signalling to be triggered.
>
> Please think carefully about these two issues as they impact heavily 
> the next version of the document.
>
> Chris.
>
>
>
> Information contained in this e-mail and any attachments are intended 
> for the use of the addressee only, and may contain confidential 
> information of Ubiquity Software Corporation. All unauthorized use, 
> disclosure or distribution is strictly prohibited. If you are not the 
> addressee, please notify the sender immediately and destroy all copies 
> of this email. Ubiquity Software Corporation plc, a company registered 
> under the laws of England and Wales, Registration 2719723, registered 
> offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. 
> Mellons, Cardiff CF3 5EA, Wales, United Kingdom.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl


_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl