Subject: Re: Summary of Megaco Meetings

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 1999 10:22:11 -0500

Henry
 
I am confused.  Megaco/H.248 is a protocol between a media gateway and
a media gateway controller.  SIP is a protocol between two media gateway
controllers.
RTP, in this architecture, is a protocol between two media gateways.
 
The SIP-BCP-T draft talks about enhancing SIP so that it can transport
ISUP.  
ISUP is another protocol between two media gateway controllers, as is H.323:

       MGC     ---   SIP/ISUP/H.323   ---   MGC
          |                                                   |
      Megaco                                       Megaco
          |                                                   |
        MG      ---   RTP/AAL2/....       ---   MG

My confusion is how we could use SIP-BCP-T between a media gateway and
a media gateway controller?  
 
Brian

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Monday, November 15, 1999 8:34 AM
To: [email-masked]
Subject: Re: Summary of Megaco Meetings

>The SCTP transport is positioned here simply as an alternative to transport
over TCP or UDP/ALF, between the MG and MGC.  Megaco/H.248 is NOT working on
inter->MGC signalling.
 
Tom, would still like to know why you have not included SIP as an option.
"SIP Best Current Practice for Telephony Interworking" 
http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt
<http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt>  
 
Henry

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Monday, November 15, 1999 7:30 AM
To: Henry Sinnreich; [email-masked]
Subject: RE: Summary of Megaco Meetings

The SCTP transport is positioned here simply as an alternative to transport
over TCP or UDP/ALF, between the MG and MGC.  Megaco/H.248 is NOT working on
inter-MGC signalling.

        -----Original Message----- 
From:   Henry Sinnreich [SMTP:[email-masked]] 
Sent:   Monday, November 15, 1999 7:03 AM 
To:     Taylor, Tom-PT [CAR:B904-I:EXCH];
[email-masked] 
Subject:        RE: Summary of Megaco Meetings 
Importance:     High 

        > providing the option of Megaco/H.248 transport over SIGTRAN SCTP
was in 
> preparation, for determination at the February SG 16 meeting 
sorry, I missed that part, but wonder why the SIP option is not pursued 
here, since a number of users and vendors have done work in the area of 
inter-gateway signaling using SIP. A group of IETF authors have published 
the revised draft 

        "SIP Best Current Practice for Telephony Interworking" 
http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt
<http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt>  

        Tom, is there a reason why your WG report does not include this
draft in the 
options? 
Could it be because SG.16 does not say so? 

        Henry 

        > -----Original Message----- 
