Subject: RE: [Sip] Open Issue #146: Re-use disabled streams

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 15:51:01 -0400

This thread has stalled. Since this is a bis open issue, I would like people
to please make a priority of getting this resolved.

Some comments below.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 2:59 AM
> To: Kim Liu
> Cc: Jonathan Rosenberg; [email-masked]'
> Subject: Re: [Sip] Open Issue #146: Re-use disabled streams
> 
> 
> 
> Hi,
> 
> How about using the FID (or something similar) as a stream identifier,
> identifying a stream for the whole session (not only within a specific
> SDP)? Then it would be very easy to 
> add/remove/change/whatever streams.
> 
> For example, assume a case where I set up a session with 5 streams.
> Then, later in the session, I want to add one stream and remove one of
> the old ones. By using identifiers one does not have to include any
> information about the streams that are not affected by the mid-session
> change.

Using an explicit stream ID would definitely make this issue go away. It
would also solve this particular issue for bis - the base spec disallows
reuse. If you want to reuse, you need to implement the FID extension that
supports this. Allowing reuse is not backwards compatible anyway.

However, its not clear to me that FID, as currently specified, has this
semantic. Here, we are talking about using the stream ID to correlate
streams ACROSS re-invites. I don't think it means that. Its currently meant
to associate streams together within a single INVITE/2xx. I'd appreciate
input from Gonzalo and the mmusic folks about whether or not this usage
fits, and/or should be added, to the fid draft.

> Kim Liu wrote:
> > 
> > 
> > My inclination is to allow reuse, but I don't think it can
> > be done.  Particularly given the restriction on dynamic PT
> > reuse in issue #23. 

These are unrelated. I don't see an issue.

> > Since the INVITE with SDP is used for
> > recovery, reusing/rewriting an old media stream slot in the
> > SDP might erase/hide information about the previous state
> > of the call (which dynamic PTs have been used, plus any
> > endpoint, media, or application specific information
> > associated with the closed media stream) though I am unaware
> > of any application which is doing this today.

Forgetting about reusing stream slots, if you do a re-invite with a new set
of codecs, there is no need to retain the list of old codecs, and their pt.
THus, this information is normally lost anyway. I'm not sure it matters. 

> >  Unfortunately,
> > since the INVITE/200 + SDP is used for call recovery,
> > that reuse will have to be avoided in order to maintain
> > a full history/state of the call in case recovery is
> > necessary.

I do not see why that is needed. The only thing you need to recover is the
current state, not the history. You don't have the history normally anyway.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Kim Liu <[email-masked]>
Date: Fri, 07 Sep 2001 16:01:57 -0400

Jonathan Rosenberg wrote:
[snipped] 
> current state, not the history. You don't have the history normally anyway.

Billing and accounting information (recovery).

It might also be useful as a positive negative to indicate
that was a past history (or at least one end point believes
so) that no longer exists.  This may be useful in recovering
state for certain services (like making sure any open firewall
ports from previous streams are closed, stopping billing for
selfsame, etc.)

Kim Liu
Senior Software Engineer
Lucent Technologies
Clearwater, FL

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 09 Sep 2001 20:10:25 +0300

Hi,

I THINK that the FID currently doesn't support the identifying of
streams for the whole sessions. However, I see no reason why it
shouldn't be possible to update the draft (I guess Gonzalo is the man to
make that decission), or otherwise write a new draft. We may even want
to define more new stream related attributes, so maybe the name should
be "SIP multimedia support", or something...

Of course, IF we would put the whole media handling in a specific draft,
the question is if this would be included there too.

I don't see too big backward compability issues with this - since it
currently simply doesn't work. And, if needed it is always possible to
define an option-tag for the feature, so...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 14 Sep 2001 23:11:15 +0300

Hello,

> make that decission)

My first idea related to FID was to use it exactly for this purpose:
"SDP media alignment". However, the optimization I was thinking of at
that point of time was a different one. If a UAC sends an INVITE with
two m lines and the UAS wants to establish a session with 3 m lines the
server needs to accept the session and later re-INVITE. With an m line
identifier it is possible to add new streams in the 200 OK and then get
the final SDP in the ACK.

This would have been a big gain (3 messages instead of 6), but it
requires a 3-way handshake. SIP just provides a 2-way handshake
(regarding SDP exchange). Using a 3-way handshake would make 3pcc
impossible. That's why we abandoned that original idea.

