Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK?

From: "Victor A Paulsamy" <[email-masked]>
Date: Fri, 2 Feb 2001 09:01:56 -0500

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Gonzalo Camarillo
Sent: Saturday, March 31, 2001 10:18 PM
To: sip
Subject: [SIP] SDP: Sub-set or not in the 200 OK?

>My proposal is to go for solution number 2. This gives a symmetrical
>negotiation. Besides, it covers more cases than solution number 1). It
>can happen that for a particular codec, the callee can send AND receive
>it but the caller can just send it. Therefore, the caller does not
>include it in the INVITE. However, if the callee lists it in the 200 OK,
>the caller will be able to send it.

This holds good *only* for sending DTMF tones. Otherwise, this would mean
two media streams encoded *differently* (one in each direction) in a
session. Is my understanding correct?

Warm regards,

--victor

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Victor A Paulsamy" <[email-masked]>
Date: Tue, 3 Apr 2001 14:37:53 -0400

Hi,

Gonzalo Camarillo wrote:

>In the last IETF the conclusion was:
>For sendrecv flows (uni-directional flows are easy), the caller puts in
>the INVITe the codecs that he can both send AND receive.

>The open issue is what the callee returns:
>1) a sub-set of the codecs listed in the INVITE that he can send AND
>receive.
>2) all the codecs that he can send AND receive.

In first place, it's not clear to me why a callee should put down *entire*
list of codecs that can send and receive while responding to an INVITE? Just
pick the first (*one*) codec if it could be supported, second if the first
cannot be supported and so on from the (entire) list given by the caller
(and return it in a 200 OK). In this case it would signal end of media
format (codec) negotiation.

Secondly, codecs are to be used for both transmission and reception. Why
should a codec be designated as send only or receive only?

Warm regards,

--victor

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 03 Apr 2001 22:01:07 +0300

Hello,

> format (codec) negotiation.

It is called change of codec on-the-fly, and you have the RTP payload
for that.

I insist once more (and it is the 3rd time that I do it in this thread)
that we do not want to mix the issue we are discussing with the issue of
picking up one single codec.

> should a codec be designated as send only or receive only?

To do this you have to use fid. With plain SDP you cannot mark a codec
as reconly in a sendrecv stream.

Gonzalo

-- 
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: Shan Lu <[email-masked]>
Date: Tue, 03 Apr 2001 16:16:33 -0400

Hi,

Before we come up with any solution, let's first understand what the 
problems are and what we want out of SDP.

Problems:

When more than more audio codecs are listed in "m=" line, SDP lacks 
mechanism to indicate:
1. sendrecv, sendonly, or recvonly for each codec;
2. packetization size supported for each codec ;
3. simultaneous capabilities. (e.g., a UA can support audio codecs A, B, 
and C, but when video codec X is used, can only support audio codec A.)

Desirable functions of SDP:

1. To indicate to the other side the full capabilities of a UA
2. To indicate to the other side the media types (codec, pack. size, 
uni. or bi-directional) that will be used for a particular session in an 
unequivocal way.

As an implementor, I can testify firsthand that I can not appreciate the 
last point enough. Here is why: In the real world, most DSP based codec 
implementations can ONLY support symmetric operation. If tx uses codec 
A, rx must also use codec A. So if the first SDP (INVITE or 200 OK)  
lists codecs A, B and C, and second SDP (200 OK or ACK) responds with 
codecs A and B, one UA may start use codec A and the other may pick 
codec B, which results in either dead silence or garbled speech. We have 
seen this happen at the bake-offs.

And packetization size is another issue. Take G.729 for example. The 
base frame size is 10ms. But due to resource restrictions, many 
implementations can only support a fixed, integer multiple of the base 
frame, say 20ms or 30 ms. On some implementations, packetization size is 
either a runtime or configuration parameter. In any case, a 20 ms won't 
talk to 30 ms G.729. We heard quite a few distorted conversations 
because of codec size mismatch at SIP bake-offs and at H323 
Interoperability Events.

Hence, I'd like to propose the following:

1. Assume all audio codecs (not including DTMF) are send and recv, and 
require symmetric operation;
2. Originating SDP lists packetization size for each codec unless 
default value is used;
3. If supported, origination SDP lists explicitly whether DTMF is send 
or recv, with sendrecv being default;
4. Responding SDP lists one and ONLY one codec for each media (if, of 
course, there exists overlap) and, when applicable, includes 
packetization size and send/recv attribute;
5. The side that originates SDP uses OPTIONS to query the other side's 
capability after call setup, if necessary.

Example: UA1 supports codecs A (20ms), B (30ms), and C (20ms), and can 
transmit and recv DTMF; UA2 supports codecs A(10 ms), B (30ms), and D( 
20ms) and can transmit DTMF (but not recv). Here's the SDP exchange:

UA1->UA2 (INVITE)

m=audio 40000 RTP/AVP 100 101 102
a=rtpmap: 100 A/8000
a=ptime: 20
a=rtpmap:101 B/8000
a=ptime: 30
a=rtpmap:102 C/8000
a=ptime: 20
m=audio 40000 RTP/AVP 103
a=fmtp:103 0-15
a=sendrecv

UA2->UA1 (200 OK)
m=audio 30000 RTP/AVP 101
a=rtpmap:101 B/8000
a=ptime: 30
m=audio 30000 RTP/AVP 103
a=fmtp:103 0-15
a=sendonly

Note that there are two "m=" lines in each SDP because the DTMF and 
codec are really simultaneous capabilities. The usage of "a=ptime" is a 
little bit stretch here at codec level and may cause problem for 
existing implementations. But I haven't seen it used very much.

Regards,

Shan Lu

NexTone Communications

Gonzalo Camarillo wrote:

> Hello,
> 
> There have been already several mails showing certain confusion about
> SDP usage in SIP.
> Note that caller and callee have reversed roles if the SDP from the
> client to the server is sent in the ACK instead of in the INVITE.
> 
> I would like to ask folks not to mix this open issue with another
> similar issue: I have a DSP that cannot change codecs on-the-fly, and I
> want to pick up just one codec. Let us discuss this issue at other time.
> 
> Opinions?

---

From: "Victor A Paulsamy" <[email-masked]>
Date: Wed, 4 Apr 2001 10:37:35 -0400

Hi,

>It is called change of codec on-the-fly, and you have the RTP payload

Where can I find this and available literature?

Thanks in advance.

Warm regards,

--victor

---

From: aravindan shanmugam <[email-masked]>
Date: Wed, 4 Apr 2001 07:49:05 -0700 (PDT)

Hi,

Handling different packet size is not a difficult
problem as long as the packet size is an integer
multiple of codec frame size. Let us not add more
variables to the problem.

Making DTMF, CN etc. as separate streams will create
more issues with many existing systems. 

Aravindan
> > the caller will be able to send it.

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

---

From: Shan Lu <[email-masked]>
Date: Wed, 04 Apr 2001 12:27:08 -0400

> variables to the problem.

Can you tell me how if neither side indicates the packet size ?

Shan Lu

>>> There have been already several mails showing
>> 
>> certain confusion about
>> 
>>> SDP usage in SIP.
>>> For sendrecv flows (uni-directional flows are
>> 
>> easy), the caller puts in
>> 
>>> the INVITe the codecs that he can both send AND
>> 
>> receive.
>> 
>>> 1) a sub-set of the codecs listed in the INVITE
>> 
>> that he can send AND
>> 
>>> receive.
>>> Note that caller and callee have reversed roles if
>> 
>> the SDP from the
>> 
>>> client to the server is sent in the ACK instead of
>> 
>> in the INVITE.
>> 
>>> I would like to ask folks not to mix this open
>> 
>> issue with another
>> 
>>> similar issue: I have a DSP that cannot change
>> 
>> codecs on-the-fly, and I
>> 
>>> want to pick up just one codec. Let us discuss
>> 
>> this issue at other time.
>> 
>>> My proposal is to go for solution number 2. This
>> 
>> gives a symmetrical
>> 
>>> negotiation. Besides, it covers more cases than
>> 
>> solution number 1). It
>> 
>>> can happen that for a particular codec, the callee
>> 
>> can send AND receive
>> 
>>> it but the caller can just send it. Therefore, the
>> 
>> caller does not
>> 
>>> include it in the INVITE. However, if the callee
>> 
>> lists it in the 200 OK,
>>

