Subject: [SIP] SIP and network element signalling (formerly: (no subject) )

From: James Kempf <[email-masked]>
Date: Tue, 25 Apr 2000 09:04:57 -0700 (PDT)

>If you need two call agents, then they must communicate.  What protocol
>would you choose?
> 
>If the call agents come from one vendor, then they may of course use a
>proprietary protocol.
>However, the network operator may wish to have the CAs use a standard
>protocol.  There are
>several choices - ISUP/SS7 is one choice, especially the Q.BICC variant.
>H.323 is another
>choice.  SIP is yet another choice.  
> 

SIP is the Session *Initiation* Protocol, it was not originally
intended for signalling between network elements outside of the
context of setting up a multimedia session. ISUP/SS7 is awkward in
an all-IP network, I`m not all that familiar with H.323.

>You started out assuming you wanted a Media Gateway/Media Gateway Controller
>architecture.
>That may be very appropriate for some kinds of gateways, but "intelligent"
>devices may be
>more appropriate for other kinds of endpoints.  Complex systems may have
>both kinds in the network.  One of the nice characteristics of sip is that
>you can build quite simple UAs, or
>quite complex UA/Server combinations.  This is less true of some other
>protocol choices.
> 

My understanding is that Megaco is primarily for "dumb"
endpoints, and SIP is for "smart" endpoints. 

This discussion brings up an issue that I'm encountering in my work
with 3rd generation cellular systems. There is need for a signalling
protocol between network elements, like SIP proxies as call agents
or a SIP proxy/call agent and a "smart" IP-based cell phone, outside
of the context of setting up a multimedia session. An example in
the cell phone world is paging to determine whether a cell phone
happens to be in a particular service area. Or having an
intelligent IP cell phone retrieve authentication credentials from 
a proxy, so it can authenticate incoming INVITEs, before any
call is in progress.

There are ways that one could force these situations into a SIP
context, like setting up a multimedia session to perform the operation,
then using a SIP INFO method to transfer the data or perform the
operation, but these seem somewhat forced, like a hack. Despite this, some
people are forging ahead with this anyway due to lack of a better solution. 
Megaco doesn't seem like the right solution either, if its intended use 
primarily covers controlling media gateways for "dumb" devices. Most cell phones 
these days are pretty intelligent, and since 3GPP has decided to standardize on 
SIP for a future all-IP cell phone, cell phones are likely to become even more 
intelligent as they move to using IP for signalling and voice services as well
as for data.

So the question is what to do? Should these functions simply be left to
proprietary protocols? Is there need for another protocol that is 
specifically designed for signalling between network elements, like
proxies, to cover these cases? Or should SIP be somehow expanded
to cover them? 

My opinion is that proprietary protocols are not appropriate, since
most of these functions are covered by standardized protocols in
the current SS7 based network, so this would be a step backwards.
Since I generally like to keep protocols well focussed and therefore
hopefully simple, expanding out SIP to handle these cases seems 
fraught with potential featurization peril. On the other hand,
it is unclear to me whether there are enough cases to cover
having a new protocol.

Comments?

Maybe this isn't the right list to explore this issue (if so, please
tell me to get lost)?

		jak

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Apr 2000 12:08:57 -0400

It might be helpful to describe those things that are different for
"network element" signaling and what information needs to be conveyed. I
don't see (yet) why this needs to be a hack, but I would stay away from
"let's just use the INFO hammer" approach.

I wouldn't read too much into a protocol name. This is more of a
historical accident than a political platform. As far as I can tell, SIP
should be able to handle the tasks typically done by signaling
protocols. It is not a multimedia transport protocol such as RTP or a
replacement for email or ftp.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs