Subject: RE: SDP on Physical Terminations

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 21 Feb 2001 11:49:37 -0500

Well you are mixing a few issues into one.

First of all, negotiation occurs because two ends
need to negotiate communication.  The way we express
the RESULTS of the negotiation is always SDP.  It is
in MGCP also.  The issue is how you express the
range of possible values.  SDP doesn't have the syntax
for that, and the three examples I gave address that issue.
You can't use a set of properties in LocalControl to fix this,
because the negotiation has to be sent to one end, or the
other (or both) for the negotiation to take place.
That is why we do in fact need a way to express capability
(which means options).  We also need a way to express
capacity (how many, in addition to what kinds).

This has nothing to do with LocalControl.  You don't
negotiate LocalControl. 

Now, for an analog line, there are, admittedly, only
a few things that are interesting to modify, but ALL of
them already exist as SDP expressible.  For example,
if I want to connect two physical terminations together
like a hairpin connection, and I want to have different
codecs on each of them, I need to express that.  Rather
than duplicating options already in SDP, we simply reuse
them.  We need a reasonable, non offensive way to have
a legal SDP, which means c and m lines, but I think it is
in fact better to do that, then invent properties of
LocalControl that duplicate the existing SDP.

Finally, although we can fix errors, and clear inconsistencies
in the Implementor's Guide, the text of H.248 and RFC3015 is 
frozen, and I am loath to change an entire mechanism now.  
Try again in V2.

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 10:32 AM
> To: Rosen, Brian
> Cc: [email-masked]'
> Subject: Re: SDP on Physical Terminations
> 
> 
> "Rosen, Brian" wrote:
> > 
> > Yes, the original purpose of SDP does not include negotiation.
> > This is now seen as a limitation, which will be addressed.
> 
> Sometimes limitations are good.  SDP does what it does very well.
> 
> > 
> > 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.
> 
> Sounds like a lot of pounding on a square peg.
> 
> 
> > 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.
> 
> Sillier than four lines of non applicable (even misleading)
> information to set one bit?
> 
> 
> > > > >                         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
> 
> 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
>

---

From: Troy Cauble <[email-masked]>
Date: Wed, 21 Feb 2001 15:50:22 -0500

> for that, and the three examples I gave address that issue.

No problem with this.

> This has nothing to do with LocalControl.  You don't

I didn't follow your reason why the MGC->MG part of the
negotiation can't be in LCD while the MG->MGC replies
are in the LD.

I don't have a clear understanding of what the purpose
of the LCD is vs. that of the LD.  I just know that SDP 
goes in one and not the other.  Can you clarify this?
Also, why is there a Mode option in the LCD instead of 
using the one in SDP?

> LocalControl that duplicate the existing SDP.

They might be SDP expressible, but we still have to change 
SDP to
1) 'X out' the parts we don't want, and
2) under/over-specify the parts we do want.

This is true for the negotiation of RTP streams too.

> frozen, and I am loath to change an entire mechanism now.

Yeah, I knew the cause was lost when I started.  Thanks for
humoring me with a discussion.

In terms of H.248/Megaco being frozen though, it's only frozen 
because somebody said "We'll take care of all those pesky little 
details later by extending SDP."  So H.248/Megaco is frozen, but 
it's unusable until somebody hacks SDP.  It sounds like these 
details are biting you now at interop.

IMO, if someone had published all those potential changes to
SDP before H.248 was frozen, people could have seen how ugly
they would make the SDP and opted for a different mechanism.
Water under the bridge now.

-troy