Subject: resolving open issues in offer/answer

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 02:29:22 -0500

Folks,

I want to try and move swiftly towards closure of the open issues in 
offer/answer. I presented slides at IETF 52 on these issues, which you 
can pick up from:

http://www.jdrosen.net/ietf/52/mmusic_open_dec01.ppt

I want to summarize the issues, and their resolutions, and make sure 
there is consensus. Also, I am having second thoughts on one of them.

ISSUE 1: Allow for changes in the media stream type. There was consensus 
that the answer was yes, which is consistent with the sip wg resolution 
to allow for reuse of zeroed SDP. The text would also note that such 
changes are really for cases where the different media type represents 
the same logical stream, as in the fax/g711 case.

ISSUE 2: Be prepared to send&recv on bidirectional stream when you send 
the SDP. Consensus to update text to indicate that you need to be 
prepared to both send and receive.

ISSUE 3: Multiple streams of the same type. See the slides for the 
issue. My proposal was accepted, with the caveat that we would add 
wording to clarify that the default operation is NOT to copy media from 
your own local sinks to sources, unless you happen to be a conference 
server.

ISSUE 4: synchronizing codec changes. The agreement at the meeting was a 
third proposal. Whenever you send a new offer with a set of codecs which 
  is not the same as the previous, and overlaps in some way, you 
basically use a new dynamic PT for each codec. THis way, when the UA 
receives media with one of those new PT, it can unload any of the codecs 
which no longer overlap.

Since the meeting, I have become worried about this. Basically, any 
useful reinvite will require new dynamic PT for all codecs. You could 
very well exhaust the set of dynamic PT, since there are so few (127 of 
them).

Some other ideas:

1. change the ssrc when you send with the new codec set. The receiver 
can drop uneeded codecs when it sees the new ssrc. This only works for 
unicast.

2. change in set of codecs has to also be accompanied by a port change; 
when you see data on the new port, you can unload any unneeded codecs.

ISSUE 5: Unidirectional codecs in a bidirectional stream. Consensus was 
to disallow this in the baseline offer/answer. Thats what FID is for.
Anything else is a hack.

Please raise any concerns on these resolutions asap.

THanks,
Jonathan R.
-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Dec 2001 10:28:05 -0500

