Subject: Washington Issue 11 - ATM Parameters in SDP

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 1999 14:44:12 -0500

A number of issues were raised in the Washington meeting that
were "send to the list".  This is one of these issues, with the
problem and my suggested fix.

Problem
Annex C has syntax to create ATM bearers.  SDP must be
extended to allow ATM bearers to be created with text encoding

Proposed Solution
In an email to the list from the MSF Forum with the original
Annex C parameters for ATM, it was suggested that the c=
line specify the AAL type, address mechanism and address,
the m= line contain the VPI/VCI, and then c= lines contain
the remaining parameters with names the same as the corresponding
ones in Annex C.

IANA registrations for these parameters would be required
if this proposal was accepted.

Brian

---

From: Michael Brown <[email-masked]>
Date: Tue, 16 Nov 1999 17:57:14 -0500

I was confused when I read over the proposal described because something
didn't seem quite right and so I went back to look at the the original
posting of the MSF forum email. For those who did not access the initial
MSF email, the proposal from that document is shown following Brian's
message. I found two differences.

First, the description of the c= line has changed from the original
proposal. Initially, it was to be the network type, address type and the
connection address. The current proposal shows the AAL type, address
mechanism (same as address type?) and the connection address.

The second thing I found is that the reference to using the c= line for
"remaining parameters..." in the current proposal previously referred to
an a= line being used for these things in the MSF forum email. The c=
line would be used only for the connection info. I don't think this
change was intentional.

One other point is the use of the m= line for the VPI/VCI (which is the
same in both proposals). I'm not sure why this would be an m= line
rather than a c= line or perhaps an a= line. Actually another question
is whether or not it makes sense to send the VPI/VCI to the MGC at all.
My understanding is that the VPI/VCI has no end to end network path
significance and would not be used outside the scope of the bearer
control function of the MG which chooses that VPI/VCI. The only possible
reason I can think of for providing the VPI/VCI in the SDP would be that
the MGC is maintaining some VPI/VCI map and is allocating or keeping
track of  the resources on behalf of the MG. So, the first question is
whether the VPI/VCI needs to be included in the SDP at all. If it is
believed that it is needed, then the suggested modification to the
proposal would be that the VPI/VCI would be specified in the SDP using a
c= line or an a= line rather than the m= line.

Michael Brown

> if this proposal was accepted.

4. SDP Syntax

The "c=" field contains connection data.

The first sub-field is the network type, which is a text string giving
the type of network. "ATM" is defined to have the meaning "ATM network".

The second sub-field is the address type. Three values are defined:
"E.164", "AESA" and "VC". In the first two cases, an explicit address is

specified, and a new VC is to be created. If VC is specified, an address
is not
specified in the c= line, and an existing VC is used.

The third sub-field is the connection address.

m= A session description may contain a number of media descriptions.

Each media description starts with an "m=" field, and is terminated by
either the next "m=" field or by the end of the session description. A
media field also has several sub-fields:

The first sub-field is the media type. Currently defined media are
"audio", "video", "application", "data" and "control", though this list
may be
extended as new communication modalities emerge (e.g., telepresense).
The difference between "application" and "data" is that the former is a
media flow such as whiteboard information, and the latter is bulk-data
transfer such as multicasting of program executables which will not
typically be
displayed to the user. "control" is used to specify an additional
conference control channel for the session.

The second sub-field is the VPI/VCI to be used. Either component can be
specified as "choose" (?), which is interpreted to mean the MG shall
select a value, which shall be returned to the MGC.

The third sub-field is optional, and is the Transport field. Values
would be similar to existing SDP practice. Specifically, RTP is used to
create an
RTP connection over an ATM VC, as in H.323 Annex C.

For all other ATM parameters could be specified with a= parameters. The
"Short Tag" field from the prior tables forms the parameter name. For
example:

a=AALtype:2 Specifies an AAL2 connection. An example follows:

        c=ATM AESA 122cf.2234.ded01

        m=?/?

        a=AALtype:1

        a=PCR:171