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

Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se> Thu, 12 October 2000 05:53 UTC

Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06654 for <sip-archive@odin.ietf.org>; Thu, 12 Oct 2000 01:53:52 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0838444438; Thu, 12 Oct 2000 00:52:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 12E0744437 for <sip@lists.bell-labs.com>; Thu, 12 Oct 2000 00:51:10 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9C5ojt24779; Thu, 12 Oct 2000 07:50:45 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA22497; Thu, 12 Oct 2000 08:50:43 +0300 (EET DST)
Message-ID: <39E55120.4C00165F@lmf.ericsson.se>
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "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
References: <DBD1CC7CE357D211AECC009027158FD1033B976F@itmail-ict1-imc.wichi> <39E17C56.35D50F99@lmf.ericsson.se>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 12 Oct 2000 08:50:24 +0300
Content-Transfer-Encoding: 7bit

Hi,

I already checked with the guys of the AVT WG and we reached some
conclusions on this matter. The issue was what to do when RTP has to be
sent to different ports based on the codec used at any moment.

The conclusion is that two RTP streams will be used. Right below I
attach a small review of the thread and one open issue regarding the fid
attribute.

Feedback is appreciated,

************

Hi,

Henning Schulzrinne wrote:
> 
> Gonzalo Camarillo wrote:
> >
> 
> >
> > Yes, that is one of the concerns people have - RTCP. Anyway, this 3rd
> > party developed RTP library is just one among many examples. There are
> > other scenarios where this feature might be useful. For instance, when
> > the DTMF tones have to be received in a different device than the voice.
> 
> That is solvable in a far cleaner manner by having two voice sessions,
> one for regular audio and one for DTMF. The same applies to other
> scenarios. To the end system, this is just like mixing several sources.
> Implementing this gets you mixing and conferencing for free, so this is
> a Good Thing.

I am happy with this solution. However, I would like to signal it
properly to the other end.

That is, I receive the following description (in an INVITE for
instance).

         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
         m=audio 20002 RTP/AVP 8

This means that I will receive two media streams. The first one on port
number 20000 will use PCM u-law. The second one will arrive on port
number 20002 and will be using PCM A-law.
Actually I might receive media from both media streams simultaneously.
One of the media streams might contain the voice of the singer and the
other the background (public, guitars, ...) of the concert.


I would like to differentiate this case from the following one.
Now I want to have a conversation with somebody. I want just to transmit
my voice. However, sometimes I will use PCM u-law and others PCM A-law.
The receiver wants to receive (due to any reason) different codecs on
different port numbers.

As we have discussed previously in this thread, we will establish two
media streams. But I want the receiver to know that I will never
transmit simultaneouly in both media streams.

I will transmit using one OR the other.

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?

RTP and RTCP remain untouched.

Actually, this discussion began being very much RTP related, but now we
are moving to MMUSIC or SIP probably...

Best regards,

Gonzalo
************

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip