Subject: [Sip] Ensuring in-dialog stuff works with outbound

From: Byron Campen <[email-masked]>
Date: Thu, 5 Apr 2007 13:59:33 -0500

I've been tuning a server implementation of outbound recently, and  
I've come upon a bit of a conundrum. Say we have an endpoint using  
outbound with an edge-proxy. Everything is set up as specified in the  
draft. This endpoint then sends a dialog-forming request. The edge  
proxy has to be able to ensure that in-dialog traffic coming from the  
other direction goes over the same outbound flow, by record-routing  
with a flow token. However, in the non-outbound case, is it downright  
_wrong_ for the edge proxy to record-route with a flow-token, because  
doing so breaks target-refreshes. Unfortunately, the edge-proxy is  
keeping no flow state, and has no clue if this dialog-forming request  
came over an outbound flow or not.

I see two choices for fixing this, please pipe up if you see  
additional options:

1. We require the endpoint to specify whether it wants the outbound  
treatment on each outgoing request, either by including some  
recognizable outbound goo in the request, or by preloading a Route  
header with a flow-token to the edge proxy (using something like  
Service-Route maybe, although interactions between Service-Route and  
Path might be a little weird).

2. We require proxies to store information on which connections are  
outbound flows, and which are not (this would make the whole exercise  
of stateless flow-tokens moot).

Best regards,
Byron Campen

_______________________________________________
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

---

From: "Kevin Johns" <[email-masked]>
Date: Mon, 16 Apr 2007 14:32:18 -0600

Byron,

Just saw this email and have not seen any responses as of yet...

I am not sure I fully follow your issue, are you trying to figure out
how to distinguish between non-outbound enabled UAs and outbound enabled
UAs within the same edge proxy? It also appears you want to be able to
determine this so you know when to insert a flow token in a record-route
header to allow for routing of mid-dialog requests?

Is my understand correct?

Kevin

-----Original Message-----
From: Byron Campen [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 1:00 PM
To: SIP IETF
Cc: Cullen Jennings; Rohan Mahy
Subject: [Sip] Ensuring in-dialog stuff works with outbound

	I've been tuning a server implementation of outbound recently,
and I've come upon a bit of a conundrum. Say we have an endpoint using
outbound with an edge-proxy. Everything is set up as specified in the
draft. This endpoint then sends a dialog-forming request. The edge proxy
has to be able to ensure that in-dialog traffic coming from the other
direction goes over the same outbound flow, by record-routing with a
flow token. However, in the non-outbound case, is it downright _wrong_
for the edge proxy to record-route with a flow-token, because doing so
breaks target-refreshes. Unfortunately, the edge-proxy is keeping no
flow state, and has no clue if this dialog-forming request came over an
outbound flow or not.

I see two choices for fixing this, please pipe up if you see additional
options:

2. We require proxies to store information on which connections are
outbound flows, and which are not (this would make the whole exercise of
stateless flow-tokens moot).

Best regards,
Byron Campen

---

From: Byron Campen <[email-masked]>
Date: Fri, 20 Apr 2007 10:07:43 -0500

Yeah, this is essentially what I was asking. I ended up having a  
conversation with Rohan, and the takeaway was that the outbound- 
enabled UA needed to remember the edge-proxy's Path header, and pre- 
load it as a Route header in outgoing requests over that flow. The  
edge-proxy, when seeing this, would then Record-Route with the same  
(after determining whether this flow-token referred to the source, or  
the destination, it would Record-Route in such a way to keep it from  
getting confused over the direction the flow-token was pointing,  
probably by using a double record-route.)

Best regards,
Byron Campen

> proxy
> additional

---

From: "Kevin Johns" <[email-masked]>
Date: Fri, 20 Apr 2007 10:33:53 -0600

Byron,

This was along the lines of what I was thinking, but neither outbound
nor RFC 3327 state this.

Kevin 

-----Original Message-----
From: Byron Campen [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 9:08 AM
To: Kevin Johns
Cc: SIP IETF; Cullen Jennings; Rohan Mahy
Subject: Re: [Sip] Ensuring in-dialog stuff works with outbound

	Yeah, this is essentially what I was asking. I ended up having a
conversation with Rohan, and the takeaway was that the outbound- enabled
UA needed to remember the edge-proxy's Path header, and pre- load it as
a Route header in outgoing requests over that flow. The edge-proxy, when
seeing this, would then Record-Route with the same (after determining
whether this flow-token referred to the source, or the destination, it
would Record-Route in such a way to keep it from getting confused over
the direction the flow-token was pointing, probably by using a double
record-route.)

Best regards,
Byron Campen

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 22 Apr 2007 20:02:13 -0700

Hi Byron,

Double record-route is not needed.  A simple Record-Route with a flow  
token in the userpart is sufficient from an implementation  
perspective, as long as the edge proxy can use the source of a  
request to determine if a request routed through a particular flow  
token is "coming" or "going".

Also, the draft just says that each edge proxy just needs to do  
whatever is necessary to make sure that subsequent requests get back  
to the same instance.  This leaves the door open for 1) extra edge  
proxies between the first edge proxy and the authoritative proxy to  
step out of the path, 2) edge proxies that record route with a more,  
3) incorporating per call state blobs, (and possibly other things I  
haven't thought of).

thanks,
-rohan

On Apr 20, 2007, at 9:33 AM, Kevin Johns wrote:
> enabled