Subject: [MMUSIC] supporting just one codec at a time

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Jan 2002 16:47:23 -0500

Folks,

I've been combing through the sip-implementors and sip lists, looking 
for open issues that need resolution, or comments that needed addressing 
in the specification. This is the source of much of my spamming on 
sip-implementors....

An issue that has arisen time and time and time again, is the need for 
an endpoint to indicate in its SDP that it can do any one of these three 
codecs, but can only do one at a time, that is, it doesn't support 
dynamically changing codecs on the fly. Since the question has been 
asked 1/2 dozen times on sip-implementors, and concerns both sip and 
mmusic, I have cross posted. If the thread takes off we'll trim it to a 
single list.

The response I gave to people who asked about it, was that this was what 
simcap 
(http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) 
was for, and to go read that. However, after a discussion with Flemming, 
it appears I misinterpreted that specification. It is merely a 
declaration of the codes that an endpoint can support. This information 
would be used in subsequent offer/answer exchanges, so that a UA can 
make an offer without having to guess whether it would or wouldn't be 
accepted. I was under the false impression that the point of simcap was 
to, in fact, solve this particular problem of one-codec-at-a-time for 
the initial exchange.

So, we are faced with this gap of how to handle this problem. I see a 
few solutions:

1. Use a three-way handshake in SIP, using offer/counter-offer/answer.

The offer would list ALL the codecs the UA can do, the counter-offer is 
the subset that the other UA can do, and the answer can reduce it 
further to just a few.

This solution would require us to define this 3-way handshake somewhere; 
that is still being debated as an open issue. Bill has included this 
already in manyfolks, partly to solve this problem (or maybe entirely to 
solve this problem).

2. Define a backwards compatible usage of simcap to modify the 
offer-answer exchange.

The offer would contain an m line with a single codec choice (in this 
particular case where it can do only one a time), but the offer would 
include simcap attributes indicating support for other codecs. The 
answerer could choose from amongst those codecs in formulating the 
answer. So, for example:

Offer:

m=audio 8778 RTP/AVP 0 76
a=rtpmap:76 telephone-event
a=sqn:0
a=cdsc: 1 audio RTP/AVP 0 76
a=cdsc: 3 audio RTP/AVP 1 76
a=cdsc: 5 audio RTP/AVP 2 76

This offer means that the offerer is definitely using PCMU with someone 
that doesn't understand simcap, but is indicating they can also do 
codecs 1 and 2 (and each of them with rfc2833). The answerer could pick 
one of those alternate cdsc in the answer:

m=audio 7554 RTP/AVP 1 76
a=rtpmap:76 telephone-event

We would probably need to define an additional attribute in the SDP that 
indicates that this "simcap effects the m line selection" semantic is 
being followed.

This approach may confused intermediaries that are assuming a subset of 
codecs in the answer.

3. Define a sort-of backwards compatible usage of simcap with offer/answer

In this model, the offerer lists all codecs they can do in the offer. 
They include simcap declarations as well. As with normal offer/answer, 
the answerer has to pick a subset, but they use the simcap declarations 
to help them pick a subset which is an allowed capability. So, in the 
example above where the caller can do codecs 0,2,3,4 along with 76, but 
only ONE of 0,2,3,4 at a time, the O/A would look like this:

OFFER:

m=audio 8778 RTP/AVP 0 1 2 76
a=rtpmap:76 telephone-event
a=sqn:0
a=cdsc: 1 audio RTP/AVP 0 76
a=cdsc: 3 audio RTP/AVP 1 76
a=cdsc: 5 audio RTP/AVP 2 76

ANSWER:
m=audio 7554 RTP/AVP 1 76
a=rtpmap:76 telephone-event

If, however, the UAS doesn't understand simcap, its possible that 
they'll return an SDP listing all four codecs, and possibly change them 
on the fly. That can be fixed, in general, by another re-invite which 
lists only a single codec. This will work, but might cause an RTT worth 
of media to be sent using a codec different from the one the UAC 
"loaded" into the DSP.

4. Declare that simcap is overkill for this one problem, and define a 
single attribute, a=pickone, which says to choose only one of the codecs 
in the m line.

The "I can do one of N, but only one at a time" problem, IMHO, the only 
capability problem that anyone actually has in real usage. I will note 
that, in fact, this is the only capabilities question ever asked on 
sip-implementors.

A single attribute would easily solve it. If you want to do rfc2833 
along with any one of N other codecs, you could use fid along with this, 
to include an m line with the rfc2833, and then another m line with the 
N codecs and the a=pickone attribute.