> From: Media Gateway Control (megaco) 
> [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of Tom-PT Taylor 
> Sent: Sunday, November 14, 1999 8:12 PM 
> To: [email-masked] 
> Subject: Summary of Megaco Meetings 
> 
> 
> This message summarizes the outcome of the Megaco meetings held Wednesday 
> and Friday mornings Nov. 10 and 12 respectively, plus design team and 
> informal activity held between those two meetings. 
> 
> The Wednesday meeting opened with the announcement that we were still 
> tinkering with process.  Given that the Megaco protocol still has some 
> deficiencies, the latest proposal is to mark the completion of the work by

> going to IESG last call and issuing a Proposed Standard BEFORE the ITU-T 
> decision meeting in February.  The intent is to achieve a cleaner 
> handoff to 
> Study Group 16.  ITU-T management had been advised of this change in 
> procedure and had agreed with it.  Once H.248 has been decided, we can 
> revert to the original plan. 
> 
> At the Wednesday meeting, Tom Taylor [[email-masked]] 
> presented a 
> review of the protocol against our requirements document.  Tom 
> will release 
> an I-D recording the results of that review shortly.  A number of 
> discrepancies were noted, some of which raise issues for the 
> protocol.  In a 
> few cases the meeting agreed that the protocol had met intent and the 
> requirements needed clarification.  Many cases were noted where the 
> requirements will be met when work on package specification has been 
> completed.  Nancy Greene [[email-masked]] will issue a new 
> version of the requirements document within a week, with the 
> intention that 
> this go for WG Last Call.   (As a result of a decision made at the IETF 
> plenary on Wednesday night, the requirement to support legal interception 
> will be deleted from the document.) 
> 
> Brian Rosen [[email-masked]] presented the results of the Redbank 
> meeting.   He noted that despite a great deal of discussion in Redbank, we

> still do not have a fully satisfactory description of the operation of 
> events and signals.  Following Brian's presentation, Mike Kallas 
> [[email-masked]] and Zacharias Bilalis 
> [[email-masked]] presented the status of the work on 
> packages, another incomplete work item.  Finally, Glenn Parsons 
> [[email-masked]] presented the status of work on FAX 
> and modem 
> packages.  A separate design team has been formed under the leadership of 
> Glenn, Roy Spitzer [[email-masked]],  and James Rafferty 
> [[email-masked]], to create FAX and modem packages.  This team

> was asked to coordinate with Gunnar Hellstrom 
> [[email-masked]] 
> to ensure that text conversation was properly supported. 
> 
> The Wednesday afternoon meeting of the protocol design team considered two

> inter-related problems: how to differentiate between ephemeral 
> terminations 
> with different transport (IP, ATM) when adding them, and how to determine 
> the capabilites afforded to ephemeral terminations before any such 
> terminations have been created in the MG.  The third topic of how to keep 
> audit response message sizes reasonable was also considered.  This meeting

> came to some definite conclusions, but some of those conclusions were 
> refuted at the Friday morning meeting of the WG (see below). 
> 
> The Thursday afternoon meeting of the protocol design team 
> wrestled with the 
> question of how events operate within the protocol.  The meeting failed to

> come to a conclusion.  Discussion was continued informally on Thursday 
> evening. 
> 
> In the Friday meeting, Matt Holdrege [[email-masked]] drew 
> attention to the 
> preliminary draft for a Megaco MIB and asked for further 
> contributions.  In 
> discussion of this item, it was noted that a document is needed that 
> describes how all of the various MIBs that deal with MG operation fit 
> together.  Scott Bradner suggested that Megaco might provide a 
> first cut at 
> such a document.  Chip Sharp [[email-masked]] noted that an annex 
> providing the option of Megaco/H.248 transport over SIGTRAN SCTP was in 
> preparation, for determination at the February SG 16 meeting (and decision

> presumably in the fall).  The ITU-T is able to add annexes 
> without reissuing 
> the whole protocol document. 
> 
> Most of the remainder of the meeting was spent discussing open issues, and

> particularly proposals arising out of the design meetings and informal 
> discussion the night before. 
> 
> An important point noted in this discussion was that transport 
> may vary per 
> stream, so that the same termination supports both Video/RTP/UDP/IP and 
> Voice/RTP/AAL5, for instance.  As a result, one cannot in general assume 
> that the terminationID carries any information about the type of transport

> supported on the termination.  Two proposals to simplify audits were 
> accepted as worth consideration on the list.  One is to specify the naming

> pattern for terminations on the MG as a string property of ROOT. 
> The other 
> is for syntax to request and receive aggregated (set union of) 
> capabilities 
> for a group of terminations. 
> 
> Proposals coming out of Thursday evening's informal discussion of events 
> were also discussed.  One of these proposals was to eliminate event 
> buffering except for the operation of digit maps, and to have the latter 
> then perform any buffering needed.  Michael Thomas [[email-masked]] pointed

> out that the intent of quarantine buffers in MGCP was to capture 
> ALL events, 
> not just those enabled in the current event descriptor, and hold those 
> events between the time a Notify is sent to the MGC and the time 
> it sends an 
> update to the reporting termination.  This view differs from that 
> understood 
> by the protocol design team, and needs to be considered in further work on

> events.  It was also proposed that digit maps should be defined 
> in packages 
> rather than as part of the basic protocol.  This drew 
> unfavourable comment, 
> on the ground that it amounted to a structural change to the protocol as 
> currently defined and put an excessive amount of behaviour into a package.

> 
> The Chair noted that Megaco requires a number of extensions to 
> SDP.  In his 
> view these extensions could be created following the process 
> defined in RFC 
> 2327 Appendix B on the basis of documentation produced by Megaco 
> rather than 
> MMUSIC.  He will discuss this proposition with Joerg Ott 
> [[email-masked]], Chair of MMUSIC. 
> 
> The Friday meeting concluded with a discussion of the future of 
> Megaco.  The 
> general feeling was that there are definitely open issues which should be 
> tackled in H.248v2, but that work shouldn't start until we get some 
> implementation experience.  The advice provided by the closing speaker was

> representative.  He suggested that the process from here on in should be 
> agreed on the list; that it would be more efficient to take 
> future work to a 
> single body (probably the ITU-T), and that package development after the 
> basic set should be done by way of BOFs or, if sufficiently complex, by ad

> hoc Working Groups. 
> 
> Tom Taylor 
> Advisor -- IPConnect Standards 
> E-mail: [email-masked] (internally, Tom-PT Taylor) 
> Phone and FAX: +1 613 736 0961

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 15 Nov 1999 14:21:43 -0600

RE: Summary of Megaco MeetingsBrian,

Your diagram is 100% correct IMHO and I hope it would have some place in
MEGACO documents.
Would have saved all today's mail...
Tom: Any way to include Brian's diagram?

Thanks, Henry
  -----Original Message-----
  From: Media Gateway Control (megaco)
[mailto:[email-masked]]On Behalf Of Brian Rosen
  Sent: Monday, November 15, 1999 9:22 AM
  To: [email-masked]
  Subject: Re: Summary of Megaco Meetings

  Henry

  The SIP-BCP-T draft talks about enhancing SIP so that it can transport
ISUP.
  ISUP is another protocol between two media gateway controllers, as is
H.323:

  Brian
    -----Original Message-----
    From: Henry Sinnreich [mailto:[email-masked]]
    Sent: Monday, November 15, 1999 8:34 AM
    To: [email-masked]
    Subject: Re: Summary of Megaco Meetings

    >The SCTP transport is positioned here simply as an alternative to
transport over TCP or UDP/ALF, between the MG and MGC.  Megaco/H.248 is NOT
working on inter->MGC signalling.

    Tom, would still like to know why you have not included SIP as an
option.
    "SIP Best Current Practice for Telephony Interworking"
    http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt

    Henry

      -----Original Message-----
      From: Tom-PT Taylor [mailto:[email-masked]]
      Sent: Monday, November 15, 1999 7:30 AM
      To: Henry Sinnreich; [email-masked]
      Subject: RE: Summary of Megaco Meetings

      The SCTP transport is positioned here simply as an alternative to
transport over TCP or UDP/ALF, between the MG and MGC.  Megaco/H.248 is NOT
working on inter-MGC signalling.

        -----Original Message-----
        From:   Henry Sinnreich [SMTP:[email-masked]]
        Sent:   Monday, November 15, 1999 7:03 AM
        To:     Taylor, Tom-PT [CAR:B904-I:EXCH];

was in
        > preparation, for determination at the February SG 16 meeting
        sorry, I missed that part, but wonder why the SIP option is not
pursued
        here, since a number of users and vendors have done work in the area
of
        inter-gateway signaling using SIP. A group of IETF authors have
published
        the revised draft

        Henry

        > [mailto:[email-masked]]On Behalf Of Tom-PT
Taylor
was in

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 16 Nov 1999 20:01:31 -0800

Have you read RFC 2719?

That should hopefully be all the architectural reference needed in MEGACO
and SIGTRAN documents.

At 02:21 PM 11/15/99 -0600, Henry Sinnreich wrote:
>Brian,
>>> transport over TCP or UDP/ALF, between the MG and MGC.  Megaco/H.248 is
>>> NOT working on inter->MGC signalling.
>>>
>>><http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt>h
>>>ttp://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt
>>>
>>>Henry
>>>
>>>>transport over TCP or UDP/ALF, between the MG and MGC.  Megaco/H.248 is
>>>>NOT working on inter-MGC signalling.
>>>>-----Original Message-----  From:   Henry Sinnreich
>>>>[SMTP:[email-masked]]  Sent:   Monday, November 15, 1999 7:03
>>>>AM  To:     Taylor, Tom-PT [CAR:B904-I:EXCH];
>>>>[email-masked]  Subject:        RE: Summary of
>>>>Megaco Meetings  Importance:     High
>>>>
>>>> > providing the option of Megaco/H.248 transport over SIGTRAN SCTP was
>>>> in  > preparation, for determination at the February SG 16
>>>> meeting  sorry, I missed that part, but wonder why the SIP option is
>>>> not pursued  here, since a number of users and vendors have done work
>>>> in the area of  inter-gateway signaling using SIP. A group of IETF
>>>> authors have published  the revised draft
>>>>
>>>>Tom, is there a reason why your WG report does not include this draft
>>>>in the  options?  Could it be because SG.16 does not say so?
>>>>
>>>>Henry
>>>>
>>>> > -----Original Message-----  > From: Media Gateway Control
>>>> (megaco)  >
>>>> [<mailto:[email-masked]>mailto:[email-masked]
>>>> RTELNETWORKS.COM]On Behalf Of Tom-PT Taylor  > Sent: Sunday, November
>>>> 14, 1999 8:12 PM  > To: [email-masked]  >
>>>> Subject: Summary of Megaco Meetings  >  >  > This message summarizes
>>>> the outcome of the Megaco meetings held Wednesday  > and Friday
>>>> mornings Nov. 10 and 12 respectively, plus design team and  > informal
>>>> activity held between those two meetings.  >  > The Wednesday meeting
>>>> opened with the announcement that we were still  > tinkering with
>>>> process.  Given that the Megaco protocol still has some  >
>>>> deficiencies, the latest proposal is to mark the completion of the
>>>> work by  > going to IESG last call and issuing a Proposed Standard
>>>> BEFORE the ITU-T  > decision meeting in February.  The intent is to
>>>> achieve a cleaner  > handoff to  > Study Group 16.  ITU-T management
>>>> had been advised of this change in  > procedure and had agreed with
>>>> it.  Once H.248 has been decided, we can  > revert to the original
>>>> plan.  >  > At the Wednesday meeting, Tom Taylor
>>>> [[email-masked]]  > presented a  > review of the protocol
>>>> against our requirements document.  Tom  > will release  > an I-D
>>>> recording the results of that review shortly.  A number of  >
>>>> discrepancies were noted, some of which raise issues for the  >
>>>> protocol.  In a  > few cases the meeting agreed that the protocol had
>>>> met intent and the  > requirements needed clarification.  Many cases
>>>> were noted where the  > requirements will be met when work on package
>>>> specification has been  > completed.  Nancy Greene
>>>> [[email-masked]] will issue a new  > version of the
>>>> requirements document within a week, with the  > intention that  >
>>>> this go for WG Last Call.   (As a result of a decision made at the
>>>> IETF  > plenary on Wednesday night, the requirement to support legal
>>>> interception  > will be deleted from the document.)  >  > Brian Rosen
>>>> [[email-masked]] presented the results of the Redbank  >
>>>> meeting.   He noted that despite a great deal of discussion in
>>>> Redbank, we  > still do not have a fully satisfactory description of
>>>> the operation of  > events and signals.  Following Brian's
>>>> presentation, Mike Kallas  > [[email-masked]] and
>>>> Zacharias Bilalis  > [[email-masked]] presented the
>>>> status of the work on  > packages, another incomplete work
>>>> item.  Finally, Glenn Parsons  > [[email-masked]]
>>>> presented the status of work on FAX  > and modem  > packages.  A
>>>> separate design team has been formed under the leadership of  > Glenn,
>>>> Roy Spitzer [[email-masked]],  and James Rafferty  >
>>>> [[email-masked]], to create FAX and modem packages.  This
>>>> team  > was asked to coordinate with Gunnar Hellstrom  >
>>>> [[email-masked]]  > to ensure that text conversation was
>>>> properly supported.  >  > The Wednesday afternoon meeting of the
>>>> protocol design team considered two  > inter-related problems: how to
>>>> differentiate between ephemeral  > terminations  > with different
>>>> transport (IP, ATM) when adding them, and how to determine  > the
>>>> capabilites afforded to ephemeral terminations before any such  >
>>>> terminations have been created in the MG.  The third topic of how to
>>>> keep  > audit response message sizes reasonable was also
>>>> considered.  This meeting  > came to some definite conclusions, but
>>>> some of those conclusions were  > refuted at the Friday morning
>>>> meeting of the WG (see below).  >  > The Thursday afternoon meeting of
>>>> the protocol design team  > wrestled with the  > question of how
>>>> events operate within the protocol.  The meeting failed to  > come to
>>>> a conclusion.  Discussion was continued informally on Thursday  >
>>>> evening.  >  > In the Friday meeting, Matt Holdrege [[email-masked]]
>>>> drew  > attention to the  > preliminary draft for a Megaco MIB and
>>>> asked for further  > contributions.  In  > discussion of this item, it
>>>> was noted that a document is needed that  > describes how all of the
>>>> various MIBs that deal with MG operation fit  > together.  Scott
>>>> Bradner suggested that Megaco might provide a  > first cut at  > such
>>>> a document.  Chip Sharp [[email-masked]] noted that an annex  >
>>>> providing the option of Megaco/H.248 transport over SIGTRAN SCTP was
>>>> in  > preparation, for determination at the February SG 16 meeting
>>>> (and decision  > presumably in the fall).  The ITU-T is able to add
>>>> annexes  > without reissuing  > the whole protocol document.  >  >
>>>> Most of the remainder of the meeting was spent discussing open issues,
>>>> and  > particularly proposals arising out of the design meetings and
>>>> informal  > discussion the night before.  >  > An important point
>>>> noted in this discussion was that transport  > may vary per  > stream,
>>>> so that the same termination supports both Video/RTP/UDP/IP and  >
>>>> Voice/RTP/AAL5, for instance.  As a result, one cannot in general
>>>> assume  > that the terminationID carries any information about the
>>>> type of transport  > supported on the termination.  Two proposals to
>>>> simplify audits were  > accepted as worth consideration on the
>>>> list.  One is to specify the naming  > pattern for terminations on the
>>>> MG as a string property of ROOT.  > The other  > is for syntax to
>>>> request and receive aggregated (set union of)  > capabilities  > for a
>>>> group of terminations.  >  > Proposals coming out of Thursday
>>>> evening's informal discussion of events  > were also discussed.  One
>>>> of these proposals was to eliminate event  > buffering except for the
>>>> operation of digit maps, and to have the latter  > then perform any
>>>> buffering needed.  Michael Thomas [[email-masked]] pointed  > out that
>>>> the intent of quarantine buffers in MGCP was to capture  > ALL
>>>> events,  > not just those enabled in the current event descriptor, and
>>>> hold those  > events between the time a Notify is sent to the MGC and
>>>> the time  > it sends an  > update to the reporting termination.  This
>>>> view differs from that  > understood  > by the protocol design team,
>>>> and needs to be considered in further work on  > events.  It was also
>>>> proposed that digit maps should be defined  > in packages  > rather
>>>> than as part of the basic protocol.  This drew  > unfavourable
>>>> comment,  > on the ground that it amounted to a structural change to
>>>> the protocol as  > currently defined and put an excessive amount of
>>>> behaviour into a package.  >  > The Chair noted that Megaco requires a
>>>> number of extensions to  > SDP.  In his  > view these extensions could
>>>> be created following the process  > defined in RFC  > 2327 Appendix B
>>>> on the basis of documentation produced by Megaco  > rather than  >
>>>> MMUSIC.  He will discuss this proposition with Joerg Ott  >
>>>> [[email-masked]], Chair of MMUSIC.  >  > The Friday meeting
>>>> concluded with a discussion of the future of  > Megaco.  The  >
>>>> general feeling was that there are definitely open issues which should
>>>> be  > tackled in H.248v2, but that work shouldn't start until we get
>>>> some  > implementation experience.  The advice provided by the closing
>>>> speaker was  > representative.  He suggested that the process from
>>>> here on in should be  > agreed on the list; that it would be more
>>>> efficient to take  > future work to a  > single body (probably the
>>>> ITU-T), and that package development after the  > basic set should be
>>>> done by way of BOFs or, if sufficiently complex, by ad  > hoc Working
>>>> Groups.  >  > Tom Taylor  > Advisor -- IPConnect Standards  > E-mail:
>>>> [email-masked] (internally, Tom-PT Taylor)  > Phone and
>>>> FAX: +1 613 736 0961