RE: [SIP] distributed sip

["Peter Blatherwick" <[e-mail]>]

Megaco IP Phone MG provides such a solution for master/slave controlled
"dumb" appliances, which can easily be used within a SIP-based network.  See
http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-03.txt.  Its
currently in Last Call, for Informational RFC, in Megaco WG.  

Before the religious war starts (experience shows it will), I want to make
it clear I very much like both SIP and the Megaco/H.248 approach to end
devices.  Both SIP-based and Megaco/H.248-based end user appliances have
strong roles in the real world.  The two models are completely compatible
within a system, and are complementary in nature.  Properly implemented, the
end user actually can't tell the difference between the two approaches. 

While the peer-peer approach characterized by SIP is truly excellent for
SmartPhone type applications supporting stand-alone features and services,
the master/slave type approach characterized by Megaco/H.248 affords major
advantages for new feature/service development and deployment, especially
across large systems supporting horizontal features/services.  With the
Megaco/H.248 approach, since new features and services are developed and
deployed on network-based servers near the network edge (on the Media
Gateway Controllers (MGC)), mass software downloads to the large numbers of
diverse devices out there is not necessary to introduce the new feature,
generic rather than device-specific development tools can be used, and there
is no need to "upgrade" end devices over time to add memory etc since the
device itself is unchanged.  Since the MGC acts as a proxy for the end
devices (slightly different sense than SIP usage here), its still
fundamentally a SIP network, operating in conjunction with
Megaco/H.248-based master/slave control underneath -- the two are
orthogonal, not in competition.   

Cost is a diminishing issue, but cost of a master/slave type system will
always be lower than for peer-peer type approach since the end device does
not need to carry the more complex peer protocol logic, implement features
and feature interactions locally, and does not locally implement the
associated user interface either (just the widgets to drive the UI).  Size
of the specific protocol stack itself is much less of an issue than the
associated implementation logic.  

Hope that helps,
Peter Blatherwick

-----Original Message-----
From: Dvir Oren [mailto:[e-mail]]
Sent: Saturday, September 30, 2000 09:33
To: farhan
Cc: SIP
Subject: [SIP] distributed sip


farhan writes ("[SIP] distributed sip"):

> We will at this stage have a distributed SIP wherein, the actual endpoints
> of a sip call are slave units of a central control unit and the control
unit
> in turn is sip compliant (the slave units are not).

What you are suggesting is in fact some SIP-X gateway, where 'X' is
some proprietery protocol that is supposed to be smaller than SIP.
The network between the SIP gateway and the end point units is not a
SIP network, but an 'X network'.  You might even want to hink of using 
MGCP, which is client-server based, where the end points are just dumb 
terminals.  I'm suggesting this since it might help to use something
that already has been done.

On the other hand, since between the SIP gateway and the remote units
there is a network, you'll have to handle all the possible errors in
the network.  Basically, this will mean re-inventing a protocol.  So,
why not use an existing one?

I don't even see why you can't use SIP.  

> client is just a 48kb slave totally controlled by hotfoon.com. As a

I don't think you need one of those giant C++/Java implementations
that are megabytes in size.  You can do with a small implementation of 
SIP.

-- 
Dvir Oren               <[e-mail]>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  [phone]  Fax:  [phone]

_______________________________________________
SIP mailing list
[e-mail]
http://lists.bell-labs.com/mailman/listinfo/sip