Now, coming back to our current problem, using identifiers just to reuse
m lines is overkill. We just need to allow that the position of an m
lines that has been answered with port zero can be reused. Adding stream
identifiers does not give us any extra gain.

Therefore, let us focus in our real problem. The decision we have to
make is: can a UA reuse a position in the SDP when that media stream has
been rejected?

My personal opinion is: if any implementor has a problem with this,
let's keep the mechanism as it is right now (that is, we dissallow
position reuse). If implementors feel that this change will not break
significally their code, let's go for it.

Regards,

Gonzalo

, or otherwise write a new draft. We may even want

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Sep 2001 08:46:26 +0300

Hi,

> the final SDP in the ACK.

I guess that sounds ok. However, considering the manyfolks mechanism
(using 18x and PRACK for the negotiation), in that case we would going
towards two different methods of doing 3-way handshake...

I think the problem is, that so far we have been talking pretty much
about codecs ("I tell you what codecs I support in the INVITE, and you
tell me what codecs you support in the 200..." - period. ), and not
multiple streams. 

So, one question is: if A initiates the session, giving one or more
streams, should B be allowed to add more streams in the session
establishment? One could say no, and that B must send a re-INVITE after
the 200/ACK if it wants to add more streams.
 
>significally their code, let's go for it.

I agree that this was the initial problem, but I think they are related
to each other. If we DO have a mechanism to identify the streams per
session, it is then easier to come up with mechanisms/rules how to
re-use them - AND how to add/remove streams during the call WITHOUT
having to re-send the whole SDP in the re-INVITE.

We should also remember that "setting the port to zero" is very IP
specific (similar to the media on-hold issue), so  it won't work very
good with ATM.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 17 Sep 2001 18:18:05 +0300

Hello Christer,

> towards two different methods of doing 3-way handshake...

No, we are not. 18x and PRACK is still an offer/answer model.

> the 200/ACK if it wants to add more streams.

This is exactly what I have explained in my previous mail. Since we use
an offer/answer model, the callee needs to re-INVITE in order to add
more streams. This was discussed a lot of IETFs ago in the MMUSIC
session.

> having to re-send the whole SDP in the re-INVITE.

Sending the whole SDP in the INVITE is NOT a disadvantage. It is a
desing rule that SIP developers MUST follow. It avoids synchronization
problems and allows easier failure recovery.

And as I said before, it is not necessary to have identifiers in order
to reuse stream positions.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Sep 2001 14:31:06 +0300

Hi,

First, I would like to go back a few mails, to the original issue, so
let's forget all FIDs, stream IDs etc for a couple of seconds.

Assume that A sends the following:

m=audio 100 RTP/AVP 1 2 3
m=audio 200 RTP/AVP 2 3 4

Now, B wants to use different ports for different codecs, but B doesn't
support any related SIP extensions (FID, for example), so the reply may
look something like:

m=audio 300 RTP/AVP 1
m=audio 400 RTP/AVP 2
m=audio 500 RTP/AVP 3

Now, there is NO way for A to know which m= line (except, in this case,
the first) in the response maps to which m= line in the request, so I
don't agree with what Jonathan said in the initial mail ("This works
because there is never any confusion about which streams correspond to
which.") 

So, before we even come to the issue of REPLACING/REUSING streams we see
that this does NOT work. So, the question is: shall bis forbid this kind
of behaviour, and state that there MUST be a 1:1 mapping between the m=
lines in the request and response, and separate ports within a single
logical stream can NOT be used? And, is this really a backward
compability issue, since it doesn't work anyway? Or, have I missed
something? 

Then, IF someone wants to "split" an m= line into multiple m=lines
(still defining a single logical stream), using separate ports etc some
SIP extension MUST be used.

Then, assuming that this extension would be the FID draft (let us still
forget about all other stream IDs etc which have been proposed), I think
there would need to be an option-tag, to be used in the Supported- or
Require header, to inform the UAS that the feature is supported. The FID
draft currently DOES say (chapter 6.4) that the grouping must be
requested by the UAC. But, how does that work in the example above?

a=group:FID ?
a=group:FID ?
m=audio 100 RTP/AVP 1 2 3
a=mid: ?
m=audio 200 RTP/AVP 2 3 4
a=mid: ?

Should we allow something like:

a=group:FID a b c
a=group:FID d e f
m=audio 100 RTP/AVP 1 2 3
a=mid: a b c
m=audio 200 RTP/AVP 2 3 4
a=mid: d e f

Also, if A now wants to remove one codec from one group, the re-INVITE
could look like:

a=group:FID a b
a=group:FID d e f
m=audio 100 RTP/AVP 1 2
a=mid: a b
m=audio 200 RTP/AVP 2 3 4
a=mid: c d e

Now, where did stream 3 (a=mid: c) go? It is still supposed to be in the
SDP, so I guess the re-INVITE MUST look like:

a=group:FID a b c
a=group:FID d e f
m=audio 100 RTP/AVP 1 2
a=mid: a b
m=audio 0 RTP/AVP 3  (NOTE: Port set to zero, since A wants to remove
this codec from the stream!)
a=mid: c
m=audio 200 RTP/AVP 2 3 4
a=mid: d e f

Anyway, since the FID draft does not allow multiple identification-tags
in a single mid, this doesn't work.

A possible solution would be to make it MANDATORY for the UAC to only
include ONE codec per m= line from the beginning, EVEN if the same port
is used for each of them:

a=group:FID a b c
a=group:FID d e f
m=audio 100 RTP/AVP 1
a=mid: a
m=audio 100 RTP/AVP 2
a=mid: b
m=audio 100 RTP/AVP 3
a=mid: c
m=audio 200 RTP/AVP 2
a=mid: d
m=audio 200 RTP/AVP 3
a=mid: e
m=audio 200 RTP/AVP 4
a=mid: f

Now, it would also be no problem to issue the re-INVITE:

a=group:FID a b c
a=group:FID d e f
m=audio 100 RTP/AVP 1
a=mid: a
m=audio 100 RTP/AVP 2
a=mid: b
m=audio 0 RTP/AVP 3 (NOTE: Port set to zero!)
a=mid: c
m=audio 200 RTP/AVP 2
a=mid: d
m=audio 200 RTP/AVP 3
a=mid: e
m=audio 200 RTP/AVP 4
a=mid: f

Now, one could think that this is fine and works, but it actually brings
us to my next question :)

Chapter 6.2. in the FID draft says that the mid value in a response MUST
be the same as the mid value in the request. So, let's take the example
above again.

A sends:

a=group:FID a b c
a=group:FID d e f
m=audio 100 RTP/AVP 1
a=mid: a
m=audio 100 RTP/AVP 2
a=mid: b
m=audio 100 RTP/AVP 3
a=mid: c
m=audio 200 RTP/AVP 2
a=mid: d
m=audio 200 RTP/AVP 3
a=mid: e
m=audio 200 RTP/AVP 4
a=mid: f

Now, B only supports ONE codec per stream, ie it will only send 2 m=
lines back, so how can it do a 1:1 mid mapping???

a=group:FID ?
a=group:FID ?
m=audio 300 RTP/AVP 1
a=mid: ?
m=audio 400 RTP/AVP 3
a=mid: ?

Or, B could reply with:

a=group:FID a b c
a=group:FID d e f
m=audio 300 RTP/AVP 1
a=mid: a
m=audio 0 RTP/AVP 2 (NOTE: Port set to zero!)
a=mid: b
m=audio 0 RTP/AVP 3 (NOTE: Port set to zero!)
a=mid: c
m=audio 0 RTP/AVP 2 (NOTE: Port set to zero!)
a=mid: ?
m=audio 400 RTP/AVP 3
a=mid: ?
m=audio 0 RTP/AVP 4 (NOTE: Port set to zero!)
a=mid: ?

However, I am not sure this is a good solution, to put ports to zero
only to indicate that the UAS don't support the same codecs as the
UAC...

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bert Culpepper" <[email-masked]>
Date: Tue, 18 Sep 2001 16:56:57 -0400

Hi Christer,

comments inline...

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Christer Holmberg
> Sent: Tuesday, September 18, 2001 7:31 AM
> To: Gonzalo Camarillo
> Cc: Jonathan Rosenberg; Kim Liu; [email-masked]'

First of all, this reply indicates three streams are supported by the
sender.

> because there is never any confusion about which streams correspond to

