Subject: [Simple] Identity of resource in SIP event notification

From: Ngoc Son <[email-masked]>
Date: Wed, 9 Jun 2010 10:44:27 +0700

Hi everybody,

I have one confusing thing when study about event notification using SIP,
that is identification of resource which is being subscribed. Suppose that
SUBSCRIBEs from Alice (sip:[email-masked] <[email-masked]>) are
sent to Presence Server (sip:ps.example.com) to subscribe presence
information of Bob (sip:[email-masked] <[email-masked]>)

+>    RFC 3265, section 3.1.2 state that:
"

Identification of events is provided by three pieces of information:
Request URI, Event Type, and (optionally) message body.

The Request URI of a SUBSCRIBE request, most importantly, contains
   enough information to route the request to the appropriate entity per
   the request routing procedures outlined in SIP [1
<http://tools.ietf.org/html/rfc3265#ref-1>].  It also contains
   enough information to identify the resource for which event
   notification is desired, but not necessarily enough information to
   uniquely identify the nature of the event

"
It means that Request-URI is used as identification of resource. First
SUBSCRIBE from Alice has Request-URI is
sip:[email-masked]<[email-masked]>,
which is correct to indicate resource Bob. But from second SUBSCRIBE,
Request-URI will be URI of Presence Server (sip:ps.example.com), because
after receiving response and NOTIFY from PS, Alice's UA will updates Remote
target which is indicated in Contact header of NOTIFY from Presence Server.
So, is it correctly identification of resource? And why don't we use To
header as identification of resource?

+>    In addition, in RFC 4660 about functional description of filtering,
section 5.2.1:
"

The subscriber may have chosen to leave the URI in the filter
   undefined.  If the URI is not defined within the filter, the filter
   applies to the resource identified in the Request-URI.

   Similarly, the subscriber may have chosen to include a URI in the
   filter.  In this case, the filter applies to all notifications sent
   with content associated with the resource with that URI for this
   subscription.  If the Request-URI and the URI in the filter do not
   match, the filter may be ignored or rejected.

"
So, if second SUBSCRIBE from Alice contain filter which has filter-URI is
URI of Bob, request-URI (sip:ps.example.com) and filter-URI (
sip:[email-masked] <[email-masked]>) do not match and filter may be
ignored.
If this SUBSCRIBE contain filter which doesn't has filter-URI, this filter
will be used for resource identified in Request-URI (sip:ps.example.com). It
is not correct because this filter is for presence info of Bob.
So, again, why don't we use To header as identification of resource in SIP
event notification mechanism?

Thanks,

-- 
Regards!
DinhNgocSon
Email: [email-masked]
Developer at Xener Systems

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jun 2010 09:18:14 -0400

inline

Ngoc Son wrote:
> Hi everybody,
> 
> I have one confusing thing when study about event notification using 
> SIP, that is identification of resource which is being subscribed. 
> Suppose that SUBSCRIBEs from Alice (sip:[email-masked] 
> <mailto:[email-masked]>) are sent to Presence Server 
> (sip:ps.example.com <http://ps.example.com>) to subscribe presence 
> information of Bob (sip:[email-masked] <mailto:[email-masked]>)
> 
>    the request routing procedures outlined in SIP [1 <http://tools.ietf.org/html/rfc3265#ref-1>].  It also contains
> 
> SUBSCRIBE from Alice has Request-URI is sip:[email-masked] 
> <mailto:[email-masked]>, which is correct to indicate resource 
> Bob.

yes.

> But from second SUBSCRIBE, Request-URI will be URI of Presence 
> Server (sip:ps.example.com <http://ps.example.com>), because after 
> receiving response and NOTIFY from PS, Alice's UA will updates Remote 

By "second subscribe" I guess you mean an in-dialog refresh of the 
subscription, right?

This will use whatever contact URI has been provided. It is the 
responsibility of the server to ensure that in-dialog requests are 
associated with the same resource as the original subscription. If 
necessary, it should put an identification of the resource in the 
contact URI. If it hasn't done so, then presumably there is no ambiguity 
or else it has some other way to decide.

> So, is it correctly identification of resource? And why don't we 
> use To header as identification of resource?

Generally the To URI isn't used for anything - its a historical 
artifact. In the case of INVITE, it won't work for identifying the 
target once a call has been forwarded. The same principle holds for 
SUBSCRIBE, though its perhaps less common for a presence subscription to 
be forwarded.

> +>    In addition, in RFC 4660 about functional description of 
> filtering, section 5.2.1:
> "
> 
> So, if second SUBSCRIBE from Alice contain filter which has filter-URI 
> is URI of Bob, request-URI (sip:ps.example.com <http://ps.example.com>) 
> and filter-URI (sip:[email-masked] <mailto:[email-masked]>) do 
> not match and filter may be ignored.

The initial subscribe identifies the resource/resources to be subscribed 
to. IMO all the filter can do is remove things from consideration. 
Normally the subscribe will identify only a single resource, in which 
case filtering the URI can only be a no-op or else reduce the 
subscription to nothing. However sometimes the target of the initial 
subscribe identifies a number of URIs. In 3gpp this can happen because 
an AOR can have other associated AORs, and subscribing to one is 
considered to imply subscribing to all. Another way is to subscribe to a 
resource-list, which identifies a number of URIs. In those cases 
filtering by URI would have actual utility.

	Thanks,
	Paul

> If this SUBSCRIBE contain filter which doesn't has filter-URI, this 
> filter will be used for resource identified in Request-URI 
> (sip:ps.example.com <http://ps.example.com>). It is not correct because 
> this filter is for presence info of Bob.
> So, again, why don't we use To header as identification of resource in 
> SIP event notification mechanism?
> 
> Thanks,
>  
> -- 
> Regards!
> DinhNgocSon
> Email: [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 10 Jun 2010 15:49:04 +0200

2010/6/9 Paul Kyzivat <[email-masked]>:
> necessary, it should put an identification of the resource in the contact
> URI. If it hasn't done so, then presumably there is no ambiguity or else it
> has some other way to decide.

The subscription is a dialog and the presence server can be aware of
such dialog (by keeping a subscription dialogs list taking the
call-id, from/to tags) so IMHO there is no need for a special Contact
URI param or any other kind of identifier.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>