---

From: aravindan shanmugam <[email-masked]>
Date: Wed, 4 Apr 2001 09:42:02 -0700 (PDT)

> Can you tell me how if neither side indicates the

You know the payload size of RTP packet when you
receive a packet after protocol processing and you
know the codec frame size from the codec type. Thus,
you can estimate the number of codec frames in the
packet. For more details refer to
draft-ietf-avt-profile document.

Aravindan
> >> When more than more audio codecs are listed in
> "m="
> >> line, SDP lacks 
> >> mechanism to indicate:
> >> last point enough. Here is why: In the real
> world,
> >> most DSP based codec 
> >> lists codecs A, B and C, and second SDP (200 OK
> or
> >> ACK) responds with 
> >> codecs A and B, one UA may start use codec A and
> the
> >> other may pick 
> >> And packetization size is another issue. Take
> G.729
> >> for example. The 
> >> frame, say 20ms or 30 ms. On some
> implementations,
> >> packetization size is 
> >> either a runtime or configuration parameter. In
> any
> >> case, a 20 ms won't 
> >> talk to 30 ms G.729. We heard quite a few
> distorted
> >> conversations 
> >> because of codec size mismatch at SIP bake-offs
> and
> >> at H323 
> >> Interoperability Events.
> >> 
> >> 1. Assume all audio codecs (not including DTMF)
> are
> >> send and recv, and 
> >> 2. Originating SDP lists packetization size for
> each
> >> codec unless 
> >> default value is used;
> >> 4. Responding SDP lists one and ONLY one codec
> for
> >> each media (if, of 
> >> course, there exists overlap) and, when
> applicable,
> >> includes 
> >> Example: UA1 supports codecs A (20ms), B (30ms),
> and
> >> C (20ms), and can 
> >> 20ms) and can transmit DTMF (but not recv).
> Here's
> >> the SDP exchange:
> >> 
> >> UA1->UA2 (INVITE)
> >> 
> >> little bit stretch here at codec level and may
> cause
> >> problem for 
> >> existing implementations. But I haven't seen it
> used
> >> very much.
> >> 
> >> Regards,
> >> 
> >> Shan Lu
> >> 
> >> NexTone Communications
> >> 
> >> Gonzalo Camarillo wrote:
> >> 
> >>> Hello,
> >>> 
> >> This list is for continuing development of the
> SIP
> >> protocol.
> >> The sip-implementor's list is the place to
> discuss
> >> implementation,

---

From: Shan Lu <[email-masked]>
Date: Wed, 04 Apr 2001 13:57:03 -0400

> draft-ietf-avt-profile document.

I see. You want to leave the burden to RTP PT. Let's consider the 
following two scenarios:

1. UA1 and UA2 both can support 20 ms and 30 ms of Codec A and both can 
switch packetization size "on-the-fly". But the default configuration is 
20 ms for UA1 and 30 ms for UA2. Now are you saying that UA1 should 
refrain from transmitting RTP packets till packets arrive from UA2 at 
which time UA1 can figure out the packet size the other side wants to 
use and switch to that size? Of course, both UAs may start transmit at 
the same time. But for sure the first moments of speech won't be as 
clear as a user would like to hear due to packetization size mismatch. 
And how do you make sure that the two UAs do not switch simultaneously 
which will again lead to packet size mismatch? Let's  not forget that 
even "on-the-fly" switch takes time and a user can definitely tell it.

2. UA1 can ONLY support 20ms codec A and UA2 can ONLY support 30ms codec 
A. UA1 calls UA2. UA2 rings and user picks up the phone. Then what? Dead 
silence, garbled speech, or busy/reorder tone, or LED display "packet 
size mismatch"?  What you want in this case is for UA2 to send 415 
"unsupported media type" response because the two UAs can never have a 
media connection. This of course assumes UAs have a way to list 
packetization size.

