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

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

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Apr 2000 22:37:00 -0400

> and might even be in standby mode.

Paging to initiate a call? Why is this different from an INVITE?

> come from a valid source.

I assume that public key mechanisms are not acceptable?

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

> which people start dumping in signalling information in a uncoordinated

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.

---

From: Giuseppe Ricagni <[email-masked]>
Date: Thu, 27 Apr 2000 17:59:14 +0200

> > >"let's just use the INFO hammer" approach.

Henning,

I'd like to add another example where the need of an extention to SIP might be
analyzed.

I found your "Mobility support using SIP" paper very interesting.
I think it provides a very clear picture with respect to the scope of SIP (terminal)
mobility, what should be inplemented in SIP, what in L3, what in L2 and the
advantages of SIP mobility, in those cases where it should be applied.

However there are some (very important) scenarios  that are not covered by that
paper, and I didn't manage to figure out whether all the pieces needed to implement
them are already there/something should be added to SIP/another protocol should be
used.

Let' s assume that (for a some reasons that go beyond the technical aspects) we
always have at least 3 SIP proxies betwen two mobile endpoints. (Well, they may also
be something more complicated  than a proxy, but let's call them proxys now)

   * One proxy is in the "serving" domain: the domain where I' m currently
     registered
   * One proxy is in the "home" domain: the domain where I subscribed my mobility
     service
   * One proxy is in the "requesting" domain: the domain of the calling party

Let's now say that the terminal either changes its "serving" domain or, for some
reasons, wants to change its "serving proxy", within the same domain. Everything
happens without a call being in progress (therefore we cannot use the Info method)

What happens when the request to change the "serving proxy" comes

   * (a) from the terminal
   * (b) from the current serving proxy itself
   * (c) from the home proxy

In case (a), the terminal can send a REGISTER message to the new "serving proxy",
but then how is the "home proxy" notified of the change ?

In case (b), how does the "serving proxy" notify the terminal it has to re-register
with another proxy? Is the OPTIONS method appropriate ?

Aren't we misusing it?

Again, how is the "home proxy" notified of the change ?

In case (c), how are both the serving proxy and the terminal notified ?

In general, a call-unrelated signalling exchange might be required between the home
proxy, the current serving proxy, and the new serving proxy.

Does the SUBSCRIBE & NOTIFY mechanism (draft-roach-sip-subscribe-notify-00.txt)
cover all these cases? In particular:

   * the handover  mechanism must work independently of the existence of a call
     involving the same two entities. Call-related subscribe requests expire at the
     end of the call. The I-D mentions the possibilty (but only for a proxy ?) to
     issue a "third-party" subscribe between the same two entities involved in a
     call. It is unclear to me whether this mechanism allows for a generic
     subscription (for example by one of the endpoints towards his proxy) performed
     during a call, that extends beyond the duration of the call itself.
   * to my understanding, the duration of the subscription should be indefinite
     (minor issue: 5 days would do, anyway)
   * Wouldn' t a generic call-unrelated notification mechanism would put a lower
     burden on the involved parties?

Best Regards
Giuseppe Ricagni

----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:[email-masked]
----------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Apr 2000 16:01:46 -0400

> Let' s assume that (for a some reasons that go beyond the technical
> aspects) we always have at least 3 SIP proxies betwen two mobile
> endpoints. (Well, they may also be something more complicated  than a
> proxy, but let's call them proxys now)
> 
>    * One proxy is in the "serving" domain: the domain where I' m
>      currently registered
>    * One proxy is in the "home" domain: the domain where I subscribed
>      my mobility service
> Let's now say that the terminal either changes its "serving" domain
> or, for some reasons, wants to change its "serving proxy", within the
> same domain. Everything happens without a call being in progress
> (therefore we cannot use the Info method)
> 
> In case (a), the terminal can send a REGISTER message to the new
> "serving proxy", but then how is the "home proxy" notified of the
> change ?

Through registration proxying or via two separate REGISTER. The former
is probably better. In that case, the serving proxy is simply an
"outbound" proxy as far as the registration is concerned.

> 
> In case (b), how does the "serving proxy" notify the terminal it has
> to re-register with another proxy? Is the OPTIONS method appropriate ?

This would be third-party registration. Feasible, but not necessary, I
believe.

> In general, a call-unrelated signalling exchange might be required
> between the home proxy, the current serving proxy, and the new serving
> proxy.

> 
> Does the SUBSCRIBE & NOTIFY mechanism
> (draft-roach-sip-subscribe-notify-00.txt) cover all these cases? In
> particular:

No, REGISTER is the appropriate mechanism here.

---

From: Giuseppe Ricagni <[email-masked]>
Date: Fri, 28 Apr 2000 12:45:45 +0200

> This would be third-party registration. Feasible, but not necessary, I

As far as I know, in current GSM, handover is always initiated by the
network, not by the terminal (based on radio subsystem criteria (RF level,
quality, distance) as well as network directed criteria (e.g. current
traffic loading per cell, maintainance requests etc) ).

Case a) I was suggesting was more for the sake of generality than for other
purposes (even if it has some important applications)

Even if we are here talking about a L7 handover, hand we can assume that a
lower level subsystem can handle most of the intra-proxy handovers, I
believe the same concept should apply or, at least, we should have the
possibility, for handovers, to be initiated by the nework. I don't want to
go into too much detail, also because many of such details have yet to be
agreed.

With third party registration, do you mean that the old proxy registers the
terminal on the new proxy by putting the terminal's URI in the To header and
its own (old proxy) URI in the From header ?

The home proxy can be notifed by means of a registration proxying mechanism,
fine. But how is the terminal notified about the change, anyway? There are
(technical and non-technical) reasons why it must be aware of the change.

Thanks and
Best Regards
Giuseppe