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

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Oct 2000 11:05:42 +0300

Hi,

I have gathered some feedback on the draft
draft-camarillo-sip-sdp-00.txt
The general feeling in the SIP and MMUSIC WGs is that this is certainly
a useful mechanism.

However, there are some concerns about the actual format to be used and
the problems that some RTP implementation might have if an RTP flow is
sent to different port numbers.

A possible solution to the format to be used is already outlined in the
draft in section 7. "Backward compatibility".

I will check what people in the Audio/Video Transport (avt) WG
<[email-masked]> think about this.

Regards,

Gonzalo

"Culpepper, Bert" wrote:
> 
> Hi,
> 
> I'm not writing to present a problem with this proposal but to state a need
> for it?
> 
> For a specific case not mentioned in the draft.  A "3rd-party call agent"
> may need to be able to receive tones and also have them be presented to the
> 2nd party.  Tone transport is defined by RFC2833, it recommends that
> gateways remove the tones from the audio media.
> 
> So..., I'd like an endpoint to understand the following media description in
> a session description.
> 
> m=audio 10010 RTP/AVP 4
> c=IN IP4 111.2.30.4
> a=rtpmap:4 G723/8000
> m=audio 10020 RTP/AVP 97
> c=IN IP4 111.2.30.4
> a=rtpmap:97 telephone-event
> a=fmtp:97 0-15
> m=audio 20000 RTP/AVP 97
> c=IN IP4 111.2.31.10
> a=rtpmap:97 telephone-event
> a=fmtp:97 0-15,16
> 
> (In this case one "c" line can be used in the session description instead of
> how it's shown.)
> 
> Nothing I read in RFC 2543 (SIP) and RFC 2327 (SDP) indicates the above is
> not allowed.  This is not a standards issue but I wonder how many endpoints
> (gateways included) will support sending the two media types to the
> different destinations as indicated above.  If in SIP the above session
> description doesn't result in three "media streams" being sent to the
> indicated host/port, media replication (which may not be present in an
> endpoint) will require a specific resource in the network.
> 
> Is the use of the flow ID attribute required to achieve the above?  Am I
> incorrect in what I think should result from the above session description
> in SIP?
> 
> The ID does seem to encourage endpoint support for media replication to
> different hosts and ports which I'd like to see as standard functionality in
> some endpoints & environments.
> 
> Regards,
> Bert
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
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 :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Oct 2000 08:50:24 +0300

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
************

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Oct 2000 07:22:06 -0700 (PDT)

> 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