[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt
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: drage@lucent.com
> -----Original Message-----
> From: RANJIT [mailto:ranjit.avasarala@bplmail.com]
> 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: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf
> Of Idnani
> Ajaykumar-AIDNANI1
> Sent: Friday, October 11, 2002 12:43 AM
> To: sip@ietf.org; 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:dean.willis@softarmor.com]
> Sent: Monday, October 07, 2002 3:15 PM
> To: duncan.mills@vf.vodafone.co.uk; adam@dynamicsoft.com;
> sip@ietf.org;
> 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip