Subject: RE: Regarding SDP Media level description

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 14 Apr 1999 08:03:11 -0400

I could see a possible case in a Media Gateway control application, where a
global c= clause identifies a circuit and m= is unnecessary because 64 kbs
clear channel service is understood.  I hasten to add that no one has
actually proposed this syntax for Megaco use.

> -----Original Message-----
> From:	Arjun RC [SMTP:[email-masked]]
> Sent:	Wednesday, April 14, 1999 5:59 AM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: Regarding SDP Media level description
> 
> 
	[[TomT]] snip

	...  However, I am yet to see
> an example/ think of a case in which I send a SDP packet without
> specifying m= field.
> 
> Could anyone give inputs on when such a case might happen ?
>  
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 14 Apr 1999 17:28:31 -0400

In fact, it could make sense to have a profile of SDP for MEGACO, that
would specify exactly how many media fields we expect.  Also, we have
run (in MGCP) into the need to specify more attributes than currently
defined in the base SDP specification.  This concerns:

* usage of silence suppression,
* usage of gain control,
* usage of RSVP and/or DIFFSERV (TOS value)
* usage of echo cancellation.

We will need to use the existing extension mechanisms to define these
attributes.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Apr 1999 01:43:44 -0400

> actually proposed this syntax for Megaco use.

Well, the m line doesn't just indicate codecs. It also indicates the
remote port(s). In this case, you would still need it.

The reason I might see for this would be in a gateway from H.323v1 to
SIP. When the SETUP arrives at the gateway, there are no media
information yet. So, the gateway would send an INVITE with SDP with no m
line. When the 200 OK comes, the gateway answers the call on the H.323
side, and does capabilities exchange based on the SDP it received in the
remote side. Once it has determined them, it sends a more complete SDP
with an m line in the ACK message. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: eubpepe <[email-masked]>
Date: Thu, 15 Apr 1999 12:24:52 +0200

> with an m line in the ACK message.
But what exactly should a UAS send as SDP in a 200 OK response to an
INVITE without a media descriptor? Should it send all it's capabilities
for all types of sessions? And even if the H323-SIP gateway sends the
media descriptor in the ACK how will the UAS know what media to expect?
Should it listen for all media types it supports?
Suppose for instance that the UAS sends an SDP with mediadescriptors for
both audio and video, and the H323-SIP gw sends an ACK with only audio.
The UAS cannot be sure the gw won't send video?

Peter Peldan
Ellemtel Utvecklings AB

---

From: Lars Berggren <[email-masked]>
Date: Thu, 15 Apr 1999 15:29:40 +0200

eubpepe wrote:
> for all types of sessions? 

The UAS SHOULD send the SDP for the media types it is willing to support
for the moment ( See rfc2543, appendix B.4 ). Compare also the response
to the OPTIONS without media description ( section 16.8 ).

> And even if the H323-SIP gateway sends the

Well, the final session description to be used will be in the ACK so if
the UAS receives, reads and understands the SDP of the ACK, it will know
that the gw won't send video.

> Ellemtel Utvecklings AB

/Lars.

-- 
Lars Berggren       <[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: eubpepe <[email-masked]>
Date: Thu, 15 Apr 1999 15:45:46 +0200

> that the gw won't send video.
Not if the gw only indicates the media it wants to receive? 
As far as I understand it, it is OK for the gw to send an SDP containg
only audio and still send video-streams since the UAS did indicate that
it supported video?

Peter

---

From: "Kalon R. Kelley" <[email-masked]>
Date: Thu, 15 Apr 1999 14:53:14 -0700

> only audio and still send video-streams since the UAS did indicate that

I don't think this is the case, although I do believe that the spec could be
clearer on this point.

I suspect that once a session description with media lines is specified
during the INVITE process (whether in the caller's INVITE request, or in the
callee's 200 response in the "delayed media stream" case detailed in section
B.4 of the spec), the rules set up in B.1 regarding media stream description
alignment apply to both the subsequent responses and ACKs related to that
INVITE.

If that is the case, then the nth media stream description in the callee's
response must be matched by the nth media stream description in the caller's
ACK, and that description includes all the information necessary for the
callee to ascertain whether or not the caller intends to both send and
receive video, send video only (sendonly attribute), or refuse the video
stream (port zero).

Kalon

Kalon Kelley
Dialogic Santa Barbara Laboratories

---

From: Lars Berggren <[email-masked]>
Date: Fri, 16 Apr 1999 08:38:12 +0200

> Not if the gw only indicates the media it wants to receive?

As I've interpreted the spec, the gw will not only list the media it
wants to receive in the ACK, rather it will list the session description
to be used, including send-only media streams.

> only audio and still send video-streams since the UAS did indicate that

In your example, I guess the messaging can look like this:

gw --> UAS:
----------
INVITE [email-masked] SIP/2.0
...
no media description.

UAS --> gw:
----------
SIP/2.0 200 OK
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000

gw --> UAS:
----------
ACK [email-masked] SIP/2.0
...
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
a=sendonly

In the ACK the UAS understands that the gateway will not receive any
video but it will send it. Hence, when the ACK arrives, the UAS knows
that it should receive but not send video.

This is my understanding, tell me if I've missed something.
/Lars

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Apr 1999 08:45:31 -0400

> In your example, I guess the messaging can look like this:

This is exactly correct.

I agree this is not clear in the spec. The annex on usage of SDP
describes how its done with INVITE followed by 200. If there is no media
at all described in the INVITE, the process  is effectively the same,
but starting with 200, followed by ACK.

Things could get confusing if you send something in the INVITE, get a
"trimmed" version in the 200 OK as expected, and then send something
different altogether in the ACK. Although the spec doesn't explicitly
disallow this, I think its a bad idea. If you want to modify the
description sent in the INVITE, use a re-INVITE instead, not an ACK. SDP
in ACK is really meant for cases (like the H.323v1 gateway), where the
media content is not known until after call acceptance.

-Jonathan R.