Subject: RE: [SIP] SIP and network element signalling (formerly: (no subje ct) )

From: James Kempf <[email-masked]>
Date: Tue, 25 Apr 2000 12:58:30 -0700 (PDT)

>If those of us in the telecommunications industry are going to embrace SIP
>as a signaling protocol (as it appears we have), we are going to have to
>find ways to do the things in the IP network that we've done in the
>circuit-switched network (and wireless network).  

Agreed.

>The use of the SIP INFO
>method, along with new MIME Type proposals, for ISUP and QSIG "tunneling"
>appears to be generally endorsed.  It was defined as a solution to providing
>much of the circuit-switched network functionality in a SIP network.  I may
>be wrong, but the intention of the authors of the SIP INFO ID appears to be
>for its use in solving many outstanding issues with converging the
>circuit-switched network with packet networks.
>

It's not clear that tunnelling legacy protocols is the right solution
for all IP networks, including IP to the mobile terminal. IMHO, there is
an important compatibility role for legacy protocols, but there
are other areas, authentication for example, that could benefit
from new approaches when signalling to the mobile terminal
over IP becomes possible. All IP network elements may also benefit.

>Extending (where appropriate) and using existing protocols is preferable to
>defining new ones in my opinion.  I do not want to see the INFO method
>become a catch-all though.  Obviously, more thought and work is needed to
>bring about interoperability between the two telecommunications network with
>the IP network.

Agreed.

		jak

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

---

From: "Culpepper, Bert" <[email-masked]>
Date: Tue, 25 Apr 2000 14:07:16 -0500

circuit-switched network (and wireless network).  The use of the SIP INFO

Regards,
Bert

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, April 25, 2000 12:35 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [SIP] SIP and network element signalling (formerly: (no
> subject) )
> 
> 
> >
> >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.
> >
> 
> The particular ones I've encountered so far in my work with IS-41 are:
> 
> 1) Paging a cell phone that currently doesn't have an ongoing call
> and might even be in standby mode.
> 
> 2) Having an IP-based phone obtain authentication credentials from a
> network 
> authentication server, which may also function as a SIP proxy/call
> agent, to
> allow the IP-based cell phone to authenticate INVITEs as having
> come from a valid source.
> 
> 3) Allowing the call agent to request a list of features (tones
> and announcements) from its home service database for delivery to the
> mobile 
> terminal (FeatureRequest in IS-41). Athough this message would most
> likely be 
> encountered during setup or execution of a call (when the INFO method
> could be
> used), it may occur outside of that context and it will require
> communication 
> between two network elements, one of which (the home service database)
> is not 
> involved in routing the call.
> 
> There are likely to be others. 
> 
> >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.
> 
> Using SIP or enhancing it if necessary is certainly an attractive
> option.
> I'm a bit concerned that the INFO method might become a catchall, in
> which people start dumping in signalling information in a
> uncoordinated
> manner. 
> 
> Perhaps an auxillary protocol, like, SDP for the INFO method would
> work,
> along with opening up the use of INFO between network elements when
> a call is not in progress (currently it is only defined for when
> a call is in progress).
> 
> 		jak
> 
> 
> 
> 
>