Subject: Re: Washington Issue 11 - ATM Parameters in SDP

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Nov 1999 18:18:18 -0500

I actually did not intend to change the MSF proposal.  Any
changes were mistakes I made.

It is worth discussing the c= and m= lines.

First let's start with VPI/VCI.

The requirements state "11.1.3.1.e.   Refer to an existing VCC
as the physical interface + Virtual Path Identifier (VPI) +
Virtual Circuit Identifier (VCI)."

This is so you can establish a (say) PVC and specify its use,
or use a proxy signalled SVC, or create an AAL2 SVC
and subsequently use it (we could invent some other kind of
identifier for the latter, but since we need the former,
why bother).

BTW when we get to multiplexed RTP, these issues apply the same
way.  If we specify an MPLS Label Switched Path, they also
apply.  The names will change to protect the innocent.

So, depending on what the MGC desires we have to:
    a) Specify that a new VC be created - this means
          specifying an address by AESA or E.164
          We may need the MG to return the VPI/VCI
    b) Specify that an existing VC be used - this means we
          need to specify the VPI/VCI
    c) Specify that the MG decide what to do (MG cache
          of bearers).  Presumably we use the same
          address as a) above.

I worry a little bit about doing anything with SDP that
means a change to the RFC.  I'm going to do more research
before I offer a revised proposal for c= and, if necessary, m=.

The a= lines would be used for additional parameters, using the
names and values from Annex C.

Brian

> -----Original Message-----
> From: Michael Brown [mailto:[email-masked]]
> Sent: Tuesday, November 16, 1999 5:57 PM
> To: [email-masked]
> Subject: Re: Washington Issue 11 - ATM Parameters in SDP
>
>
> 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
>
> Brian Rosen wrote:
>
> > 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
>
> 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
>