One way or another, we need to solve this problem. My apologies for 
bringing this up so late, but I had thought it was solved (I thought it 
implied approach #3 above).... comments on the various alternatives?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            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

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

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 04 Jan 2002 17:48:15 -0500

> N codecs and the a=pickone attribute.

simcap is indeed overkill for this and I like new attribute as long as we relax
the requirement currently in offer-answer:
    "Once the offerer has sent the offer, it MUST be prepared to receive
   media described by that offer."

If this is not relaxed the offerer cannot know which of the list of codecs to
receive with and may not be able to listen with all of them until receiving the
answer.

Of course simcap can still be used in addition to this to indicate media that can
be supported but not initially opened (e.g., rfc2833).

> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: "Jerry Yin" <[email-masked]>
Date: Fri, 4 Jan 2002 18:49:27 -0500

Hi there,

After I read the simcap
(http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx
t), I found that it is not backwards compatible with the SDP (RFC 2327).
Here's my comments.

1. the rtpmap's format in RFC 2327 is

    a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
     parameters>].
While in simcap, it is :
    a=rtpmap:<payload type> telephone-event

    Where is the "telephone-event" defined as an encoding name? If the UA is
implemented according to RFC 2327, how can it talk to the UAs implemented
according to the simcap?

2. The "m=" header and "a=rtpmap" in RFC 2327 is good enough to describe the
media attributes already. I don't know why it is necessary to define a new
attributes of "a=cdsc" and "a=cpar". There are some redundant information
here, I think.

3. If we want to describe a subset of capabilities among all capabilities
the SDP claimed, we can simply introduce one new attribute to describe the
subset. For example,
   a=subset subset_codec_number : total_codec_number.
This way, even some UAs don't understand a = subset, they still can talk
with the one supports this attribute by at list one media streaming.

Here's an example:
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
a=subset 2:3
m=video 3458 RTP/AVP 26 31
a=rtpmap:26 JPEG/90000
a=rtpmap:31 H261/90000
a=subset 1:2

This packet means the sender can support two audio streams among three
different codecs {L8, L16, and L16-stereo} and one video stream of JPEG or
H261.

Above all, it is not a good idea to introduce new headers only if 1)
backwards compatible, 2) really necessary and can solve problems, 3) easy to
implement.

Thanks,

Jerry Yin

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: Friday, January 04, 2002 4:47 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [Sip-implementors] supporting just one codec at a time
>
>
> Folks,
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 08 Jan 2002 16:33:21 -0500

> one of those alternate cdsc in the answer:

That's a slight overloading of the simcap semantics which doesn't define any kind
of grouping of capabilities. Normal usage of simcap would only list a given
capability once (per media stream at least). If you wanted to express something
like the above, you would really want to define a new attribute that could
describe allowable combinations of codecs, however that level of expressiveness
was outside the scope of the simcap specification.

> indicates that this "simcap effects the m line selection" semantic is

Right.

> a=cdsc: 5 audio RTP/AVP 2 76

Again, this is a slight overloading of the simcap semantics.

> N codecs and the a=pickone attribute.

However that would require use of multiple ports which could lead to multiple
resource reservations. Also,
- fid cannot be added by the answerer if the offer didn't include it due to the
media stream matching rules
- if fid is included in the offer, but not supported by the answerer, the handling
may not be all that graceful.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 08 Jan 2002 16:34:39 -0500

>    media described by that offer."

That would be a radical change from present-day SDP semantics.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 08 Jan 2002 16:40:52 -0500

>     a=rtpmap:<payload type> telephone-event

No. There's simply an example which has made an editorial mistake in omitting
the <clock rate>.

>
>
>     Where is the "telephone-event" defined as an encoding name?

RFC 2833.

> If the UA is

Per RFC 2327, unknown attributes are simply ignored and simcap just defines a
couple of extra attributes that can be ignored at will.

> attributes of "a=cdsc" and "a=cpar". There are some redundant information

SDP has well-known shortcomings when it comes to capability description and
negotiation. See e.g.
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-req-01.txt for an
analysis of these.

> subset.

> For example,

They can, but not with the semantics you intended.

> different codecs {L8, L16, and L16-stereo} and one video stream of JPEG or

This doesn't work if the receiver doesn't understand the "subset" attribute,
hence it's not backwards compatible.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jan 2002 00:10:29 -0500

Flemming Andreasen wrote:

>>This offer means that the offerer is definitely using PCMU with
>>
> someone
> 
>>codecs 1 and 2 (and each of them with rfc2833). The answerer could
>>
> pick
> 

I understand that now as well, once again, my misinterpretation of the 
simcap spec. Clearly I thought it was solving something that it is not. 
This leaves a larger hole than I thought.

>>single attribute, a=pickone, which says to choose only one of the
>>codecs in the m line.
>>along with any one of N other codecs, you could use fid along with
>>this, to include an m line with the rfc2833, and then another m line with
>>the N codecs and the a=pickone attribute.
>>
>>
> 
> resource reservations. 

Why? The rfc2833 could be on the same port, no?

>Also,

Correct. That seems less of an issue, since if the offerer lists 
everything it can do, and the answerer is constrained, it can simply 
select one codec.

Right.

I am not wed to this specific mechanism. However, from my 
hopefully-now-correct understanding of simcap, it seems that it simply 
doesn't help at all with this issue of doing only one codec at a time. 
So, options 1 and 2 above are no-go.

Another possibility is to add an extension to simcap which allows you to 
convey this one particular constraint.

-Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 09 Jan 2002 09:20:09 -0500

> Why? The rfc2833 could be on the same port, no?

No. The fid-draft does not allow the different "m=" lines to have the same
destination  (IP address and port)

> doesn't help at all with this issue of doing only one codec at a time.

It doesn't solve this particular problem by itself, however it provides a
mechanism that can be used to help solve it while remaining backwards
compatible. In its present form, you can send an INVITE/offer listing only one
codec in the "m=" line, and then include all codecs supported in the
capabilites. The answerer can accept this, and then do another re-INVITE
picking one or more codecs from the capabilites if you wants to use a different
one.

> convey this one particular constraint.

Right. In that case you would probably also define an offer/answer extension
that would the answerer to pick codecs from the capabilities, and not just the
"m=" line.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Paul Long" <[email-masked]>
Date: Wed, 9 Jan 2002 11:26:49 -0600

Jonathan,

Regarding your (rhetorical?) question, "The rfc2833 could be on the same
port, no?", there is no SHALL in the statement, but it sounds like RFC 2833
packets are intended to always be on the same port as the audio stream:

3.1/RFC2833: "DTMF digits and named telephone events are carried as part of
the audio stream..."

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jonathan
Rosenberg
Sent: Tuesday, January 08, 2002 11:10 PM
To: Flemming Andreasen
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a
time

Flemming Andreasen wrote:

Right.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jan 2002 12:50:17 -0500

> picking one or more codecs from the capabilites if you wants to use a different

How about a variant of this - an Invite where the offer includes *no* m=
lines, but uses simcap to describe what is available. The recipient
would be expected to accept the invite with no media, perhaps also
returning capabilities. Then one side or the other need to send a
reinvite to establish media.

This provides the extra round trip to do negotiation. But it requires
significant support from all parties.

An alternative that I was going to mention is to precede the INVITE with
an OPTIONS request to discover what the other side is capable of. But it
suffers from a serious problem - it doesn't establish a dialog, so there
is no guarantee that the subsequent INVITE will go to the same place.

	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 14 Jan 2002 17:42:34 -0500

Paul Kyzivat wrote:

> lines, but uses simcap to describe what is available.

That wouldn't be backwards compatible or RFC 2327 conformant for that matter.

> The recipient

Right. Apart from the above, I'm also not a big fan of requiring the extra
round-trip. Default behavior should work with just a single round-trip, but further
refinement (or changes) may require an extra round.

> is no guarantee that the subsequent INVITE will go to the same place.

Right - good point (it's also SIP specific as opposed to more general offer/answer).

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2002 18:45:10 -0500

Flemming - more comments below.

	Paul

> That wouldn't be backwards compatible or RFC 2327 conformant for that matter.

Why? It is legal to negotiate a media-less session. And an SDP body
constitutes an offer even if it doesn't contain any m= lines. This would
of course mean that the capability descriptions would all have to be
session-level.

So, the offer would contain a request for a session with no media, but
with capability descriptions for supported media. The response would
agree to the session with no media and return capability descriptions.
Then one side or the other would initiate a re-invite, offering media
compatible with the capabilities supported by both sides.

> refinement (or changes) may require an extra round.

Well, you only do this if you don't know what to offer initially.

You can also implement half of this techique: if you receive an offer
with media that you can't support, you could accept the invite but
refuse the media, and include a simcap description of what you would be
willing to accept. Then hope for a reinvite. If the offerer doesn't know
how to deal with this, ought to send bye to media-less session.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 14 Jan 2002 22:33:02 -0500

> of course mean that the capability descriptions would all have to be

You're right - my mistake.

> agree to the session with no media and return capability descriptions.

Or, if it was an old implementation, it might return an SDP with media streams and formats
it's willing to support.

> Well, you only do this if you don't know what to offer initially.

OK, however there are other downsides to this:
- How do you handle a 1xx response to the first INVITE ?
- What do you do if it turns out that you don't have any media formats in common, and now
the called party is being alerted and/or has already answered ?

> how to deal with this, ought to send bye to media-less session.

You could do this, but it sounds a little fragile to me (e.g. consider clipping, no media
formats in common, etc.)

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jan 2002 09:28:01 -0500

more comments below.

	Paul

> - How do you handle a 1xx response to the first INVITE ?

Nothing special - just keep waiting.

> the called party is being alerted and/or has already answered ?

Just send a BYE I suppose. This isn't any different than if you send an
INVITE without an offer, and the offer you receive isn't acceptable.

> You could do this, but it sounds a little fragile to me (e.g. consider clipping, no media

Yeah, it might me.

I don't see this as a great solution. But then I wasn't seeing any great
solutions being offered, so I thought I would throw it into the pot.

The problem is bigger than "supporting just one codec at a time", and
the solution should also be. The general problem is that negotiating
media sessions is a lot more complex than just picking one or more
codecs to use. E.g. we may need to choose from among different
transports for the same kind of medium. (This is looking like it may be
a problem with IM.)

	Paul