A does know by matching m= lines as specified in rfc2543 (and bis), B has
added a third stream.  B has also indicated that it only supports codec 1 in
the first stream and only supports codec 2 in the second stream.  The two
endpoints can exchange media successfully provided A complies with B's
capabilities.  B's added third stream is of no use since A only specified
its support for two streams in this session.

My read of Jonathon's statement you reference was dealing with session
descriptions with matching number of m= lines and how re-use of a disabled
stream should be "understood".

> logical stream can NOT be used?

It does work IMHO (maybe not as you intended). With current offer-answer
model only a 1:1 mapping makes sense.  Current SDP "disallows" separate
ports within a single stream.  (As I myself have said on another list, my
vocoders can't handle different media encodings on the same port.  So I
would respond as you indicated above, only two media streams though.)

 And, is this really a backward
> SIP extension MUST be used.

Correct, it's not supported today that I know of.

On the original issue, reusing disabled streams (m= lines), It won't bother
me one way or another.

Others will have to respond to the rest of this message as I don't
understand the correct use of the FID myself :)

Regards,
Bert

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Sep 2001 14:16:55 +0300

Hi Bert,

>>Now, B wants to use different ports for different codecs, but
>>B doesn't support any related SIP extensions (FID, for example), so the
>>reply may look something like:
>>
>>m=audio 300 RTP/AVP 1
>>m=audio 400 RTP/AVP 2
>>m=audio 500 RTP/AVP 3
>>
> 

I know. So, different codecs using different ports doesn't work in basic
SIP.
 
>>Now, there is NO way for A to know which m= line (except, in
>>this case, the first) in the response maps to which m= line in the request, so I

True. So, again: different codecs using different ports doesn't work,
and there MUST be a 1:1 mapping between the m= lines in the request and
the response.

>stream should be "understood".

You are correct. I appologise.

>>So, before we even come to the issue of REPLACING/REUSING
>>streams we see that this does NOT work. So, the question is: shall bis
>>forbid this kind of behaviour, and state that there MUST be a 1:1 mapping
>>between the m= lines in the request and response, and separate ports within a single
>model only a 1:1 mapping makes sense.

Yes. And THAT is the point I wanted to make :)

>Current SDP "disallows" separate ports within a single stream.

That may be true, but for example H.248 has a way to solve that.

>(As I myself have said on another list, my
>vocoders can't handle different media encodings on the same port.  So I would respond as you indicated above, >only two media streams though.)

Yes, but then you would indicate two separate streams, and not a single
logical stream using two m=lines...

And, maybe my example wasn't a very clear one. For example:

A sends:

m=audio 100 RTP/AVP 1 2
m=video 200 RTP/AVP 99

B replies:

m=audio 300 RTP/AVP 1
m=audio 400 RTP/AVP 2
m=video 500 RTP/AVP 99

...would not work (2 m= lines are "mapped" into 3 m=lines...), again
because separate ports are used for different codecs.

So, if we in bis define all the restrictions we have defined I guess
it's ok. After that we'll have to fix the issus in the FID draft.

Also, another question: if B does not want the FIRST stream in the list
to be used during the session, does it then answer:

m=audio 100 RTP/AVP 1 2
m=audio 200 RTP/AVP 3 4

m=audio 0 RTP/AVP 1 2
m=audio 300 RTP/AVP 3 4

>>And, is this really a backward compability issue, since it doesn't work anyway? Or, have I missed
>>something?
>>
>>(still defining a single logical stream), using separate
>>ports etc some SIP extension MUST be used.
>

No problem :) Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bert Culpepper" <[email-masked]>
Date: Wed, 19 Sep 2001 11:15:48 -0400

We're moving away from the original issue but... a comment or two below.

> Sent: Wednesday, September 19, 2001 7:17 AM
> To: Bert Culpepper
> Cc: [email-masked]

I've wondered if/when someone would solve that problem :)

> >vocoders can't handle different media encodings on the same
> port.  So I would respond as you indicated above, >only two
> media streams though.)
>

I agree, I would be using separate streams (as defined).

> because separate ports are used for different codecs.

I agree.  B has "messed up" in its response (without indicating some
extension).

> to be used during the session, does it then answer:

Is there a typo above? :)  The second set with the 2nd m= line referring to
video and payload type 99 is the correct answer IMO.

Regards,
Bert

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Sep 2001 22:10:38 +0300

