Subject: Re: Summary of Megaco Meetings

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 16 Nov 1999 09:57:07 -0600

Perhaps these could go into our requirements document.

> -----Original Message-----
> From: Greene, Nancy-M [CAR:5N10:EXCH]
> Sent: Tuesday, November 16, 1999 10:34 AM
> To:   [email-masked]
> Subject:      Re: Summary of Megaco Meetings
>
> Taking the picture from Brian's email:
>        MGC     ---   SIP/ISUP/H.323   ---   MGC
>           |                                                   |
>       Megaco                                       Megaco
>           |                                                   |
>         MG      ---   RTP/AAL2/....       ---   MG
>
> Altering to show interaction with a SIP client, as in Pyda's email below:
>
>        MGC     ---   SIP       ---------------   SIP UAC (i.e. SIP IP
> Phone)
>           |                                                   |
>       Megaco                                         /
>           |                                             /
>         MG      ---   RTP/AAL2/....  ------/
>
> In this case the RTP/AAL2 goes from the MG to the SIP IP Phone. The SIP
> UAC is a peer to the MGC. The SIP UAC does not need to know that the MGC
> uses Megaco to talk to its MG.
>
>
>
> Note that here we do not get SIP and Megaco overlapping - they are
> happening in different places.
>
>
> Nancy
> --------------------------------------------------------------------------
>
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>
>       ----------
> From:   Pyda Srisuresh[SMTP:[email-masked]]
> Sent:   Tuesday, November 16, 1999 10:06 AM
> To:     [email-masked]
> Subject:        Re: Summary of Megaco Meetings
>
>       --- Lyndon Ong <[email-masked]> wrote:
> > Hmm, maybe I can ask for more context on Henry's email:
> >
> > -- SIP could be used for transport, but it uses application layer
> framing in
> > the same way that Megaco over UDP would use application layer framing,
> so
> > there's no advantage, is there?
> >
>
>       I believe, the advantage is that the MGC is able to work with a SIP
> network.
> I.e., MGC (telephony gateway) and SIP UAC(say, IP phone) will simply be
> clients to SIP network.
>
>       cheers,
> suresh
> __________________________________________________
> Do You Yahoo!?
> Bid and sell for free at <http://auctions.yahoo.com>
>

---

From: Michael Brown <[email-masked]>
Date: Tue, 16 Nov 1999 11:45:32 -0500

I agree that the diagrams are useful to show the places where these protocols can live. Not sure where they would go in the requirements document for Megaco however since they really
show that Megaco and SIP (or the others shown) don't exist in the same domain. I suppose it is useful to reflect the interoperation point between Megaco and SIP clients.

One suggestion on the diagram, if we include it, is that specifying ISUP is, I think, a bit misleading. While ISUP as we know it could conceivably live in that space, it might be
better to show ISUP+ to reflect the enhancements needed to ISUP to support packet network bearer setup. By the same token, SIP should also be shown as SIP+ to reflect the encapsulation
of ISUP or whatever else.

Michael

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904-I]" wrote:

>             MGC     ---   SIP       ---------------   SIP UAC (i.e. SIP IP Phone)
>                |                                                   |
>            Megaco                                         /
>                |                                             /
>      In this case the RTP/AAL2 goes from the MG to the SIP IP Phone. The SIP UAC is a peer to the MGC. The SIP UAC does not need to know that the MGC uses Megaco to talk to its MG.
>
>
>
>      Note that here we do not get SIP and Megaco overlapping - they are happening in different places.
>
>      Nancy
>      > -- SIP could be used for transport, but it uses application layer framing in
>      > the same way that Megaco over UDP would use application layer framing, so
>              I believe, the advantage is that the MGC is able to work with a SIP network.

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Tue, 16 Nov 1999 12:20:09 -0800

Tom,

I was going to add the same second sentence as Michael Brown said
below (not sure where the diagram would go in the requirements
document).

The most appropriate place would be in an architecture document ....
as general information .... but we do not have such a document.

Perhaps the Architecture WG of ETSI-TIPHON would like such a diagram?

Michael Ramalho

At 11:45 AM 11/16/99 -0500, Michael Brown wrote:
>I agree that the diagrams are useful to show the places where these
>protocols can live. Not sure where they would go in the requirements
>document for Megaco however since they really
>show that Megaco and SIP (or the others shown) don't exist in the same
>domain. I suppose it is useful to reflect the interoperation point between
>Megaco and SIP clients.
>
>One suggestion on the diagram, if we include it, is that specifying ISUP is,
>I think, a bit misleading. While ISUP as we know it could conceivably live
>in that space, it might be
>better to show ISUP+ to reflect the enhancements needed to ISUP to support
>packet network bearer setup. By the same token, SIP should also be shown as
>SIP+ to reflect the encapsulation
>>      In this case the RTP/AAL2 goes from the MG to the SIP IP Phone. The
>SIP UAC is a peer to the MGC. The SIP UAC does not need to know that the MGC

Michael A. Ramalho, Ph.D.
Cisco Systems
Wall Township, NJ
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188