Subject: [Sip] I-D ACTION:draft-idnani-sip-comb-reg-subscr-00.txt

From: [email-masked]
Date: Thu, 03 Oct 2002 07:11:21 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SIP Combined Registration and Subscription
	Author(s)	: A. Idnani, T. Hallin, S. Upp
	Filename	: draft-idnani-sip-comb-reg-subscr-00.txt
	Pages		: 10
	Date		: 2002-10-2
	
This memo proposes that the headers of REGISTER and SUBSCRIBE be    
combined, so that a REGISTER message can also be treated as an    
implicit subscription for events. This memo identifies the need for    
doing this, and then explains how combining the Registration and 
Subscription solves the problem. It also presents an example flow    
demonstrating the use of this combined registration and subscription.   
The headers being combined will be made optional in the REGISTER and   
SUBSCRIBE messages - depending on where they do not appear as of    
today - so that backward compatibility is maintained.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-idnani-sip-comb-reg-subscr-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-idnani-sip-comb-reg-subscr-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-idnani-sip-comb-reg-subscr-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Chris Martin <[email-masked]>
Date: Fri, 04 Oct 2002 21:39:50 -0500

You wrote in the draft that:
  "When the MS moves to another SIP gateway, the   
   new gateway would also send a SIP REGISTER to the SIP Registrar,
and    
   record itself as being in the path to the MS. However the data at
the   
   old SIP gateway has not been updated, and the old SIP gateway is
not    
   aware of the fact that the MS has moved to a new SIP gateway."

Couldnt the policy on the SIP registrar be set up to recognize only the
last registration recieved? 

I would think that the SIP registrar and location server would maintain
the current location of the MS throughout its travels through the mobile
network. The Proxy UA's (SIP gateway) should merely perform their
function and merely time out the registration based on the Expires
value.

Section 2 describes the presence mechanism call flow, and I have some
questions here:

   "In the above diagram a watcher (some UA) subscribes for the
presence    
   data of PUA with the presence server. The Presence server
immediately   
   replies back with the current presence data of the PUA in the
NOTIFY    
   message.

   At a later time, when the PUA updates its presence data by some
means   
   (could use SIP REGISTER message), the presence server again
notifies    
   the watcher, with the new presence data."

First the watcher, is it a remote device based on the SIP side of the
mobile network talking inbound to the MS? Or is it an MS talking
outbound to the SIP network via the Proxy UA? (I think that section 4
answers my question about the direction as it describes the presence
server..but just in cas I leave this question here).

Also, I didnt see any messages to the PUA from the presence server, only
a notify message.

In section 3, I dont see why the SIP registrar would need to do anything
but let the Proxy UA expire the original registration (if it even needs
to maintain this information at all), could you explain that part of
scenario for me, or point me to more documentation on the mobile aspect
of this?
 
I think I will stop my questions here...

Thanks in advance, 
Chris
_______________________________________________
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