Hello Christer,

We are discussing exactly the same things as we discussed in MMUSIC when
the FID draft was first released. Anyway, I will try to put together an
answer to your mail.

First of all, if you send an INVITE with n media lines, the 2xx response
MUST contain n media lines. This is needed because the UAC matches the
nth media line in the INVITE with the nth media line in the 2xx.

Even if we label the lines (using mid, for instance), the UAS still MUST
to return a 2xx with the same number of n lines as the INVITE. Let me
illustrate this with an example:

INVITE
m=audio 10000 RTP/AVP 0 8
a=mid:a

200 OK
m=audio 10000 RTP/AVP 0
a=mid:a
m=audio 10000 RTP/AVP 8
a=mid:a

The example above does NOT work because the UAS does not have a remote
port to send RTCP for the m line that has been added in the 2xx. That's
why we abandoned that solution.

I hope that with this answer and with the FID draft everything is clear
now.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2001 08:06:40 +0300

Hola Gonzalo,

>nth media line in the INVITE with the nth media line in the 2xx.

Yes, this is how it's done in the basic SIP, and I think that we can
agree on that is how it will be in bis.

However, that does not give one the opportunity to use different codecs
for different ports, and that is the other issue I brought up.
 
>port to send RTCP for the m line that has been added in the 2xx.

That is true if you assume that you must have a 1:1 mapping in the
request and response, which I think we have agreed will be the case in
bis. But, my issue was to come up with an extension/mechanism that gives
us the oportunity to have 1:1 logical stream mapping, BUT one stream may
consist of multiple m= lines. Of course every node must then understand
that extension to make it work, so we would have to define an option-tag
for it.
 
>I hope that with this answer and with the FID draft everything is clear

It is not about the FID draft. I DO understand what it does, but the
point was that it currently doesn't solve the issue I brought up :) 

So, the question is: are we not going to support different codecs on
different ports, within in single logical stream (indicated by the mid:a
for both m= lines), in SIP - unless it's done in both directions, in the
same way, so that we can have a 1:1 m= line mapping, and then group them
together using FID???

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2001 09:42:56 +0300

Hi,

>>Also, another question: if B does not want the FIRST stream
>>in the list to be used during the session, does it then answer:
>>
>>m=audio 100 RTP/AVP 1 2
>>m=audio 200 RTP/AVP 3 4
>>
>>m=audio 0 RTP/AVP 1 2
>>m=audio 300 RTP/AVP 3 4
>>
> 

No, this was a new example :) But, I'll use different media types to
make it more clear.

A sends:

m=video 100 RTP/AVP 99
m=audio 200 RTP/AVP 3 4

Now, B does not support video, so it replies:

m=video 0 RTP/AVP 99 (Note: Port set to zero!)
m=audio 200 RTP/AVP 3 4

Is this correct?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 20 Sep 2001 18:35:12 +0300

Hello Christer,

> But, my issue was to come up with an extension/mechanism that gives
> consist of multiple m= lines. 

What you are asking for is exactly what FID does. Please, read the 04
version of the draft. It contains many examples.

The following one is taken directly from the draft:

The session description below would be the SDP sent by a SIP user
agent using a cellular access. The user agent supports GSM on port 
30000 and AMR on port 30002.

         v=0
         o=Laura 289083124 289083124 IN IP4 two.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 3
         a=rtpmap:3 GSM/8000
         a=mid:1
         m=audio 30002 RTP/AVP 97
         a=rtpmap:97 AMR/8000
         a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-
      neighbor; maxframes=1
         a=mid:2

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2001 21:15:36 +0300

Hi,

>          a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-

I am aware of this example, but again it assumes that there is a 1:1
mapping of the m= lines in the request and the response. What I am
talking about is a scenario where, for example, the UAC can receive both
codecs on the same port, so it only includes one m=line, but the UAS can
not, so it includes two m= lines.

UAC/INVITE

m=audio 30000 RTP/AVP 3 97

UAS/200 OK

m=audio 10000 RTP/AVP 3
m=audio 20000 RTP/AVP 97

Again, this does NOT work in basic SIP, so let's focus on the extension.

My proposal is to use an identifier (sid, mid, whatever...) that defines
a single logical stream, no matter how many m= lines there are. Every m=
line with the same identifier then belongs to the same single logical
stream.