Hope this is enough to convince you. A protocol has to be designed based 
on reality. And the reality is many codec implementations use DSPs and 
DSPs have limitations. If we have super-fast DSPs with super-large 
on-chip RAM, packetization size is not a problem  Nor is codec type.

Regards,

Shan Lu

> 
>>> 
>>> Making DTMF, CN etc. as separate streams will
>> 
>> create
>> 
>>>> 1. sendrecv, sendonly, or recvonly for each
>>> 
>> codec;
>> 
>>>>> Note that caller and callee have reversed roles
>>>> 
>> if
>> 
>>>> the SDP from the
>>>> 
>>>>> client to the server is sent in the ACK instead
>>>> 
>> of
>> 
>>>> in the INVITE.
>>>> 
>>>>> can happen that for a particular codec, the
>>>> 
>> callee
>> 
>>>> can send AND receive
>>>> 
>>>>> it but the caller can just send it. Therefore,
>>>> 
>> the
>> 
>>>> caller does not
>>>> 
>>>> and to receive advice on understanding existing
>>> 
>> sip.
>>

---

From: aravindan shanmugam <[email-masked]>
Date: Wed, 4 Apr 2001 11:48:55 -0700 (PDT)

No one said that the packet size has to be same in
both direction. I can send 20ms packet and receive
30ms packet, it is simple. Why would anyone want to
configure it?. If you still feel it is essential to
have packet size I leave it to you and others.

Aravindan
--- Shan Lu <[email-masked]> wrote:
> >>>> Before we come up with any solution, let's
> first
> >>>> understand what the 
> >>>> 2. To indicate to the other side the media
> types
> >>>> (codec, pack. size, 
> >>>> As an implementor, I can testify firsthand that
> I
> >>>> can not appreciate the 
> >>>> A, rx must also use codec A. So if the first
> SDP
> >>>> (INVITE or 200 OK)  
> >>>> codec B, which results in either dead silence
> or
> >>>> garbled speech. We have 
> >>>> implementations can only support a fixed,
> integer
> >>>> multiple of the base 
> >>>> 3. If supported, origination SDP lists
> explicitly
> >>>> whether DTMF is send 
> >>>> transmit and recv DTMF; UA2 supports codecs
> A(10
> >>>> ms), B (30ms), and D(

---

From: Colin Perkins <[email-masked]>
Date: Wed, 04 Apr 2001 14:36:47 -0400

>on-chip RAM, packetization size is not a problem  Nor is codec type.

SDP has an a=ptime attribute, if you really need to signal this. Although,
as both SDP and the RTP A/V profile note, "it should not be necessary to
know ptime to decode RTP audio, and it is intended as a recommendation for
the encoding/packetisation of audio."

Colin

---

From: Shan Lu <[email-masked]>
Date: Wed, 04 Apr 2001 15:18:11 -0400

> the encoding/packetisation of audio."

a=ptime is exactly what I proposed to use. See my early posting:

http://lists.bell-labs.com/pipermail/sip/2001q2/006521.html
I agree with you that it is not necessary to know ptime to decode RTP 
stream. The problem is not decdoing. Rather it is how to make sure the 
two sides use the same size.

Regards,

Shan Lu

---

From: Shan Lu <[email-masked]>
Date: Wed, 04 Apr 2001 15:30:55 -0400

> have packet size I leave it to you and others.

It is possible to have different sizes for enc and dec. But as a 
practical matter, it is a lot harder for systems to do it that way, 
especially for those based on DSPs. If you want to assume that UAs 
support different sizes for encoding and decoding, one can certainly 
assume that UAs support asymmetric codecs for encoding and decoding. 
Then this entire discussion on SDP becomes unnecessary. But does it 
solve our problem? Also, what about my case #2?

Regards,

Shan Lu

>>>>> Handling different packet size is not a
>>>> 
>> difficult
>> 
>>>>> multiple of codec frame size. Let us not add
>>>> 
>> more
>> 
>>> know the codec frame size from the codec type.
>> 
>> Thus,
>>