>very well exhaust the set of dynamic PT, since there are so few (127 of 

I don't see why this will be an issue, unless you have many (>64) codecs in
use in a single session. Is that likely to be common?

Colin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 13:21:04 -0500

Colin Perkins wrote:

>>ISSUE 4: synchronizing codec changes. The agreement at the meeting was
>>
> a 
> 
>>third proposal. Whenever you send a new offer with a set of codecs
>>
> which 
> 
>>receives media with one of those new PT, it can unload any of the
>>
> codecs 
> 
>>which no longer overlap.
>>

Its not just the number of codecs; its the PRODUCT of the number of 
codecs and the number of re-invites.

Lets say I have four codecs, A, B, C and D, and each of them has a 
dynamic PT. Now, I do a re-invite to add E. In that re-INVITE, I assign 
NEW dynamic PT numbers to each of those existing four codecs, plus the 
new one. Thats five more dynamic PT. Now, if I re-invite once more, 
removing E, once again, I need to assign new PT to each of the remaining 
four. Thus, I have consumed 13 dynamic PT already.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Dec 2001 14:13:03 -0500

...
>four. Thus, I have consumed 13 dynamic PT already.

Why can't you re-use the old numbers? Aren't we just trying to avoid
confusion during the overlap period?

Colin

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Dec 2001 22:31:13 +0200

Hi,

> confusion during the overlap period?

We have to avoid receiving RTP packets with different codecs with the
same PT. This can happen if we have several re-INVITEs in a short period
of time.

Under normal circumstances this would not be a problem, because you can
use RTP sequence numbers to determine after which packet the PT
identifies the new codec. However, if no RTP is being sent and there are
many re-INVITEs, this might be a problem.

Well, if no RTP is being sent, both UAs will have to rely on timers
anyway, which was what we were trying to avoid.

This might be a corner case that we do not want to worry about. In that
case we could go ahead reuse PTs.

Regards,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Dec 2001 13:56:48 -0500

Comments below - Paul

> prepared to both send and receive.

I don't understand the point in requiring someone to be prepared to
send. 

Even if you are fully prepared to send, you may not send anything
because you just don't have anything to say. Can the spec mandate that
you MUST send something? From a normative viewpoint, it is impossible to
distinguish between not being prepared to send and not wanting to send
anything.

> your own local sinks to sources, unless you happen to be a conference

I don't have any substantial objection to what you propose. But the
first two listed requirements can be met in cursory ways:

- the requirement that sources must be sent to one or more streams begs
the question of when you do or don't have a source. For instance, if I
mute my phone, have I removed a source or have I stopped sending the
source to a stream?

- I believe the bit bucket is a perfectly valid sink. I can always
dispose of input from a stream by conjuring up a bit bucket sink to send
it to.

So, is there any point in imposing these requirements?

> receives media with one of those new PT, it can unload any of the codecs

This proposal is very RTP-centric. It refers almost exclusively to
codecs and payload types, but those are specific to the RTP Audio/Video
profile. The general term in SDP is "media format", and the encoding and
semantics of them are media specific. A general requirement that
mandates use of new dynamic payload types can't fly. There needs to be a
set of general requirements for any kind of media, and then if there are
specific requirements for the RTP Audio/Video profile, then they need to
be expressed as such.

Elaborating on an example from sdp-new, if I have been using

     m=application 32416 udp wb xx

and I want to switch to using

     m=application 32416 udp wb yy

I need to be able to decide when I can stop using xx.

> when you see data on the new port, you can unload any unneeded codecs.

This last proposal might solve the general problem.
Presumably this would be optional - without a port change you have to
use implementation specific heuristics to decide when to unload.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 21 Dec 2001 00:29:11 -0500

Jonathan Rosenberg wrote:

> Since the meeting, I have become worried about this.

I agree. Also, it doesn't work with static payload types not to mention that
I suspect most implementations don't do this kind of thing.

> Basically, any

Actually, I don't even think it does. If you have multiple senders sending
media to you, how do you know which SSRC corresponds to which sender ? Also,
it is possible than an SSRC change might happen for other reasons
(admittedly, we are getting down to a rather small window for this race).

> when you see data on the new port, you can unload any unneeded codecs.

However, such a requirement interacts with resource reservation in a
negative way so I'd rather not do that. Out-of-order delivery could also
lead to unnecesarry discard of some packets (small window again admittedly).

Fundamentally, I don't believe the synchronization problem can be solved
completely and hence we end with a heuristic no matter what. In tha case,
I'd prefer something very simply that doesn't rely on SSRC's, sequence
numbers or is tied to the specifics of the media stream in any other way. I
will contend, that if the answerer sends a media packet and an answer at
time t, then in practice it is *very* likely that the media packet will
arrive no later than the answer at the offerer. In practice, this means that
the offerer MAY simply stop accepting according to the old offer at the time
it receives the answer.

Also note that this issue applies equally well to the answerer, i.e. at what
point does the answerer stop accepting media according to the old
offer/answer exchange (I don't believe there was any text proposed for
this). This problem is actually worse inasmuch as the answerer doesn't know
when/if the offerer actually got the answer (not that I'm proposing it, but
it's hard to see how you can solve this without a 3-way handshake).

One idea would be to put constraints on allowable operation while there is
an outstanding offer in place. More specifically, if the current media
stream has codecs X and Y as allowable codecs and the new offer has codec X
and Z as allowable codecs, then you should not send media with codec Y while
the offer is outstanding. That way, the answerer can stop listening for
codec Y at the time the answer is sent. However, in practice this is
probably not all that desirable, e.g. consider the case where X is RFC 2833,
and Y and Z are voice codecs, or the case where X is a high-bw codec needed
for voiceband date transfer and Y and Z are codecs used for normal voice.

Any other ideas ?

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 21 Dec 2001 00:31:14 -0500

> I don't understand the point in requiring someone to be prepared to

There were two issues here. First one was that we always want codecs listed on
a bi-directional stream to indicate a send and receive capability. Second one
was, that even if you have only sent an initial offer, and not yet gotten a
response, it is possible to send media when using connection-oriented media
streams if the connection is established before you get the answer. In that
case, you need to be prepared to both send and receive at the time of the
offer.

> you MUST send something?

No (nor should it)

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Dec 2001 08:55:40 -0500

Sorry, but I still don't get it.

Let me put it another way. This is adding normative language requiring
the sender of SDP to be prepared to send. How would that be verified? Is
there any possible way to distinguish between being unprepared to send
(nonconforming) and simply having no desire to send (conforming)?

	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 21 Dec 2001 09:10:41 -0500

> (nonconforming) and simply having no desire to send (conforming)?

No, but it ensures, that if the answerer picks any one of those codecs, then the
offerer will actually be able to send, should he so desire.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Dec 2001 17:29:53 -0500

Flemming Andreasen wrote:

>>the sender of SDP to be prepared to send. How would that be verified?
>>
> Is
> 

I think what you are looking for is a sentence that says:

When the offerer receives the answerer, it MAY send media on that stream 
(assuming it is listed as sendrecv or recvonly in the answer). It SHOULD 
use the first media format listed in the answer when it does send.

I will add that. I agree with Paul that saying you MUST be prepared to 
send when you generate an offer is pointless, since it can't actually 
send, and therefore there is no way to actually verify this requirement.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 13:03:23 -0500

>>codecs which no longer overlap.
>>

Good point on static payload types.

> (admittedly, we are getting down to a rather small window for this

Realistically, for this to work, you would need to include the actual 
SSRC rather than simply waiting for a change in the ssrc. That would 
resolve the issues you raise above, but requires an additional SDP 
parameter.

Its worth noting that there is another advantage of the ssrc parameter, 
which is that it will allow us to correlate a media stream from a 
particular source to a specific dialog, in the event the demux is not 
done at the port level. This will happen in the case where we have a 
forked INVITE that results in two 200 OK. Each answerer will end up 
sending to the same offererd port. Having something in the answer, like 
the ssrc, which will allow for disambiguation, would help.

Of course, there is the associated ugliness with collisions resulting in 
a change in ssrc....

However, this proposal is worth further consideration. It gives us an 
explicit, reliable, rapid way to associate media streams with signaling, 
and I think thats fairly valuable. I will admit that changing SSRC might 
introduce some confusion into systems; I welcome inputs on specific 
problems it might cause.

>>2. change in set of codecs has to also be accompanied by a port
>> change; when you see data on the new port, you can unload any unneeded codecs.
>>
> 

Good point on the resource reservation. It would also force SRTP 
rekeying for the same reasons. There is also the general "don't use 
addresses/ports for application layer indications" as these eventually 
get you in trouble with nat. No need to add more such things at this time.

> the offerer MAY simply stop accepting according to the old offer at the

This is more or less exactly what I proposed initially in the meeting; I 
just added 1m for safety.

> it's hard to see how you can solve this without a 3-way handshake).

The SSRC proposal above would solve that.

> for voiceband date transfer and Y and Z are codecs used for normal

It also wouldn't work in the case where the new offer has no codecs in 
common with the old. Furthermore, if the intersecting codec was not the 
highest preference one, you would end up using this intermediate codec 
for just one RTT, that probably won't sound all that great.

-Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 04 Jan 2002 12:32:29 -0500

> use the first media format listed in the answer when it does send.

Not really :-)

> send, and therefore there is no way to actually verify this requirement.

I'm obviously doing a poor job of expressing myself clearly, however I
believe we have agreed on the underlying issue (that all codecs listed in a
sendrecv media stream must be supported for send and receive in both the
offer and answer). Given that, I'm happy to leave this for now and just take
a look at the next version of the draft.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 04 Jan 2002 12:58:52 -0500

> the ssrc, which will allow for disambiguation, would help.

That's a good point - it would be very helpful indeed.

> Of course, there is the associated ugliness with collisions resulting in

I think it is imperative, that such an "SSRC" attribute only be advisory in nature,
i.e a hint. If you receive packets with a known SSRC, you know what to do, but if you
receive packets with an unknown SSRC, everything must still work. Also, since not all
implementations would support such an extension, we still need rules for what to do
in the absence of this attribute and/or other SSRCs.

> and I think thats fairly valuable.

I agree.

> I will admit that changing SSRC might

Again, I think it is important to have some flexibility surrounding the use of such
an SSRC attribute, and see it as an optimization hint as opposed to enforcing strict
rules.

As far as problems go, SRTP security contexts (which key off the SSRC) would seem to
be potentially troublesome.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Jan 2002 15:07:07 -0500

>>wording to clarify that the default operation is NOT to copy media
>>from your own local sinks to sources, unless you happen to be a conference
>>server.
>>
> 

Its more that there is a binding between a source and a stream, and if 
the source has data, it gets sent on that stream. In the case of mute, I 
would argue that the source has no data.

> dispose of input from a stream by conjuring up a bit bucket sink to send

It is a question of what behavior is desired by the sender. If the 
sender is collecting media from different sources, it needs to know that 
the general behavior is that all sources will be rendered. If people 
interpret multiple m lines to be "pick one, throw the rest in the 
garbage", then the sender needs to do mixing at its end. So, the 
strength of this incoming stream to actual sink requirement would be 
SHOULD, so that you could still discard a media stream, but only if you 
had some specific reason to do so. That is, the normal behavior would be 
to present everything.

-Jonathan R.