Re: [SIP] draft-camarillo-sip-sdp-00.txt

Michael Thomas <mat@cisco.com> Thu, 12 October 2000 14:23 UTC

Return-Path: <owner-confctrl>
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA05138 for confctrl-outgoing; Thu, 12 Oct 2000 07:23:25 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA05133 for <confctrl@zephyr.isi.edu>; Thu, 12 Oct 2000 07:23:23 -0700 (PDT)
Received: from jindo.cisco.com (jindo.cisco.com [171.69.11.73]) by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA21529 for <confctrl@ISI.EDU>; Thu, 12 Oct 2000 07:23:36 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA13841; Thu, 12 Oct 2000 07:22:06 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA09794; Thu, 12 Oct 2000 07:22:06 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <14821.51470.600000.694429@thomasm-u1.cisco.com>
Date: Thu, 12 Oct 2000 07:22:06 -0700
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>, Rohan Mahy <rohan@cisco.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com, Henning Schulzrinne <hgs@cs.columbia.edu>, mmusic <confctrl@ISI.EDU>
Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
In-Reply-To: <39E55120.4C00165F@lmf.ericsson.se>
References: <DBD1CC7CE357D211AECC009027158FD1033B976F@itmail-ict1-imc.wichi> <39E17C56.35D50F99@lmf.ericsson.se> <39E55120.4C00165F@lmf.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &, heK/V66p?[2!i|tVn, 9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a), -7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d, g">$%B!0w{W)qIhmwhye104zd bUcI'1!
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Gonzalo Camarillo writes:
 > I would like my session description to look like:
 > 
 >          v=0
 >          o=John 289085535 289085535 IN IP4 first.example.com
 >          t=0 0
 >          c=IN IP4 111.111.111.111
 >          m=audio 20000 RTP/AVP 0
 >          a=fid:1
 >          m=audio 20002 RTP/AVP 8
 >          a=fid:1
 > 
 > If an implementation does not understand the fid attribute it will try
 > to mix the audio streams. Since one is "empty" all the time, doing this
 > is not really a big deal. Thus, backwards compatibility is not a
 > concern.
 > 
 > Do you have any concerns with this approach?

   The main problem I see is with the interaction with
   QoS reservations. Namely, that you'd expect the receiver
   to book reservations for both flows. Doing:

   m=audio 20000 RTP/AVP 0 8

   on the other hand only implies that you book the ceil()
   of both flows. 

   Why is it so advantageous to segregate these into two 
   streams? The implicit coupling you're after seems like
   it's not well handled by SDP right now, and I'd bet
   that this would be better taken up as a working item
   for SDPng (if not already there) because my understanding
   is that explicit audio synch with video is also problematic in
   SDP right now, which is sort of similar.

		Mike