Subject: [MMUSIC] Re: Codec equality in FID

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 06 May 2002 20:13:20 +0300

Hi Flemming,

> > Therefore, the demultiplexing is performed based on the codec in use
> > (i.e., format of the media), and not on the transport in use.
> >
> 
> Understood - my question was whether it was on the combination of transport
> and codec or just codec.

Codec only.

> If it is done based on both transport and codec, then
> FID provides a useful way of negotiating both codecs and transport in a single
> round-trip. If not, then we'll have to do multiple round-trips (e.g. based on
> SIMCAP information) for this, which I was hoping to avoid.

The thing is that FID is not intended to provide "alternative"
destinations in the sense that one will be used and the other not
(negotiation). FID is intended to be used when all of them will be used,
depending on the codec used at a particular time. I understand your
needs, and I believe that we could define a new semantics for group.
Let's say, ALT. When a UA received m lines grouped with ALT, it would
have to choose one of them.

> Not sure. We'll call you G, me F, and the transcoder T. If I understand the
> example correctly, then either
> a) G sends an SDP with two m lines containing AMR (one RTP and the other
> SRTP), or
> b) G sends an SDP with a single m line containing AMR, and somebody in the
> middle adds another m line for the transcoder.
> 
> In case a), G may end up receiving both the RTP and SRTP stream if F supports
> both, which I don't see why you would want to.

If F is using AMR, I will receive the media stream directly. If F is
using G.711, the media stream will go to T over SRTP. Therefore, at a
particular point of time, I will be receiving only one.

> In case b), there are no
> duplicate codecs on the m line, and hence the example doesn't apply (F sends
> AMR to G or F sends PCMU to T). Did I miss something ?

OK, now I understand why we were talking past each other. FID was
intended to be used when every m line uses a different codec. This way,
you can receive, for the same media stream, different codecs on
different ports or even different network addresses.

However, we had to define what to do if two m lines contained the same
codec. We decided that in that case, the UA had to send media to both m
lines. This can be useful when you have several application servers in
the path that need to receive DTMF tones, for example.

Hope this clarifies things.

Regards,

Gonzalo

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 07 May 2002 09:30:35 -0400

> have to choose one of them.

Not sure I would go down that path as the potential interactions between ALT and FID
seem complex.

> particular point of time, I will be receiving only one.

No. In case a), my SDP contains two media lines with AMR to begin with, one using
RTP and another using SRTP, and hence per your rule that any m line with the codec
in question (AMR) needs a copy of the media, I will get two copies.

> different ports or even different network addresses.

That is my understanding as well, however given that, I do not see why you don't
want the transport to be part of the equality test.

> Hope this clarifies things.

It clarifies the text, but not the rationale. I still don't understand your example
and how it motivates not including transport in the codec equality test - can you
elaborate on it and show me the steps involved (who is sending what SDP).

Thanks

        Flemming

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 May 2002 16:27:44 +0300

Flemming,

> elaborate on it and show me the steps involved (who is sending what SDP).

Here you have a couple of examples:

User A and user B establish a session between them. In this session,
there are two application servers that need to receive the DTMF tones
sent by A (AS1 and AS2).

AS1 happens to use RTP and AS2 happens to use SRTP. I group the three m
lines (voice, DTMF to AS1 and DTMF to AS2) using FID.

Everytime A chooses to send DTMF tones (let's say, payload 96) it will
send packets to both application servers, regardless of which transport
they use.

Another example. You establish a session with me, and I want to record
everything we say. We are in the same intranet (let's assume that I work
for Cisco or that you work for Ericsson :o) ), but my SIP recording
device is outside our intranet, in my metwork at home. I will group both
m lines, the one with my IP address and the one with my SIP recording
device's IP address using FID. Both lines will list all the codecs we
negotiate (this is possible bacuse my recording device simply does an
RTP dump and thus it can receive any codec).

Since my recording device is outside our intranet, it uses SRTP. Now you
send all the time RTP to me and SRTP to my recording device.

I am not suggesting that it is a good idea to make you do this, since it
will consume a lot of resources in your computer, but if this is the
type of session I want to establish, I can describe it using FID in this
fashion.

Regards,

Gonzalo