Example:

UAC/INVITE.

m=audio 30000 RTP/AVP 3 97
a=sid:1

UAS/200 OK

m=audio 10000 RTP/AVP 3
a=sid:1
m=audio 20000 RTP/AVP 97
a=sid:1
m=audio 1000

Later, the UAC wants to replace the stream (sid:1) with a new stream.
However, this time it is not available to receive both codecs on the
same port.

UAC/re-INVITE

m=audio 30000 RTP/AVP 4
a=sid:1
m=audio 40000 RTP/AVP 5
a=sid:1

The UAS, however, can now handle both of those codecs on the same port,
so it indicates that in a single m=line

UAS/200 OK

m=audio 60000 RTP/AVP 4 5
a=sid:1

I hope that this example shows my point, and why I think that FID
doesn't solve it :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 20 Sep 2001 21:47:45 +0300

Hello Christer,

You are raising issues that have already been discussed in this thread.

As I said in a previous mail, REGARDLESS of the fact that we label or
not the m lines, the SDP in the 2xx MUST have the same number of m lines
as the SDP in the INVITE (or in the ACK, if that was the case). As I
explained in a previous mail, this is needed because RTCP has to be
sent.

Therefore, take the SDP of my example and put it in an INVITE. The 2xx
response will have 2 m lines as well. The UAS issuing the 2xx cannot
receive both codec in the same port because it would screw RTCP
statistics up. Besides, the RTP RFC explicitily says that different m
lines have to be demultiplexed using port numbers, no RTP headers.

Again, we had this discussions already a long time ago in MMUSIC.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2001 21:41:07 +0300

Hola,

>lines have to be demultiplexed using port numbers, no RTP headers.

In that case I don't understand why we allow multiple codecs in a single
m= line in the first place, since the remote party is allowed to use any
of those, and switch from one codec to another when/if it wants...
 
>Again, we had this discussions already a long time ago in MMUSIC.

Well, "a long time ago" people only talked about voice and G.711 anyway
- now we're in another situation :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 22 Sep 2001 04:32:38 +0300

Hello,

About bug#146 (bug#24): re-enable media streams. Let's try to resolve
it.

We have already figured out that this bog does not have anything to do
with labeling m lines and with the FID draft... good!

Let's analyze how much we gain re-using m lines. m lines that are
answered with port 0 do not need to carry associated "a" lines anymore.
Therefore, we will have something like:
m=audio 0 RTP/AVP 3

This is 19 bytes.

However, since the media stream has been disabled, we do not need the
payload type (codec). Besides, we do not need to carry RTP/AVP either.
So, the m line would look like:

m=audio 0

This is 9 bytes.

So, every time we disable a stream we have to carry 9 extra-bytes in the
SDP. While it might be desirable to get rid of this garbage, I do not
think it is such a big deal.

So, if there is just one implementation that would be broken if we allow
re-use of media streams, I am happy disallowing it in the spec.

However, if all the implementations can cope with this, we can safely
allow it. So far I think that nobody has spoken up saying that reusing m
lines would break his implementation... if you have one, SPEAK UP!

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 22 Sep 2001 11:12:06 +0300

Hi,

At least I support the idea that we should allow the re-use of streams,
if implementations support that.

However, I would like to discuss (I have mentioned this earlier) if we
really should use the port number. How would it work in ATM? Also, in
Megaco there is a draft on using SDP for TDM circuits. I don't remember
if the m= line is used there, though, but the point is that the port
number is very IP specific (compare to 0.0.0.0 to put call on hold).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 Sep 2001 16:39:49 +0300

Hello Christer,

Yes, setting the port to zero is IP specific. However, current SIP
systems use that mechanism to refuse streams, so, regardless of whether
we come up with a new mechanism for refusing streams for ATM, TDM, etc.,
or even a generic mechanism, we have to resolve the re-use of streams in
an IP environment. This is a backwards compatibility issue.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2001 07:45:25 +0300

Hi Gonzalo,

>an IP environment. This is a backwards compatibility issue.

I agree it should work, for backward compability, like the 0.0.0.0 to
put media on hold. But, at the same time I think we should define a new
mechanism (using an SDP attribute again, I guess) to encourage people
not to use the port-zero-mechanism in future implementations.

Regards,

Christer Holmberg
Ericsson Finland