Subject: RE: [SIP] comments on SDP section/bis-03

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 1 Jun 2001 02:42:14 -0400

> -----Original Message-----
> From: Shan Lu [mailto:[email-masked]]
> Sent: Thursday, May 31, 2001 1:45 PM
> To: [email-masked]
> Subject: [SIP] comments on SDP section/bis-03
> 
> 
> Hi,
> 
> 1. From Section B.3.1 (3rd paragraph):
> 
> "If the stream in the answer is marked as sendrecv, it MUST 
> contain at 
> least one codec the answerer is willing to both send and 
> receive with, 
> from amongst those listed in the offer. The stream MAY indicate 
> additional codes, not listed in the corresponding stream in 
> the offer, 
> that the answerer is willing to receive with."
> 
> My comment is on the last sentence. It seems rather odd that somebody 
> can list a codec as recv only in a media stream that is send 
> and recv.  
> Is this a typo? The last sentence should read as: "The stream 
> ..., that 
> the answerer is willing to send and receive with."

This is something we discussed at IETF 50. It is not a typo. The idea is
that there are codecs (well, one in particular, rfc2833), which one would
like to use in a bidirectional stream, but for which one side really only
ever wants to send it, and the other side is willing to receive it. This is
a common case when a user calls a media server, for example. 

So, the idea is that the caller would offer a stream with PCMU as the codec.
The callee, the media server, would answer with PCMU and also rfc2833. This
means that the callee can send/recv PCMU, as can the caller, but the caller
can also send rfc2833 to the callee.

Far more complex scenarios (in terms of send/recv capabilities for codecs
within a stream) are possible, but this is the limit of the expressiveness
of SDP, and fortunately, covers a really important case. SDP-ng will handle
the more complex ones.

> 
> 2. Immediately after the quoted sentences, I propose that we add the 
> following text:
> 
> "If more than one codec are listed in the answer, the answerer and 
> offerer may choose different codecs to send media, leading to 
> asymmetric 
> codecs being used for send and receive. Furthermore,  even 
> for the same 
> codec, the answerer and offerer may choose different 
> packetization sizes 
> because the indication of packetization time is not mandatory in SDP."

Thats fine.

> 
> I'd rather see that the SIP spec requires only one codec 
> listed in the 
> answer and mandates usage of ptime, for reasons that I 
> elaborated in my 
> earlier postings. If people out there think otherwise, at 
> least we need 
> to point out the consequences. 

And I have pointed out the reasons why multiple codecs in parallel have been
part of the spec, and of the general IP conferencing model, for a long time.
To address the concern that there are phones that cannot support more than
one codec, we have the SDP-based caps exchange spec that is now in last call
in mmusic.

> 
> 3. From Section B.4 (4th paragraph):
> 
> "..., the new SDP MUST have a matching media section for each media 
> section in the previous SDP. ... This matching is necessary 
> in order for 
> the answerer to determine which stream in the new SDP 
> corresponds to a 
> stream in the previous SDP."
> 
> I think the idea of "matching media" is completely bogus as 
> described in 
> bis-03. 

This is not new. Matching of media lines by ordering has been part of SIP
since rfc2543, and it is purely based on a weakness of SDP in that it has no
explicit stream IDs. Its needed, for example, if I send an INVITE with:

m=audio 2400 RTP/AVP 0
m=audio 2402 RTP/ACP 10

and then a re-INVITE with

m=audio 2401 RTP/AVP 0

Since port numbers can change, what has happened here? Have we deleted the
first stream, or the second?

> Compare the 2nd and 3rd examples in Section B.5. Are 
> the first m 
> lines in these two SDPs supposed to match with each other? 

Oops, I screwed up big time. The new stream was added as the top m line,
when it should have been the bottom. I will fix in -04.

> What if the 
> media has changed? Consider the following two SDPs:
> 
> SDP1:
> m=audio 2400 RTP/AVP 0
> m=video 3600 RTP/AVP 31
> 
> SDP2:
> m=video 3600 RTP/AVP 31
> m=audio 2402 RTP/AVP 0
> 
> The only thing that has changed is the audio port from 2400 
> to 2402. But 
> since I am allowed to change media type, I can change the 
> order of the m 
> lines. 

Either the audio port has changed, or the two streams have changed media
types and ports. In this example, one can tell realistically which is the
case. But, without explicit numbering, how would you propose I know which
streams in a re-INVITE correspond to which ones in the previous INVITE?

-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

_______________________________________________
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: Shan Lu <[email-masked]>
Date: Fri, 01 Jun 2001 12:29:41 -0400

> of SDP, and fortunately, covers a really important case. SDP-ng will handle
I remember the discussion at IETF50. But still this looks like a hack. 
You actually list recv only codecs in a stream that is both send and 
recv. Another point is that what is wrong for the media server to list 
the DTMF codec as send and recv. Nobody can force you to use the codec 
to send.  It seems that much of the discussion focuses on the DTMF 
codec. It'll help if some text can be added to explain the rationale and 
application. A year from now, somebody must have the same inquiry.

> streams in a re-INVITE correspond to which ones in the previous INVITE?

My problem is not with matching m lines, but with the possibility of 
change media type. In my opinion, allowing media type change defeats the 
very  purpose of matching media.  In my example, based on matching 
media, one would conclude that the audio stream has been replaced by a 
video stream and the video by an audio stream, which is incorrect. And 
the media services may be disrupted.  Why would somebody change the 
media type for a m line while he can always set the port to 0 in the old 
m line and add a new m line with new media type?

Regards,

Shan Lu

NexTone Communications

---

From: "Bert Culpepper" <[email-masked]>
Date: Fri, 1 Jun 2001 16:29:30 -0400

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> Sent: Friday, June 01, 2001 2:42 AM
> To: 'Shan Lu'; [email-masked]
> Subject: RE: [SIP] comments on SDP section/bis-03
>
>
>
>
>
>

If we consider the discussion at IETF 50 described above (and the text in
B.3.1), wouldn't the events payload type be added to the original audio
stream description?  i.e., "m=audio 47920 RTP/AVP 0 1 110".  But there are
two things going on in this example at this point, changing the port for the
audio and adding events media (at a different port).  So a separate media
description is needed in this case.  It's also explicit that Bob will not
send events, which is not known if a representation based on the discussion,
and the text at the end of paragraph 3 in B.3.1, is used.  Although since
the media type is not present in the offer but is present in the answer, any
media of that type should only flow one way.

I write this because I also believe it's odd to be able to list a codec
that's sendonly/recvonly in a stream that's sendrecv.  I don't see the need
for this practice.  It may help in synchronizing tones with audio but that
can be handled by using the same port in two media stream descriptions.  (Or
is this forbidden somewhere?)  I like the example (when corrected) but don't
like the text at the end of B.3.1 paragraph 3.  The answerer gets no
indication that the offerer will send the additional media type.  However,
separate media descriptions don't help with this aspect with SDP only in
INVITE/200 and 200/ACK.  Since it seems to me that somewhat special cases
are being supported, can it be allowed/recommended to respond with SDP in an
ACK (with previously offered contents unchanged) when the answerer has added
a media stream not present in the offer?

Another solution to the problem of both the offerer and answerer knowing the
other's behavior with rfc2833 is defined in
draft-mahy-sip-signaled-digits-00.txt.  Or is the answer to use the SDP
capabilities exchange stuff?

Regards,
Bert