Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt

From: Idnani Ajaykumar-AIDNANI1 <[email-masked]>
Date: Thu, 10 Oct 2002 14:13:10 -0500

All,

We have seen a lot of good comments on this draft.

So here are a few thoughts on the basic reason for writing this draft. We
will try and address issues as we go.

In a mobile environment you have a mobile node (MN) which is not SIP aware.
But it talks to the SIP core network through a SIP Gateway which sits on the
network. The Gateway serves more than one MNs so it will run multiple UA
engines one for each of the MN's it serves. This is called a SIP Proxy UA in
the draft.

Now, when a mobile (MN) registers using non-SIP means, the Proxy UA converts
the register to a SIP Register and sends it to the registrar.

The problem really is when the MN moves from one Proxy UA to another. It
registers with the new Proxy UA, but does not de-register with the old Proxy
UA. It depends on the core network to maintain the registrations correctly
across the proxy UAs.

The draft tries to solve the problem, by having the SIP Registrar send a
notification to the old Proxy UA that the MN has moved. This is not the
normal behavior of the Registrar as someone rightly pointed out because the
Registrar is not a SIP Event server. But the registrar has all the
information it needs to send the notification. What we are suggesting is
that we decouple the NOTIFY message from the SUBSCRIBE message and allow it
to be sent in response to other methods also. Of course this raises
compatibility issues with older versions of SIP and therefore we had
suggested in the draft that the "Event" header which is currently a
mandatory header in the SUBSCRIBE method, be made optional header in other
methods like REGISTER. So only when the Registrar sees a REGISTER method
with the "Event" header, would it send NOTIFYs when the contact information
for the MN changes. Another thing to note out here is, (and this seems to
have created some confusion) the proxy UA is not subscribing for some other
party's information. It is just expecting notification of events for a MN
that it is serving so that it can clean up its resources. It can be argued
that the resource can be cleared when the registration times out, but until
that is done there are chances that the INVITEs would be forked to a proxy
UA that is not really serving the MN, and the proxy UA would end up using
precious radio resources trying to page the MN.

There was also some talk about issues with other headers, but we think we
can take the approach of using the same value for headers, as would be used
in a normal REGISTER message.

One more clarification, the draft was shown using a "presence" event, but we
feel that we could just as well use some other event - maybe a new one -
just to solve the purpose of notifying the old proxy UA that the MN has
moved.

Thanks and Regards
- Ajay

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Monday, October 07, 2002 3:15 PM
To: [email-masked]; [email-masked]; [email-masked];
Ajaykumar Idnani; Steve Upp; Tom Hallin
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt

Duncan wrote:
> However, I would support a more general version of this 
> draft.  For instance, the real gain I can see (as Adam says, 
> this is only an optimisation, which SIPPING won't allow) is 
> that one REGISTER request does the same thing as a REGISTER + 
> X * SUBSCRIBE requests.  But- In the above draft, the SIP 
> nodes are all in the core network anyway, so this saving is 
> surely less valuable?
> 
> Now, in the 3GPP situation where we send SIP messages across 
> the radio interface, there is a strong requirement to save 
> radio bandwidth. Additionally, we also use the 
> SUBSCRIBE/NOTIFY procedures for events other than presence, 
> so any kind of implicit subscription is attractive...

Perhaps I'm confused about something, but as I recall, the things in IMS
being subscibed to via SUBSCRIBE are not served from the registrar that
services the REGISTER request. In other words, the SUBSCRIBEs don't go
to the same destinations as do the REGISTERs, so combining them doesn't
seem to make a lot of sense in any case. We should have called REGISTER
something like "SETCONTACT" -- it would have avoided a lot of this
discussion.

It would seem far more effective to use a server process that aggregates
notifications and subscriptions, as is done in the "presencelist" work.
In this model one subscribes to a list served by a server, then that
server subscribes to each element of the list, aggregates state, and
filters and returns appropriate notifications to the subscriber thereby
reducing over-the-air traffic tremendously. This effectively replaces
many SUBSCRIBEs with one SUBSCRIBs, and may replace many NOTIFYs with
fewer NOTIFYs, depending on how thoseare handled.
 
> But isn't the problem with implicit subscription the fact 
> that there is no call-id for the NOTIFY request to use?  Is 
> there no way around this?

That's one problem. There are also issues with knowing how to filter
notifications and how to negotiate whether implicit subscription is
supported and lots of other things. We had not finished enumerating the
issues before deciding implicit subscriptions were just dangerous.

--
Dean
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "RANJIT" <[email-masked]>
Date: Fri, 11 Oct 2002 09:20:25 +0530

Hi
   I think the 3GPP's document on Internet Multimedia SubSystem already
addresses this topic of SIP aware mobile nodes. There the Registrar is
S-CSCF.

so here each mobile node registers to theS-CSCF in its Home Network.

so how is this draft from the 3GPP specification?

Ranjit :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Idnani
Ajaykumar-AIDNANI1
Sent: Friday, October 11, 2002 12:43 AM
To: [email-masked]; Upp Steve-CSU001; Hallin Tom-ATH033
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt

All,

Thanks and Regards
- Ajay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Oct 2002 03:19:04 -0400

First off, the general tact we take here is to first generate 
requirements when you want the sip group to help solve a problem for 
you. The requirements work is done in sipping if it is deemed an 
interesting problem, and then sip develops a solution.

Clearly the requirements are not well spelled out so discussion of a 
solution is moot.

A note inline.

> UA. It depends on the core network to maintain the registrations correctly

Well, this is the basic requirement you seem to have. The old 
registration needs to be deleted.

There are many ways to do this with existing sip. I have already 
proposed one, where the new proxy UA de-registers, and it can do this 
because of defined conventions for constructing the URI.

Another way to do this is to have the old proxy-UA de-register. You have 
proposed a new mechanism for this, to allow the old proxy-UA to know 
about the new registration so it knows when it can de-register the old. 
I, and others, have pointed out the issues with the solution you have 
proposed.

However, we already have a protocol for this:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-reg-00.txt

although it is an individual draft at the moment, it will be a working 
group item. This will allow the old proxy UA to subscribe to the 
registrar and learn of the new registration, so it can unregister the 
old one. Therefore I believe it meets your requirements.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com