Redirected to sip-implementors: There are some differences of opinion on the subject of decomposed gateways. You can build a gateway as a single monolithic device that has all the signalling you need, plus all the media stream handling you need. Then your "inter MGC/CallAgent" protocol extends out to that gateway. In the SIP world, that would be a SIP UA, and in a trunk gateway you would have an instance of a SIP UA for each and every DS0 (or equivalent) in the TGW. This will work. The issue is, will the complexity of all those UA instances, and the requirements of SIP UA implementations, when multiplied by, say, 10,000, or 50,000 DS0s require more compute power than you would really like to put into the box that handles 50,000 media streams? If that isn't a problem, and SIP is the only protocol you want that gateway to handle, and, if you have PRIs coming into that gateway you can handle the Q.931 termination and SIP interwork, and, if you have SS7 coming into that gateway you can handle all of the SIP-T interwork stuff with the available compute power, then it might be the way to go. If on the other hand you would rather move all that computing onto a more cost effective computing platform, a Solaris box, or redundant Linux system to name a few examples, and have the requirements for the embedded computer on the TGW limited to something that is simpler (WHEN SCALED TO LOTS OF LINES) then you might want to put all those UA instances, Q.931 terminations and/or ISUP interwork instances onto that COTS computer, and run Megaco or MGCP on the gateway -- you decompose the gateway into the signalling part and the media handling part. You could also more easily accommodate BICC signalling, or even H.323 signalling in addition to SIP, and the MG does not change, at all, to accommodate this. Typically, you have fewer computers than gateways; a big computer might be able to handle more than 50K DS0s. If you are a gateway vendor, you could implement Megaco, and that's all, and be able to sell to customers who used SIP, BICC or H.323 signalling, or any combination. If you are a "softswitch" vendor you could implement Megao and then be able to drive any gateway that had a Megaco implementation. In smaller devices, phones, say, the same principals apply, but the cost of the SIP UA implementation vs the cost of the Megaco implementation don't matter enough to even argue about. What does matter to some operators is allowing the signalling employed by the internal network to extend out to be within the customer premises. They worry about that, perhaps unnecessarily. If your residential gateway is a Megaco MG, and the Softswitch, which is completely in the operator's control is the thing with SIP on it, there is some sense that nothing the customer can do will screw up the network. I'm sure some SIP folks would say that it is easy to build a SIP proxy server which could provide all the isolation a network operator may need. Maybe. I will point out that the features and services provided by a Megaco phone or a SIP phone could be the same, but more of the work may have to be done by the softswitch. Finally, I don't think we need anything for a "SIP Trunking Gateway" beyond the SIP-T work. The latest mapping document even covers interwork to Q.SIG, which is a superset of Q.931. Brian > -----Original Message----- > From: Nitin Kumar [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 01, 2001 9:37 AM > To: '[EMAIL PROTECTED]' > Subject: [SIP] Difference between SIP and MGCP > > > Hi, > > I am writing for the first time on this mailing list. So, > hoping to get the > answer. > I have a very basic question. > I understand SIP is useful for inter-MGC communication as well as for > tunneling of PSTN signalling across IP network. > But when we talk about SIP phone or residential gateways... > Is SIP better > than MGCP or Megaco? If yes, then how ? > Is there any document which goes into detail about SIP and MGCP/Megaco > comparison? > > Moreover, Is there any work going on for SIP trunking gateway? > > regards > > -nitin > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to [EMAIL PROTECTED] with > "subscribe sip-implementors" in the body. > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
