Subject: Re: H.248/BICC discussions

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 2 Jun 2000 08:59:57 -0400

As I noted in a previous posting, our Area Directors have agreed that when
it comes to detailed changes to SDP (not involving new principles), Megaco
can go ahead and do the job on its own.  MMUSIC, of course, has to be kept
informed.

While I'm being cooperative with MGCP, that shouldn't get in the way of a
logical evolution of the standard.

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, June 02, 2000 8:47 AM
> To:   [email-masked]
> Subject:      Re: H.248/BICC discussions
>
> Well, I'm having a problem with the idea that a package can extend SDP.
>
> For one thing, that's a non-trivial change to the protocol document, as it
> describes what
> is in a package.  For another, SDP is described in a separate RFC and is
> under
> control of a different group.  For a third, the mechanism wouldn't work
> with SIP (or really
> MGCP).
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:[email-masked]]
>       Sent: Friday, June 02, 2000 8:41 AM
>       To: Mark Watson; [email-masked]'
>       Cc: Sophia Scoggins; [email-masked];
> [email-masked]
>       Subject: RE: H.248/BICC discussions
>
>
>
>       I have forwarded this note to the Megaco list because I believe
> there is a fundamental point to be discussed on the nature of packages.  I
> have not sent it to the SG 11 BICC list because that list is closed to
> non-members.  If someone thinks it is worth forwarding they are free to do
> so.
>
>       I have held the intent in my own mind that it should be possible
> within packages to define properties that are realized within Local and
> Remote.  This would be consistent with Annex C usage and would also imply
> that packages can specify additions to SDP detailed syntax.  If this is
> the consensus view, then it won't be necessary to modify H.248 to
> accommodate BICC.  Instead, Local and Remote would be stripped out at the
> MGC and forwarded via the tunnel, in exact accordance with H.248 design
> intent.
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 2 Jun 2000 10:09:11 -0700

Tom-PT Taylor wrote:

>
>
> As I noted in a previous posting, our Area Directors have agreed that
> when it comes to detailed changes to SDP (not involving new
> principles), Megaco can go ahead and do the job on its own.  MMUSIC,
> of course, has to be kept informed.

Please refresh my mind - which posting was this ?

If all you are saying is, that Megaco, just like anybody else, is free
to "extend" SDP as per the Appendix B procedures in RFC 2327, then I
have no problem with that, provided existing SDP field names and values
do not do the job.

If on the other hand you are saying that Megaco has gotten approval to
violate SDP (in the MG=>MGC direction that is, as the MGC=>MG direction
is not RFC 2327 SDP), then I'm both confused and concerned.

>
>
> While I'm being cooperative with MGCP, that shouldn't get in the way
> of a logical evolution of the standard.

Agreed, however if we start violating RFC 2327, then we will have
interworking problems with several protocols. Megaco should not try and
operate in a vacuum IMHO.

-- Flemming

>      For one thing, that's a non-trivial change to the protocol
>      document, as it describes what
>      is in a package.  For another, SDP is described in a separate RFC
>      and is under
>      control of a different group.  For a third, the mechanism
>      wouldn't work with SIP (or really
>      MGCP).
>
>      Brian
>           I have forwarded this note to the Megaco list because I
>           believe there is a fundamental point to be discussed on the
>           nature of packages.  I have not sent it to the SG 11 BICC
>           list because that list is closed to non-members.  If someone
>           thinks it is worth forwarding they are free to do so.
>
>           I have held the intent in my own mind that it should be
>           possible within packages to define properties that are
>           realized within Local and Remote.  This would be consistent
>           with Annex C usage and would also imply that packages can
>           specify additions to SDP detailed syntax.  If this is the
>           consensus view, then it won't be necessary to modify H.248
>           to accommodate BICC.  Instead, Local and Remote would be
>           stripped out at the MGC and forwarded via the tunnel, in
>           exact accordance with H.248 design intent.
>
>
--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839

---

From: Michael Thomas <[email-masked]>
Date: Fri, 2 Jun 2000 07:59:36 -0700

> logical evolution of the standard.

   It seems that pitting this as MGCP vs MEGACO
   problem is wrongheaded. The real problem with
   H.248 packages "extending" SDP willy-nilly is
   what that does to other SDP aware endpoints.
   If we end up with mutually exclusive varieties
   of SDP where there needs to be some agreement
   on the outer transport layer protocol (MEGACO,
   MGCP, SIP, SAP, etc) then that's a real
   problem. We need to preserve the ability to
   have, say, a H.248 endpoint sources a multicast
   session which is transported to its MGC which sends
   an INVITE to a conference server which sends
   the same SDP announcement out in SAP, etc, etc.
   The SAP receiver shouldn't know or care who
   originated the SDP annoucement.

   If we extend SDP, we should extend SDP in the
   context of MMUSIC to make certain that there
   aren't gratitous collisions. Where the work
   originates from is another matter, but what
   we don't want is "H.248's version of SDP";
   we want "SDP".

           Mike