Subject: [Simple] Request URI in NOTIFY

From: "Ngo, Dai (c)" <[email-masked]>
Date: Thu, 26 Jul 2001 14:29:00 +0000

Adam et al,

In section 5.2.2 of the SIP-Specific Event Notification
(draft-ietf-sip-events-00.txt) it states that "The Request URI of a NOTIFY
request contains enough information to route the request to the party which
is subscribed to receive notifications. It is derived from the "Contact"
header present in the corresponding SUBSCRIBE request.". I think this
statement is only true in general, except in the following case:

In the case of the Presentity, who is being subscribed to be watched, has
registered with a contact specified with a Methods=NOTIFY, the address
location specified with a Methods=NOTIFY in the Contact header should be
used as the Request URI instead.

Have I missed something?

Please clarify. Thanks.

-- Dai

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Jul 2001 15:22:45 -0400

-----Original Message-----
>From: Ngo, Dai (c) [mailto:[email-masked]]
>Sent: Thursday, July 26, 2001 10:29 AM
>To: [email-masked]
>Subject: [Simple] Request URI in NOTIFY
>
>
>Adam et al, 
>
>In section 5.2.2 of the SIP-Specific Event Notification (draft-ietf-sip-
>events-00.txt) it states that "The Request URI of a NOTIFY request contains

>enough information to route the request to the party which is subscribed to

>receive notifications. It is derived from the "Contact" header present in
the 
>corresponding SUBSCRIBE request.". I think this statement is only true in 
>general, except in the following case:

>location specified with a Methods=NOTIFY in the Contact header should be
used 
>as the Request URI instead.

You've got things in the wrong direction. If A subscribes to B, B is the
presentity. The NOTIFY is sent to A. That NOTIFY has to have a request URI
which routes back to A. To do that, we have agreed, I believe, to have
SUBSCRIBE use INVITE semantics for record-routing. THis means that if no
proxies record-route, the NOTIFY to A is sent to the Contact that A provided
in their SUBSCRIBE. This has nothing to do with any registrations of any
sort that the presentity has made.

-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

---

From: "Ngo, Dai (c)" <[email-masked]>
Date: Thu, 26 Jul 2001 19:33:32 +0000

Jonathan,

You're right that I have made an error in stating the question. Here is the
scenario:

A (watcher) subscribes to watch B (the Presentity)
There is a contact header in the SUBSCRIBE from A: [email-masked].
A also has previously registered with a contact, which specified
Methods=NOTIFY, i.e. [email-masked];Methods=NOTIFY

B now needs to send a NOTIFY to A.

Which address is to be specified in the Request URI for the NOTIFY: The
address in the Contact header of the SUBSCRIBE, or the address with
Methods=NOTIFY in the registrar database?

Thanks.

Dai

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 2:23 PM
To: Ngo, Dai (c); [email-masked]
Subject: RE: [Simple] Request URI in NOTIFY

-----Original Message-----

the 

used 

-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
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Ngo, Dai (c)" <[email-masked]>
Date: Thu, 26 Jul 2001 19:54:10 +0000

Jonathan,

A and B both use the same Presence Server/Registrar therefore the PS knows
of A and B. Since B changes status the PS needs to send NOTIFY to A.

Maybe I'm still confusing about the purpose of using "Methods=NOTIFY". Could
you please summarize it then?

-- Dai

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 2:46 PM
To: Ngo, Dai (c); Jonathan Rosenberg; [email-masked]
Subject: RE: [Simple] Request URI in NOTIFY

-----Original Message-----
From: Ngo, Dai (c) [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 3:34 PM
To: 'Jonathan Rosenberg'; [email-masked]
Subject: RE: [Simple] Request URI in NOTIFY

>Methods=NOTIFY in the registrar database?

How would B know whats in the registration database for A, who is some
client in some provider on the other side of the planet? We use standard SIP
record-routing techniques. If no proxies record-route, the request URI in
the NOTIFY is from the Contact in the SUBSCRIBE. If proxies record-route,
the request URI in the NOTIFY is the top record-route entry (ie, that of the
proxy closest to B).

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 29 Jul 2001 23:38:08 -0400

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 4:11 PM
> To: Jonathan Rosenberg
> Cc: 'Ngo, Dai (c)'; [email-masked]
> Subject: Re: [Simple] Request URI in NOTIFY
> 
> > 
> What if the contact header in the SUBSCRIBE that A sent 
> actually points 
> to a proxy/registrar, which A has registered to point to 
> somewhere else?
> 
> For example, A sends a register to the proxy/registrar P with 
> a From: of 
> A@P and a Contact: <sip:A&A>;methods=NOTIFY. A then sends a 
> SUBSCRIBE to 
> B with a Contact: sip:A@P. It would seem to me that the 
> NOTIFY would go 
> via A@P, and get proxied or redirected to A&A (if the absense of a 
> record-route, of course.)

Things get confused, in general, when a UA puts an address in the Contact
which doesn't actually point to itself. I can work in some cases, but it
needs coordinated agreement amongst several entities. Specifically, the
proxy that the SUBSCRIBE went through initially might very well be the same
that the user registers with. In that case, it if record-routes the
SUBSCRIBE, the NOTIFY will loop through this proxy, and thus be rejected.
So, if the UA places an address that resolves to a proxy inside of Contact,
that proxy cannot record-route. Also, any record-routes in the NOTIFY would
need to be ignored by the UA (this is the case right now for presence, but
not necessarily all event packages).

Why bother, though? If the subscriber moves, re-subscribe with an updated
local contact. Thats how it works with INVITE, and SUBSCRIBE is supposed to
mirror INVITE behavior in this regard.

-Jonathan R.

---