Subject: RE: SDP on Physical Terminations

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 20 Feb 2001 15:42:50 -0500

Yes, the original purpose of SDP does not include negotiation.
This is now seen as a limitation, which will be addressed.

Megaco did a couple of extensions to address this.
Flemming Andreason of Cisco has a proposal for some other changes
	that make negotiation easier
There is a SDPng effort underway which includes negotiation
	with a non-backwards compatible syntax

So, we use SDP for negotiation.
We've been over the local connection options a lot,
consensus is that it's much better to use SDP because
to accommodate a new option you have to add both an SDP
extension AND local connection options, which is silly.
Look at the ATM package for SDP, completely unnecessary
complicated options totally duplicating the SDP extension.

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Tuesday, February 20, 2001 2:59 PM
> To: Rosen, Brian; [email-masked]'
> Subject: Re: SDP on Physical Terminations
> 
> 
> Troy Cauble wrote:
> > 
> > "Rosen, Brian" wrote:
> > >
> > > Okay, I've been looking at this one for a while, and never said
> > > anything, and now, at the Interop Event, it's a real problem.
> > >
> > > I draw your attention to the example in Appendix A:
> > >    MGC to MG1:
> > >    MEGACO/1 [123.123.123.4]:55555
> > >    Transaction = 9999 {
> > >        Context = - {
> > >            Modify = A4444 {
> > >                Media { Stream = 1 {
> > >                         LocalControl {
> > >                             Mode = SendReceive,
> > >                             tdmc/gain=2,  ; in dB,
> > >                             tdmc/ec=on
> > >                         },
> > >                         Local {
> > >    v=0
> > >    c=IN IP4 $
> > >    m=audio $ RTP/AVP 0
> > >    a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
> > >                            ; detection algorithm
> > >
> > > The problem is the SDP on the Physical Termination.
> > > There are valid reasons why you should allow SDP on 
> physical terminations.
> > > The example shows one, setting the VAD bit.
> > >
> > > The problem is the c and the a lines.  The physical termination is
> > > not an IP flow, and is not using RTP.  Yet, SDP requires 
> an a and m line,
> > > just an a line is not a valid SDP.  Worse, the SDP is 
> using "CHOOSE"
> > > for the addresses, and there is no reply with the answers.
> > >
> > > We need to do something.  All I can think of is to register some
> > > new network/protocol combinations like:
> > > c=X
> > > m=audio 0 X
> > >
> > > Another, less extreme suggestion would be most welcome.
> > >
> > > Brian
> > 
> > I think the problem is more general than the physical case.
> > Using SDP in the LocalDescriptor from the MGC to the MG is
> > more trouble than it's worth.
> > 
> > If you look at the *typical* RTP usage, there's five pieces
> > of information that COULD be extracted:
> >         host
> >         port
> >         mode
> >         payload
> >         packetization
> > 
> > In the context of an RTP LocalDescriptor sent from the MGC
> > to the MG, the first two will always be CHOOSE,  and "mode"
> > has already been moved to the LocalControlDescriptor.
> > (BTW, what happens if the a=<mode> line is present and
> > doesn't match the LCD??)
> > 
> > This leaves us with several lines of data to specify two
> > things, payload and packetization.  It also causes us to
> > contort the SDP specs looking for ways to over/underspecify
> > them.
> > 
> > I think the correct answer (although perhaps not what you
> > consider "less extreme") is to stop using the LocalDescriptor
> > in the MGC -> MG direction and add these elements to the
> > LocalControlDescriptor (like someone did with "mode").
> > BTW, the MGCP approach is similar.
> > 
> > Your Physical example makes it even more clear that SDP
> > is the wrong way to do this.
> > 
> > -troy
> 
> Several quotes from RFC2327 seems to indicates it's for DESCRIBING
> sessions, not NEGOTIATING them.
> 
>    ...a session directory tool
>    is used to advertise multimedia conferences and communicate the
>               ^^^^^^^^^
>    conference addresses and conference tool-specific information
>    necessary for participation.  This document defines a session
>    description protocol for this purpose...
> 
> 
>    SDP is not intended for negotiation of media encodings.
>                            ^^^^^^^^^^^
> 
> 
>    Session directories assist the advertisement of conference sessions
>                                   ^^^^^^^^^^^^^
>    and communicate the relevant conference setup information to
>    prospective participants.  SDP is designed to convey such 
> information
>    to recipients.  SDP is purely a format for session description...
> 
> 
>    However, it is not intended to
>    support negotiation of session content or media encodings - this is
>            ^^^^^^^^^^^
>    viewed as outside the scope of session description.
> 
> -troy
>

---

From: Troy Cauble <[email-masked]>
Date: Wed, 21 Feb 2001 10:32:12 -0500

> This is now seen as a limitation, which will be addressed.

Sometimes limitations are good.  SDP does what it does very well.

> So, we use SDP for negotiation.

Sounds like a lot of pounding on a square peg.

> extension AND local connection options, which is silly.

Sillier than four lines of non applicable (even misleading)
information to set one bit?

> > > > new network/protocol combinations like:

You should 'X out' the 'PCMU' portion too.  It doesn't really
apply to the physical connection.

By the time we're done with mangling SDP, there won't really
be any reason to have started with it, other than leveraging
off it's popularity and *claiming* re-use.

So instead of requiring SDP and LCD extensions, we're going to
create another overly complicated Uber protocol with enough 
flexibility allow all possible future negotiations and descriptions.
And just to make it ugly we'll start with a protocol that is
specifically not for negotiation.
But I don't suppose it was phrased this way when consensus was reached :(

-troy