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

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Apr 2000 10:34:03 -0400

Mauricio Arango wrote:
> 
> >>
> >> 1) Paging a cell phone that currently doesn't have an ongoing call
> >> and might even be in standby mode.
> >
> >Paging to initiate a call? Why is this different from an INVITE?
> >
> 
> Not necessarily to initiate a call but to find the location (cell) of the
> station, or obtain other station information before the call is made.
> 
> I think one of the points Jim is making is that if INVITE is used for both
> these type of queries and for initiating a call, there doesn't seem to be
> a way in SIP to tell a station or any other element to treat INVITEs used
> for different purposes in a different way. A possibility could be a SIP
> pre-call query method.

What about just using OPTIONS? It is a query method that gets routed in
the same way that other SIP requests, such as INVITE, would be.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

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

---

From: Mauricio Arango <[email-masked]>
Date: Wed, 26 Apr 2000 10:30:22 -0400

Mauricio

-----------------

>
>
>James Kempf wrote:
>> 
>> >
>> >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:
>> 
>> 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.
>
>I assume that public key mechanisms are not acceptable?
>
>> 
>> 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.
>
>Might help to define 'call agent', as I'm not sure I have the same
>understanding of this term as you might. Sounds like an OPTIONS request
>to me, but then I'm not sure how 'tones and announcements' fit into
>this, as that sounds like media, not signaling.
>
>> 
>> 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.
>
>I share your concern - INFO should be used very sparingly. There is no
>cost in SIP in defining new methods, for example, which allows one to
>express what actually is meant rather than somehow being implied in the
>body or a collection of headers.
>
>> 
>> 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
>>