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

From: James Kempf <[email-masked]>
Date: Wed, 26 Apr 2000 08:26:36 -0700 (PDT)

>> 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?
>

An INVITE would work if the phone was being paged to set up a call, but paging 
does not necessarily lead to a call being set up. It may be done
for administrative reasons, for example, to flush a cached service
profile if the phone is no longer in the service area. My understanding is that 
INVITE is part of a precall setup process only.

>> 
>> 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?
>

Sure, but I'm talking about setting up the keying in the first place.
Something lightweight is needed. It may be possible to leverage
off the mobile IP keying here.

>> 
>> 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.
>

I thought that OPTIONS was only allowed in the context of either
setting up a call or an ongoing call. With regard to what the "tones
and announcents" are, that's all the IS-41 spec says about the return
value for FeatureRequest. I presume its something like the 
announcement you get when somebody's phone is off and you try to
call it. Though that is in the context of a call setup, FeatureRequest
is not restricted to an in progress call, as far as I can determine.

		jak

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Apr 2000 12:36:24 -0400

> is not restricted to an in progress call, as far as I can determine.
OPTIONS is meant to be used pre-call, to find out what the other side
can do. An INVITE may follow or not. So it doesn't have to be part of a
call.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 26 Apr 2000 11:53:38 -0700

>INVITE is part of a precall setup process only.

Without knowing the specifics of your application it seems OPTIONS would be 
appropriate.

One thing you haven't mentioned is alphanumeric "paging", where 
SUBSCRIBE/NOTIFY would be appropriate.

>off the mobile IP keying here.

seems reasonable to exchange keying information either before or during a 
REGISTER.  several methods for "securing" signalling have been proposed: 
Basic, Digest, RADIUS, Kerberos, IKE, TLS.....    stay tuned, this is a 
complex topic.

>is not restricted to an in progress call, as far as I can determine.

tones and features seem like the type of thing returned in a 183 session 
progess message, which corresponds to an attempted INVITE, but typically 
not a call "in-progress."

if for some reason, you need to send tones to the phone completely outside 
of the context of an attempted call, i have some ideas, but i would want to 
know more specifics before elaborating.

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Apr 2000 00:54:40 -0400

> Without knowing the specifics of your application it seems OPTIONS would be

As has been pointed out, I believe OPTIONS is appropriate. What kind of
information are you looking to obtain from the page? Is the intent that
this page have a particular state side effect? If the page has no effect
on the state of the phone, and simply returns the current location of
the phone, its capabilities, and so on, OPTIONS is exactly what you
want. 

> Basic, Digest, RADIUS, Kerberos, IKE, TLS.....    stay tuned, this is a

SIP is not meant as a keying exchange protocol. There are already keying
exchange protocols out there, as Rohan has pointed out. I am very queasy
about trying to invent a new one ontop of SIP just to avoid having to
implement "another" protocol. In reality, you will be implementing
another protocol, but just using SIP as a transfer method between two
points. That is the easy part of any protocol. I'll also note that
security protocols are notoriously easy to get wrong. 

> >is not restricted to an in progress call, as far as I can determine.

Without more specifics, its hard to say what the right way to do it is.

Related to this, there is a tendency of folks to try and support legacy
features within SIP by using the same legacy mechanisms used to
implement those legacy features. I don't think this is the right
approach. Rather, figure out the service requirement, generalize it, and
then consider how it can be done in SIP. Saying we need the equivalent
of "FeatureRequest" makes me nervous since the mechanism for services
within SIP is not the same as PSTN. Consider the specific case you
mention, that of getting an announcement when someones phone is off. In
SIP, it seems like this would work as follows:

1. A calls B, which is routed to B's "home" proxy
2. B is registered elsewhere, at this "remote" proxy, so B's home proxy
forwards the request there
3. at the remote proxy, the call is forwarded the current location of
the user
4. the user does not answer, so the remote proxy returns 408
5. the home proxy receives 408. It has the service enabled so that if it
receives no answer, the call is forwarded to a media server which
responds with a 183, plays the announcement, and then responds with a
final 400.

This achieves the desired service without inheriting the particulars of
how it was implemented within IS-41. 

I'll also observe that one of the absolutely essential components of the
SIP-T work, which also supports legacy signaling, is that call semantics
are always derived from SIP, not the tunneled protocols. INFO carries
messages which have no impact on call or session state, and are
basically "passed to the application", which is a gateway in this case.
This ensures that any features are still  being provided by SIP, in a
SIP fashion, while the ISUP is carrying only information that is "FYI".
This is possible since ISUP signaling is honestly not radically
different from SIP, just that it has lots of extra bits and information
that is not really needed for SIP itself.

So, for people considering INFO method for something or other, be aware
of this. The INFO draft explicitly states a very limited scope for INFO.
Using it as a catchall way for anything will definitely cause
interoperability nightmares. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com