Subject: Re: H.248/BICC discussions

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 2 Jun 2000 07:40:43 -0500

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.

> -----Original Message-----
> From: Watson, Mark [MAIFP:EP11-M:EXCH]
> Sent: Friday, June 02, 2000 8:03 AM
> To:   [email-masked]'; [email-masked]'
> Cc:   Scoggins, Sophia [NC1:3T18:EXCH]; [email-masked]
> Subject:      RE: H.248/BICC discussions
>
> Christian, All,
>
> Before we get confused, let's remember that the Tunnelling mechanism, and
> the question of what is carried inside the Tunnell, are separate and
> independent issues.
>
> What I understand has been agreed is that we will work on a general
> purpose tunnelling mechanism in BICC for the purpose of transporting MG to
> MG information for Bearer Control.
>
> As Christian says, the tunnelling mechanism will not be specific to any
> bearer technology and could in principle be used in any cases where there
> is no need for any intermediate BCF-Rs in the bearer network to see the
> Bearer Control information.
>
> Personally, I think that there are some cases where Bearer Control
> Tunnelling *could* in principle be used, but where we should decide that
> it is not applicable. Specifically, I think that for those technologies
> supported by CS1, we should think carefully before introducing alternative
> ways of supporting the same thing. As an example, Bearer Control
> Tunnelling could be used to transport ATM UNI signalling between two GSNs,
> because there is no ATM switching between GSNs. However, I don't see any
> value in specifying this application of Bearer Control Tunnelling. This is
> at present my opinion. The meeting has not yet addressed this point in
> detail.
>
> Sophia's comments below referred also to the other Nortel contribution to
> Melbourne which discussed the way that H.248 presently transports the
> pieces of information which need to be exchanged between MGs for IP Bearer
> Control. The proposal was that in considering what may be placed inside
> the Tunnel for IP Bearer Control, we should consider the encodings already
> supported in H.248 such as SDP and Native Tags.
>
> If we followed this approach, then the BICC version of H.248 would carry
> the SDP information inside the Bearer Control Tunnelling package, rather
> than inside the present termination properties used for SDP. This would be
> a minor change, but with the important effect of clearly separating out
> the MG-MG information from the MG-MGC information in the protocol.
>
> What remain an open issues, are (i) whether any other information or
> wrapper needs to be carried with the SDP inside the tunnel, and (ii)where
> we specify the procedures relating to sending and receipt of tunnelled SDP
> information. These should probably be covered in the IP Bearer Control
> document produced by SG11.
>
> Comments ?
>
> Regards,
>
> Mark Watson
> Nortel Networks
>
>
>
> -----Original Message-----
> From: Scoggins, Sophia [NC1:3T18:EXCH]
> Sent: 01 June 2000 12:28
> To: [email-masked]; Watson, Mark [MAIFP:EP11-M:EXCH]
> Subject: Re: Multiple MGC scenarios
>
>
> Christian,
>
>
> Nortel has separate contributions regarding this topic. One addressed
> the bearer information tunneling method (it was Mark's contribution).
> The other proposed using the H.248 Native Tags or SDP as the encoding
> mechanism (is was Mark and my contribution). Mark presented both at the
> Melbourne meeting. I didn't go.
>
>
> Mark,
>
> Would you please answer Christian's question? This mailing list is for
> H.248 Megaco Interop testing coming in Aug.
>
>
> Regards, Sophia
>
> Christian Groves wrote:
> >
> > G'Day Sophia,
> >
> > Is this decision in a meeting report somewhere?
> >
> > I was at the Melbourne meeting where this was discussed and it was
> > decided that the tunnel was a global mechanism to be used for IP and ATM
>
> > bearer establishment signalling. The tunnel accepted did not mention SDP
>
> > or H.248 Native tags, it was a simply a bucket to carry bearer
> > establishment signalling which otherwise would been signalled directly
> > between 2 peer BCFs (MGs).
> >
> > Regards, Christian
> >
> > Sophia Scoggins wrote:
> > >
> > > Christian,
> > >
> > > You are right. There is one Nortel Network submission particularly
> > > addressing tunneling H.248 parameters in SDP or H.248 native tag
> > > formats. This is, however, for IP parameters only (in the BICC/ISUP+
> CS2
> > > or capability Set 2). All the ATM parameters have been defined in BICC
>
> > > parameter field. In order to backward compatible, ITU-T SG11 has
> decided
> > > by majority not to change it or provide extension to carry additional
> > > ATM related information in the tunneling messages.
> > >
> > > Regards, Sophia
> > >
> > > Christian Groves wrote:
> > > >
> > > > G'Day Sophia,
> > > >
> > > > Just to clarify what SG11 accepted. It was the idea of tunnelling
> bearer
> > > > control messages across BICC and H.248, not to add H.248 parameters
> in
> > > > BICC messages.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Sophia Scoggins wrote:
> > > > >
> > > > > My understanding is that this interop testing event will have a
> single
> > > > > MGC to a MG or possibly extend to a single MGC to two MGs. There
> won't
> > > > > be multiple MGCs. The communications between MGC-MGC is outside of
> the
> > > > > Megaco protocols, and it is not included in this initial H.248
> interop
> > > > > testing. Gatekeepers are for IP phones. If a MG doesn't handle IP
> > > > > phones, gatekeepers are not needed.
> > > > >
> > > > > There are parameters from MG-MGC that are not included in the
> current
> > > > > MGC-MGC communication protocols, such as ISUP+ and SIP+. In my
> recent
> > > > > contribution to ITU-T, I have added extension to ISUP+ (now known
> as
> > > > > BICC) to pass H.248 native tags or SDP parameters. This
> contribution is
> > > > > accepted as an work item by the SG11. To see it to be included in
> the
> > > > > standard and implementation, it will take time. So, interop from
> H.248
> > > > > end-to-end through MGCs will take time to be reality.
> > > > >
> > > > > Regards, Sophia
> > > > >
> > > > > [email-masked] wrote:
> > > > > >
> > > > > > In section 1.1.1 it is mentioned "The digit shall be
> provisionable.  In single
> > > > > > MGC test environments, the digit will normally be zero.  In
> multiple MGC
> > > > > > scenarios, the gateways are numbered from zero."
> > > > > >
> > > > > > Between multiple MGCs what kind of MGC-MGC interface will be
> used.
> > > > > > Is some MGC-MGC communication interface standaridised ???
> > > > > >
> > > > > > Is there a plan to include getekeepers in multiple MGC scenarios
> for the simple
> > > > > > tests included in the test document ???
> > > > > >
> > > > > > Sachin Mittal
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Jun 2000 08:46:54 -0400

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

        -----Original Message-----
From:   Watson, Mark [MAIFP:EP11-M:EXCH]
Sent:   Friday, June 02, 2000 8:03 AM
To:     [email-masked]'; [email-masked]'
Cc:     Scoggins, Sophia [NC1:3T18:EXCH]; [email-masked]
Subject:        RE: H.248/BICC discussions

        Christian, All,

        Before we get confused, let's remember that the Tunnelling
mechanism, and the question of what is carried inside the Tunnell, are
separate and independent issues.

        As Christian says, the tunnelling mechanism will not be specific to
any bearer technology and could in principle be used in any cases where
there is no need for any intermediate BCF-Rs in the bearer network to see
the Bearer Control information.

        Personally, I think that there are some cases where Bearer Control
Tunnelling *could* in principle be used, but where we should decide that it
is not applicable. Specifically, I think that for those technologies
supported by CS1, we should think carefully before introducing alternative
ways of supporting the same thing. As an example, Bearer Control Tunnelling
could be used to transport ATM UNI signalling between two GSNs, because
there is no ATM switching between GSNs. However, I don't see any value in
specifying this application of Bearer Control Tunnelling. This is at present
my opinion. The meeting has not yet addressed this point in detail.

        Sophia's comments below referred also to the other Nortel
contribution to Melbourne which discussed the way that H.248 presently
transports the pieces of information which need to be exchanged between MGs
for IP Bearer Control. The proposal was that in considering what may be
placed inside the Tunnel for IP Bearer Control, we should consider the
encodings already supported in H.248 such as SDP and Native Tags.

        If we followed this approach, then the BICC version of H.248 would
carry the SDP information inside the Bearer Control Tunnelling package,
rather than inside the present termination properties used for SDP. This
would be a minor change, but with the important effect of clearly separating
out the MG-MG information from the MG-MGC information in the protocol.

        What remain an open issues, are (i) whether any other information or
wrapper needs to be carried with the SDP inside the tunnel, and (ii)where we
specify the procedures relating to sending and receipt of tunnelled SDP
information. These should probably be covered in the IP Bearer Control
document produced by SG11.

        Comments ?

        Regards,

        Mark Watson
Nortel Networks

        -----Original Message-----
From: Scoggins, Sophia [NC1:3T18:EXCH]
Sent: 01 June 2000 12:28
To: [email-masked]; Watson, Mark [MAIFP:EP11-M:EXCH]
Subject: Re: Multiple MGC scenarios

        Christian,

        Nortel has separate contributions regarding this topic. One
addressed

        Mark,

        Would you please answer Christian's question? This mailing list is
for
H.248 Megaco Interop testing coming in Aug.

        Regards, Sophia

        Christian Groves wrote:
> > formats. This is, however, for IP parameters only (in the BICC/ISUP+ CS2
> > parameter field. In order to backward compatible, ITU-T SG11 has decided
bearer
> > > control messages across BICC and H.248, not to add H.248 parameters in
> > > BICC messages.
> > >
> > > Cheers, Christian
> > >
> > > Sophia Scoggins wrote:
> > > >
single
won't
the
interop
current
recent
> > > > contribution to ITU-T, I have added extension to ISUP+ (now known as
> > > > BICC) to pass H.248 native tags or SDP parameters. This contribution
is
the
H.248
provisionable.  In single
multiple MGC
> > > > > Between multiple MGCs what kind of MGC-MGC interface will be used.
for the simple

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 2 Jun 2000 10:27:17 -0400

The simplest thing to do here is for me to reproduce Scott's note to me.
Definitely we will NOT violate SDP.  I think I may have posted to the ATMSDP
list and MMUSIC rather than the general Megaco list (Sorry!).

From Scott Bradner to me, received last Tuesday:

tom - Allison & I have talked about the megaco SDP extensions and
have agreed that megaco should go ahead and take the token but
coordinate with mmusic

> From: Flemming Andreasen [SMTP:[email-masked]]
> Sent: Friday, June 02, 2000 1:09 PM
> To:   [email-masked]
> Subject:      Re: H.248/BICC discussions
>
>
> 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
>
>
>
>       From:   Rosen, Brian [SMTP:[email-masked]]
>       Sent:   Friday, June 02, 2000 8:47 AM
>       To:     [email-masked]
>       Subject:        Re: H.248/BICC discussions
>
>               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
>
>               From: Tom-PT Taylor [ <mailto:[email-masked]>]
>                       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: Scott Bradner <[email-masked]>
Date: Fri, 2 Jun 2000 11:04:02 -0400

we don't want is "H.248's version of SDP";
   we want "SDP".

fully agree

Scott

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 2 Jun 2000 11:10:45 -0400

You make excellent points and I accept them in principle, meaning that
anything we document in Megaco would be coordinated with MMUSIC as Scott
advised.  The reason for using the Megaco documentation process is because
Megaco is likely to be the earliest consumer of a lot of this work.

RFC 2327 requires RFC documentation to support extensions to SDP.  The
Megaco process provides this.

> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Friday, June 02, 2000 11:00 AM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:   [email-masked]
> Tom-PT Taylor writes:
>  > 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.
>
>    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
>          Mike

---

From: Scott Bradner <[email-masked]>
Date: Fri, 2 Jun 2000 15:29:02 -0400

> Well, I'm having a problem with the idea that a package can extend SDP.

SDP is designed to be extensible - it is reasonable for other IETF working
groups to suggest extensions, the mmusic WG should be in the loop during
the discussions but having the group that has the best knowledge of
what the extensions are for be in the drivers seat means it is more
likly to get done in a reasonable period of time - mmusic can provide
feedback if they think that the proposed extensions run counter to the
SDP design goals or feel that there is a better way to do the function.

Scott