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

From: Adam Roach <[email-masked]>
Date: Thu, 3 Oct 2002 12:04:18 -0500

I have a several comments on the draft "SIP Combined Registration
and Subscription".

General Priciple:
-----------------

1) As a working group, we long ago reached the conclusion that
   combining multiple operations into a single request is a
   really bad idea, and have worked hard to avoid it. This is
   why, for example, uploading of CPL scripts in REGISTER messages
   has been depricated. Among other problems, it becomes
   impossible to describe what failed in partial-failure scenarios.

2) Another principle we have embraced is that we will design the
   tools for creating powerful services in such a way that they
   work as independantly of each other as possible. This is often
   stated as selecting generality over efficiency. This is, for
   example, why we have selected to standardize the general
   capability described by the "REFER" draft instead of the
   onetime competing proposal for a "TRANSFER" verb.

Process:
--------

Currently, the way of getting work items onto the SIP working
group agenda is to formulate a group of requirement in the
SIPPING working group, and then develop the acutal mechanism
in the SIP working group.

Specific Mechanism:
-------------------

1) It is not clear how the proposed mechanism solves the problem
   described in the introduction. However,
   the described mechanism doesn't solve this problem any better
   than a standard REGISTER and SUBSCRIBE message sent
   separately. Has there been some sort of major cut-and-paste
   error, or did I miss the linkage?

2) The draft proposes:

      This memo also proposes that a NOTIFY SHOULD not be sent      
      immediately on receiving the REGISTER, since the proxy UA would      
      have all the required information on presence, or would get it in
      the 200 OK response. So a NOTIFY SHOULD only be sent when the      
      presence information changes like when the old contact is removed,

      or a new contact address is added,  the old contact SHOULD to be      
      informed of this change.

   Unfortunately, this isn't a workable solution. The immediate NOTIFY
   was placed in RFC3265 quite purposefully to solve a wide variety
   of problems. Forking of requests is the most obvious, but it serves
   other important purposes, such as communicating the state of the
   subscription itself (in addition to the resource), and providing
   a final negotiated expiration time.

3) In many, if not most, cases, the subscriber will want information
   about more than one resource (that is, he will want to subscribe
   to more than one resouce, and often, more than one type of event
   package). It is not clear how the proposed mechanism could
   handle this case.

4) One of the more important bits of information when subscribing
   for presence is the identity contained in the Request-URI.
   However, for REGISTER messages, this Request-URI is required
   to contain the identity of the registrar. It is highly
   doubtful that the intention is to subscribe to the presence
   of the registrar. So, from the current description, it
   is not clear at all to which resource the subscription would be.

/a
_______________________________________________
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: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 14 Oct 2002 12:36:35 +0100

3GPP currently addresses this by each entity that desires knowledge of the registration status sending a SUBSCRIBE request to the registrar for the reg event package. This does result in a large number of SUBSCRIBE messages being sent in parallel to REGISTER messages, but this is certainly what will occur in the current approved release.

I understand that the object of the proposal being discussed was to reduce the number of SUBSCRIBE requests in like scenarios like the 3GPP one by creating an implicit subscription, but that does not form part of any 3GPP drafts at the moment.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: RANJIT [mailto:[email-masked]]
> Sent: 11 October 2002 04:50
> To: Idnani Ajaykumar-AIDNANI1
> Cc: Sip-Ietf
> Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
> 
> 
> 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,
> 
> 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