Subject: [Sip] configuration NOTIFY in example 9.1 of outbound i-d

From: [email-masked] (Juha Heinanen)
Date: Mon, 29 Sep 2008 17:47:40 +0300

how can Bob's UA in example 9.1 of outbound i-d receive the NOTIFY
request sent by EP1 if Bob's UA is behind firewall that does not allow
EP1 to setup a new TCP connection to Bob's UA?

is it described somewhere that in this kind of situation EP1 has to
re-use the SUBSCRIBE TCP connection and that Bob's UA should not tear it
down so that it can be re-used?

-- juha
_______________________________________________
Sip mailing list  https://www.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: "Francois Audet" <[email-masked]>
Date: Mon, 29 Sep 2008 11:32:26 -0500

Yes, it's there.

SUBSCRIBE creates a dialog which is used for the NOTIFY. So it's no
different than INVITE-created mid-dialog requests.

The specific text covering this is located here:

Section 4.3 states (UA procedures):
   If the UAC is sending a dialog-forming request, and wants all
   subsequent requests in the dialog to arrive over the same flow, the
   UAC adds an 'ob' parameter to its Contact header.  Typically this is
   desirable, but it is not necessary for example if the Contact is a
   GRUU [I-D.ietf-sip-gruu].  The flow used for the request is typically
   the same flow the UA registered over, but it could be a new flow, for
   example the initial subcription dialog for the configuration
   framework [I-D.ietf-sipping-config-framework] needs to exist before
   registration.

Then, section 5.3.2 (proxy procedures):
   For mid-dialog requests to work with outbound UAs, the requests need
   to be forwarded over some valid flow to the appropriate UA instance.
   If the Edge Proxy receives an outgoing dialog-forming request, the
   Edge Proxy can use the presence of the ob URI parameter in the UAC's
   Contact URI (or topmost Route header field) to determine if the Edge
   Proxy needs to assist in mid-dialog request routing.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juha Heinanen
> Sent: Monday, September 29, 2008 07:48
> To: [email-masked]
> Subject: [Sip] configuration NOTIFY in example 9.1 of outbound i-d
> 
> how can Bob's UA in example 9.1 of outbound i-d receive the 
> NOTIFY request sent by EP1 if Bob's UA is behind firewall 
> that does not allow
> is it described somewhere that in this kind of situation EP1 
> has to re-use the SUBSCRIBE TCP connection and that Bob's UA 
> should not tear it down so that it can be re-used?
> 
> -- juha
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 29 Sep 2008 20:01:10 +0300

Francois Audet writes:

 >    GRUU [I-D.ietf-sip-gruu].  

if contact is gruu, does it mean that 'ob' param is implicitly included?

 >    Proxy needs to assist in mid-dialog request routing.

if there is no edge proxy, i.e., UA sends subscribe directly to a
presence server, then does this draft not apply and there is no
mechanism for the UA to indicate that it wants subscribe tcp connection
to be reused by presence server for notifies?

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 29 Sep 2008 13:04:31 -0500

> if contact is gruu, does it mean that 'ob' param is 

I am not sure why this is worded like this. I was thinking that using 
a GRUU as a contact in a dialog-forming request would mandate that
requests sent to that Contact would be sent using the same flow, but
I see no such rule in draft-ietf-sip-gruu.

Cullen/Rohan/Jonathan?

> if there is no edge proxy, i.e., UA sends subscribe directly 
> to a presence server, then does this draft not apply and 
> there is no mechanism for the UA to indicate that it wants 
> subscribe tcp connection to be reused by presence server for notifies?

Maybe I'm misunderstanding the question, but this draft relies on an
outbound proxy. So, in this specific example, the configuration server
needs to have outbound proxy behavior otherwise you are correct, this
NOTIFY won't be delivered. It's kind of like the co-located registrar
and proxy described explicitly in the document, but for co-located
Config server and proxy.
_______________________________________________
Sip mailing list  https://www.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: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Sep 2008 16:26:17 -0400

> I see no such rule in draft-ietf-sip-gruu.

Gruu isn't dependent on outbound.

	Thanks,
	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 30 Sep 2008 11:34:54 +0300

> I see no such rule in draft-ietf-sip-gruu.

based on cullen's reply, text

needs to be changed, because no matter gruu or not, ob needs to be
included if UA wants the same flow to be used for requests of the dialog
from the proxy.

 > and proxy described explicitly in the document, but for co-located

outbound behavior is also needed in case of regular presence server.
that is why i don't quite understand is why is this "usage of the same
flow for in-dialog requests" feature tied to outbound proxy.  why is it
not useful to have a generic capability for UAC to tell to the next hop
(a proxy or UAS) in its dialog initiating request that "please use this
flow for subsequent requests of this dialog"?

-- juha