Subject: RE: SDP on Physical Terminations

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 25 Feb 2001 06:28:46 -0500

This seems as good a place as any for me to jump in to this thread.

The key historical fact behind our use of SDP is that it is used by SIP.
When Christian Huitema and his colleagues created SGCP, they included SDP
for the packet side because it would fit well with SIP.

Our problem is that we have undertaken to control non-IP bearers (think
circuit to ATM as an example), but retained the use of SDP.  In retrospect
I'm thinking we should have borken away, but there it is, and its partly my
fault for ruling against the protocol Brian, John Segers, and Gur Kimchi put
together.  (And others too, but I'm 13 hours out of my home time zone and
feeling it to the point where I can't remember.)

You can't simply say "Put all the non-IP stuff in LC", because then you end
up with the base protocol syntax varying with the bearer type.  The counter
argument is that you end up hacking SDP instead, but I assure you that the
TDM hack I am preparing respects RFC 2327 to the letter.

Negotiation is another matter.  A year ago I suddenly realized that I hadn't
a clue how negotiation worked in our protocol.  The ensuing discussion
produced our present mechanisms, which are probably a bit too elaborate for
real-life requirements.  It would be lovely if we could follow IETF process
and purify things going into Draft Standard stage, but I can't see how that
could be done safely without creating a second standard beyond H.248.

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 3:50 PM
> To: Rosen, Brian
> Cc: [email-masked]'
> Subject: Re: SDP on Physical Terminations
> 
> 
> "Rosen, Brian" wrote:
> > 
> > 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.
> 
> No problem with this.
> 
> > 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.
> 
> 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?
> 
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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
>

---

From: "Beny T" <[email-masked]>
Date: Mon, 26 Feb 2001 16:30:58 +0700

RE: SDP on Physical TerminationsDear,

As an engineer in circuit switch network, data or packet switch network is a
new subject for me.
But it has become my mayor job since this year. I interest to take some
training or seminar according to data or packet network.
If you have an information about the free training or seminar about that,
pls contact me.
Your information is very usefull for me, thanks alot.

Regards

Beny T
CCS7 network engineer
R&D Division TELKOM Indonesia