Subject: Re: [dispatch] SIP outbound and in-dialog requests

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 2 May 2013 09:31:50 +0200

30 apr 2013 kl. 11:41 skrev Iñaki Baz Castillo <[email-masked]>:

> 2013/4/30 Olle E. Johansson <[email-masked]>:
>> Is this the only response that is out there? To break RFC 3261 and apply a
>> route change to an existing dialog?
> 
> Is not cool enough? :)
> 
> Right, RFC 5627 should say "something" about it.
> 

The question is what to do here.

And how much the draft for SIP over WebSockets rely on Outbound. Do we need to solve this issue before moving ahead with that draft?

/O

---

From: José Luis Millán <[email-masked]>
Date: Thu, 2 May 2013 12:02:40 +0200

Hi all,

2013/5/2 Olle E. Johansson <[email-masked]>

> And how much the draft for SIP over WebSockets rely on Outbound. Do we
> need to solve this issue before moving ahead with that draft?
>

Extracted from RFC 5626, chapter 7:

```

The proxy uses the next-hop target of the message and the value of
   any stored Path header field vector in the registration binding to
   decide how to forward and populate the Route header in the request.
   If the proxy is co-located with the registrar and stored information
   about the flow to the UA that created the binding, then the proxy
   MUST send the request over the same 'logical flow' saved with the
   binding, since that flow is known to deliver data to the specific
   target UA instance's network flow that was saved with the binding.

```

Which means that a newly created registration binding (following the
procedures defined in chapter 4.4) will contain the PATH route with the new
and valid flow token, and such 'logical flow' MUST be used instead of that
in the Route header(s). Hence, the Route header(s) pointing to the old and
deprecated 'logical flow' is replaced with the new one gathered from the
registration after the flow failure.

I don't feel like this could affect in any way the use of Outbound for any
transport.

Regards.

>
> /O
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

-- 
José Luis Millán

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 2 May 2013 14:41:25 -0400 (EDT)

> From: "Olle E. Johansson" <[email-masked]>
> 
> Is this the only response that is out there? To break RFC 3261 and
> apply a route change to an existing dialog?
> Or follow RFC 3261 and let the dialog fail?

I've worked on an implementation of SIP Outbound (that wasn't
completed), and my memory is that the problem you describe is not
solved in the RFCs.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 2 May 2013 14:42:02 -0400 (EDT)

> From: JosC) Luis MillC!n <[email-masked]>
> 

It appears to me that this procedure is to be carried out only in the
circumstances described in the paragraph at the beginning of section
7:

   When a proxy uses the location service to look up a registration
   binding and then proxies a request to a particular contact, it
   selects a contact to use normally, with a few additional rules:

That is, it only applies when the proxy is looking up a registration
binding == the next-hop address is the AOR.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 2 May 2013 20:49:31 +0200

When GRUU is used in the INVITE/200 Contact, the proxy+registrar should
also perform GRUU based registration lookup so IMHO the procedure below
also applies, and it means thar the route set could be changed during a
dialog if the peer re-registered again after a connection break (so its
connection gets a new Outboud flow token id). This is the issue being
discussed here: the route set is changed since within the dialog the
registrar gets the new Path containing a new flow token and thus the Route
it adds is different than the original route set.

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 2 May 2013 21:15:27 -0400 (EDT)

> From: IC1aki Baz Castillo <[email-masked]>
> 

Ah, OK, now I recall.  The new flow will be used *if* the UA uses its
GRUU as its Contact.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 13:22:58 +0000

Hi,

Perhaps this could work in some cases, but as Inaki said: it breaks RFC 3261, and RFC 5626. Only for new dialogs can a new flow (read: route set) be selected.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 3. toukokuuta 2013 4:15
To: IC1aki Baz Castillo
Cc: [email-masked]
Subject: Re: [dispatch] SIP outbound and in-dialog requests

> When GRUU is used in the INVITE/200 Contact, the proxy+registrar 
> should also perform GRUU based registration lookup so IMHO the 
> procedure below also applies, and it means thar the route set could be 
> changed during a dialog if the peer re-registered again after a 
> connection break (so its connection gets a new Outboud flow token id). 
> This is the issue being discussed here: the route set is changed since 
> within the dialog the registrar gets the new Path containing a new 
> flow token and thus the Route it adds is different than the original route set.

Ah, OK, now I recall.  The new flow will be used *if* the UA uses its GRUU as its Contact.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 3 May 2013 15:53:52 +0200

> Perhaps this could work in some cases, but as Inaki said: it breaks RFC 3261, and RFC 5626. Only for new dialogs can a new flow (read: route set) be selected.

So we loose the capability of receiving an in-dialog request once our
NATed TCP connection has been disconnected (regardless we have
reconnected and re-registered again).

That is really really sad.

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 17:42:24 +0000

Hi,

> That is really really sad.

C'est la SIP :)

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 3 May 2013 14:01:38 -0400 (EDT)

> From: Christer Holmberg <[email-masked]>
> 
> Perhaps this could work in some cases, but as Inaki said: it breaks
> RFC 3261, and RFC 5626. Only for new dialogs can a new flow (read:
> route set) be selected.

The trouble seems to be that when the dialog is established, the
particular flow from the proxy to the UA is Record-Routed.  If the UA
uses a GRUU as its Contact URI, a Record-Route isn't needed to record
the particular route, since the GRUU can be resolved when each
in-dialog request is processed.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 19:39:41 +0000

Hi,

> in-dialog request is processed.

The in-dialog requests need to traverse the edge proxy, so the edge proxy needs to Record-Route.

Regards,

Christer

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 06 May 2013 09:33:46 +0200

It seems that technically it would be possible to change the in-dialog 
route-set, but all nodes need to be prepared for that and switch to the 
new route-set, and this also implies that the Path-vector is identical 
to the INVITE-route-set (which may not be the case in big setups). 
Further, you are always talking about registrar->user agent requests - 
but of course there may be user agent -> registrar requests that may 
swap flows.

regards
Klaus

On 02.05.2013 20:49, Iñaki Baz Castillo wrote:
> registrar gets the new Path containing a new flow token and thus the
> Route it adds is different than the original route set.
>
> --
> Iñaki Baz Castillo
> <[email-masked] <mailto:[email-masked]>>
>
> El 02/05/2013 20:42, "Dale R. Worley" <[email-masked]
> <mailto:[email-masked]>> escribió:
>
>      > From: JosC) Luis MillC!n <[email-masked]
>     <mailto:[email-masked]>>
>      >
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 May 2013 08:49:25 +0000

Hi,

> It seems that technically it would be possible to change the in-dialog route-set, but all nodes need to be prepared for that 
> and switch to the new route-set, and this also implies that the Path-vector is identical to the INVITE-route-set (which may not be the case in big setups). 
> Further, you are always talking about registrar->user agent requests - but of course there may be user agent -> registrar requests that may swap flows.

It is of course possible to transfer/replace the dialog, and hence create a new route set (as part of the new dialog), but if you want to do that without affecting the other endpoint you of course need B2BUA functionality in the network.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 6 May 2013 10:55:00 +0200

> It is of course possible to transfer/replace the dialog, and hence create a new route set (as part of the new dialog), but if you want to do that without affecting the other endpoint you of course…

It seems to me that Outbound only handles dialog-forming requests, but currently can't handle survival of a dialog between
two or more flows between the UA and the edge proxy. That's something that needs to be fixed.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 6 May 2013 15:44:06 +0200

> two or more flows between the UA and the edge proxy. That's something that needs to be fixed.

Right, let me please simplify this issue with an example:

Alice --- REGISTRAR --- EDGE --- Bob

- Bob registers with GRUU through EDGE Proxy which performs Path.

- Alice calls Bob.

- Bob disconnectes, connects again and sends a new REGISTER.

- EDGE sets a new outbound flow token in the Path header. The new
binding (with new Path) replaces the previous one in the location DB.

- Alice sends BYE to Bob. The BYE arrives to REGISTRAR which performs
lookup for the binding of the GRUU URI of the BYE, and retrieves the
new binding of Bob, so adds such a Route to the request, which now
looks as follows:

  BYE sip:[email-masked];gr=qweasdzxc
  Route: <sip:REGISTRAR> (removed by REGISTRAR)
  Route: <sip:EDGE-BOB-NEW-PATH>
  Route: <sip:EDGE-BOB-OLD-PATH> (removed by REGSISTRAR OR NOT ????)

- Of course here RFC 3261 is violated since the route set is changed.
However endpoints will not realize of it since EDGE would remove both
remaining Route headers before routing the request to Bob, but for
that to work, REGISTRAR should previously also remove the
EDGE-BOB-OLD-PATH Route header (otherwise EDGE Proxy would try to
route via the old closed connection).

Well, we have here a pain of Route headers added by intermediary
proxies within a dialog, which seems ugly. We need a solution:

1) Is the above allowed by RFC 5626/5627 or not?

2) How to avoid it? In case a new registration modifies the binding
(including Path header with outbound flow token), nothing prevents the
registrar to use the new binding for an in-dialog request, but it
violates RFC 3261 (route set changed).

3) Anyhow endpoints will never see the new Route set so, does this
violate 3261 or not?

4) and anyhow... the REGISTRAR (see example above) needs to remove the
Route header pointing to next step before it inserts a new one due to
the binding lookup and Path retrieval. Otherwise the request arrives
to the EDGE proxy with two Route (with Flow-Token) headers pointing to
it.

All of this is really unclear. I hope there is an answer that allows a
dialog to remain alive once the NATted TCP connection of an endpoint
is closed during the dialog. Otherwise, nobody cared about mobile
intermittent networks when RFC 5626/5627 were written?

Regards.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 6 May 2013 16:21:05 +0200

> 3) Anyhow endpoints will never see the new Route set so, does this
That's interesting. Just to quote RFC 3261 for information:

12.2 : "Requests within a dialog MAY contain Record-Route and Contact header
   fields.  However, these requests do not cause the dialog's route set
   to be modified, although they may modify the remote target URI."

"Target refresh requests only update the dialog's remote target URI,
   and not the route set formed from the Record-Route.  Updating the
   latter would introduce severe backwards compatibility problems with
   RFC 2543-compliant systems."

Section 12.2.1 Opens up for sending to alternate addresses,
without changing the route set. There's a discussion about using
a new contact header to update the IP address by using a target
refresh.

12.2.1.1 ends with " Subject to certain restrictions, they allow the request
      to be sent to an alternate address (such as a default outbound
      proxy not represented in the route set)."

If the first route header from the UA point of view is a DNS name,
the situation seems easier to handle. The DNS name resolves
to the set of edge proxys. The contact can be a gruu.

Maybe avoiding to use IP in record-route headers is a possible solution
that allows us to retarget.

Any thoughts?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 6 May 2013 17:15:39 +0200

>    RFC 2543-compliant systems."

I don't care RFC 2543 old devices, even less taking into account that
they will never see a modified Route set (as explained in my previous
mail).

> that allows us to retarget.

Honestly I don't think that is the problem cause of the problem to
solve. Here the real problem is that an endpoint can re-register via
another TCP connection and also through another EDGE proxy and thus,
the Path header arriving to the registrar will change (both the
Outbound flow token identifer and the EDGE address).

Later, when the registrar does lookup for the GRUU request URI of an
indialog request, it will retrieve a different path so route set is
modified (but endpoints will not realize of it).

The main and primary question is: Can a registrar perform GRUU
registration lookup for an *in-dialog* request or not? and if so,
should it add a Route header with the value of the Path header
associated to the retrieved binding? (note that such a Route was
already present in the in-dialog request due to the already formed
route set, so we have a duplicated Route header, or the old value +
the new one).

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

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 6 May 2013 18:00:58 -0400 (EDT)

> proxy needs to Record-Route.

In-dialog requests need to traverse *an* edge proxy, but (in order to
arrive), they needn't always traverse the *same* edge proxy.  As long
as the final URI is a GRUU for the UA, there is enough information in
the request to allow successful routing, even if new flows are
established.  But 3261 requires the edge proxy used in the
dialog-forming request to always be in the path.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 May 2013 00:04:07 +0200

> dialog-forming request to always be in the path.

So we have a problem? or not? :)

Please let me focus on the issue described in my two previous mails:
the registrar performs GRUU for an in-dialog request so the request
gets a *NEW* Route header (which is added to the Route headers already
present in the request due to the route set).

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 08:35:01 +0000

Hi,

One of the arguments have been that the UA won't see the changed route set, as the Route headers are removed from requests sent towards the UA.

But, and I believe this was also indicated, the UA may also SEND requests - so it would need to update its own route set also.

Now, eventhough it breaks RFC 3261, it can probably be made to work in some scenarios.

However, there are other aspects that need to be considred.

1) There might be other intermediaries than the edge proxy between the UA and registrar. Some of those might be stateful.

2) There might be intermediaries that anchor the media. The media path will not change just because you switch signaling route set.

3) The UA may have negotiated the sending of keep-alives, either on the registration- or the dialog level, and there might be intermediaries that e.g. trigger session release if those keep-alives don't arrive.

Etc etc.

Regards,

Christer

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 7. toukokuuta 2013 1:04
To: Dale R. Worley
Cc: Christer Holmberg; [email-masked]
Subject: Re: [dispatch] SIP outbound and in-dialog requests

Please let me focus on the issue described in my two previous mails:
the registrar performs GRUU for an in-dialog request so the request gets a *NEW* Route header (which is added to the Route headers already present in the request due to the route set).

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 May 2013 11:20:59 +0200

> But, and I believe this was also indicated, the UA may also SEND requests - so it would need to update its own route set also.

No, it's not needed. The UA will still indicate GRUU in its Contact so
the registrar will do lookup and also "replace" the existing old Route
header with the new one retrieved from the new Path (if there was an
Edge proxy).

Anyhow, it seems that nobody wants to reply to the problem I describe.
Is it not clear? Let me re-explain it:

******************************************************
PLEASE FOLKS READ AND REPLY BELOW
******************************************************

Scenario:

---------------------------------------------------------
Alice --- REGISTRAR --- EDGE --- Bob
---------------------------------------------------------

- Bob registers with GRUU and Outbound. EDGE adds Path:

   Path: <sip:FLOW_TOKEN_1@EDGE;lr>

- Alice calls Bob. Once the call is established, the route set from
Alice is as follows:

  Route: <sip:REGISTRAR;lr>
  Route: <sip:FLOW_TOKEN_1@EDGE;lr>

- So an in-dialog INFO from Alice looks as follows:

  INFO sip:[email-masked];gr=GRUU_1
  Route: <sip:REGISTRAR;lr>
  Route: <sip:FLOW_TOKEN_1@EDGE;lr>

- When the INFO arrives to the REGISTRAR, the REGISTRAR MUST perform
GRUU lookup, RIGHT??

- So the REGISTRAR retrieves the Bob binding which includes Path above
(to be converted into Route header), but such a Route header is
ALREADY present in the INFO due to previous and common record-routing.
So the REGISTRAR:

  - Must DELETE the Route pointing to next node (EDGE).
  - And MUST add the Route retrieved from the Path.

- YES OR NOT PLEASE???

- Then the INFO arrives to EDGE as follows:

  INFO sip:bob@BOB_IP
  Route: <sip:FLOW_TOKEN_1@EDGE;lr>

- Later during the dialog, Bob is disconnected so reconnects to EDGE
and re-registers. Now a new Outbound Flow Token is generated and added
to the Path header by EDGE:

  Path: <sip:FLOW_TOKEN_2@EDGE;lr>

- Alice sends BYE to Bob:

  BYE sip:[email-masked];gr=GRUU_1
  Route: <sip:REGISTRAR;lr>
  Route: <sip:FLOW_TOKEN_1@EDGE;lr>

- The REGISTRAR does GRUU lookup and retrieves the new Path that must
be added as a new Route:

  - The REGISTRAR removes the Route pointint to EDGE:
      Route: <sip:FLOW_TOKEN_1@EDGE;lr>
  - And adds a new one based on the new Path of Bob:
      Route: <sip:FLOW_TOKEN_2@EDGE;lr>

- So the BYE arriving to EDGE is:

  BYE sip:bob@BOB_IP
  Route: <sip:FLOW_TOKEN_2@EDGE;lr>

- ...which is properly routed to Bob via the new connection. And no
need for Alice and Bob to change the dialog route set.

Ok folks, please HELP ME, I cannot describe the problem in a better
way. Do you see the ugly play with Route headers above? the REGISTRAR
must remove a Route header that points to the next node (EDGE proxy)
before REGISTRAR adds the Route mirrored from the Path !!!!

- How is supposed that a proxy can be able to remove Route headers
belonging to proxies located after it??
- Is GRUU broken?
- Can GRUU work with in-dialog request or not?

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 09:33:48 +0000

Hi,

I will look into your latest reply later, but in general: while the SIP protocol impacts of this are discussed, I think this discussion should take place on the SIPCORE list :)

Then, if there is a suggestion to start some new work, that can be brought to DISPTACH.

Regards,

Christer

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 7. toukokuuta 2013 12:21
To: [email-masked]
Cc: Dale R. Worley; Christer Holmberg; Olle E Johansson; Klaus Darilion
Subject: Re: [dispatch] SIP outbound and in-dialog requests

> But, and I believe this was also indicated, the UA may also SEND requests - so it would need to update its own route set also.

No, it's not needed. The UA will still indicate GRUU in its Contact so the registrar will do lookup and also "replace" the existing old Route header with the new one retrieved from the new Path (if there was an Edge proxy).

Scenario:

- Alice calls Bob. Once the call is established, the route set from Alice is as follows:

- When the INFO arrives to the REGISTRAR, the REGISTRAR MUST perform GRUU lookup, RIGHT??

- So the REGISTRAR retrieves the Bob binding which includes Path above (to be converted into Route header), but such a Route header is ALREADY present in the INFO due to previous and common record-routing.
So the REGISTRAR:

- YES OR NOT PLEASE???

  INFO sip:bob@BOB_IP

- Later during the dialog, Bob is disconnected so reconnects to EDGE and re-registers. Now a new Outbound Flow Token is generated and added to the Path header by EDGE:

- The REGISTRAR does GRUU lookup and retrieves the new Path that must be added as a new Route:

  BYE sip:bob@BOB_IP

- ...which is properly routed to Bob via the new connection. And no need for Alice and Bob to change the dialog route set.

Ok folks, please HELP ME, I cannot describe the problem in a better way. Do you see the ugly play with Route headers above? the REGISTRAR must remove a Route header that points to the next node (EDGE proxy) before REGISTRAR adds the Route mirrored from the Path !!!!

- How is supposed that a proxy can be able to remove Route headers belonging to proxies located after it??
- Is GRUU broken?
- Can GRUU work with in-dialog request or not?

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

---

From: Hugh Waite <[email-masked]>
Date: Tue, 07 May 2013 10:50:48 +0100

> 1) Is the above allowed by RFC 5626/5627 or not?
 From RFC 5627 § 6.1:

    Special considerations apply to the processing of any Path headers
    stored in the registration (seeRFC 3327  <http://tools.ietf.org/html/rfc3327>  [3  <http://tools.ietf.org/html/rfc5627#ref-3>]).  If the received
    request has Route header field values beyond the one pointing to the
    authoritative proxy itself (this will happen when the request is a
    mid-dialog request),*the Path URI MUST be discarded*.  This is
    permitted byRFC 3327  <http://tools.ietf.org/html/rfc3327>  [3  <http://tools.ietf.org/html/rfc5627#ref-3>] as a matter of local policy; usage of GRUUs
    will require this policy in order to avoid call spirals and likely
    call failures.

 From my reading of this, the RFC for GRUUs does not allow changing (or 
adding to) the route-set mid-dialog.

*IF* the registrar were to remove all forward Routes and replace them 
with a new route-set from the registration, I agree that the request is 
likely to reach the UA, even if the registration was through a different 
edge proxy (for example). However, I can think of examples where it is 
important to make sure that the path being replaced is going directly to 
the UA, e.g. when there are additional hops added during call setup 
(media servers, stateful proxies etc).

Also, if a UA is forced to use a second connection for an in-dialog 
request, then the route-set for the dialog will not match, e.g. if the 
first hop in the new route is a different edge proxy. Does routing 
traffic in this direction need to be considered at the same time as the 
main discussion?

When a UA detects a lost connection (whether that is signalling, media 
or moving from a 3G signal to a WiFi signal), the dialog needs to be 
re-targetted (and/or re-directed) and it may need to renegotiate media. 
Can something like the 'replaces' mechanism be used to take over the 
dialog using out-of-dialog requests? Would this work round any of the 
problems discussed here?

Hugh

-- 
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 10:04:07 +0000

Hi,

Your example below only shows requests sent from Alice. And, true, Bob will not see that a different route set is used, as the Route headers are removed on the path (of course, the Via headers will be different, but I doubt will store and compare them).

But, my comment was about when/if Bob sends an in-dialog request (INFO, BYE, or whatever).

I am not really sure what you mean by GRUU "being broken". In the same way as Outbound, GRUU was designed with initial dialog requests (or stand-alone requests) in mind, not mid-dialog requests.

Regards,

Christer

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 7. toukokuuta 2013 12:21
To: [email-masked]
Cc: Dale R. Worley; Christer Holmberg; Olle E Johansson; Klaus Darilion
Subject: Re: [dispatch] SIP outbound and in-dialog requests

Scenario:

- YES OR NOT PLEASE???

  INFO sip:bob@BOB_IP

  BYE sip:bob@BOB_IP

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 16:57:16 +0000

Hi Mike,

The edge proxy is part of the Outbound architecture :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Michael Hammer [mailto:[email-masked]] 
Lähetetty: 7. toukokuuta 2013 16:04
Vastaanottaja: Christer Holmberg; [email-masked]; [email-masked]
Aihe: RE: [dispatch] SIP outbound and in-dialog requests

Hmmm...  It would seem your problem is that there is this EDGE proxy between Bob and the Registrar.
Perhaps if you eliminate that, then your problems go away.
Do you have an RFC that details what the EDGE proxy is doing?

OK, so that is a bit facetious, but I have to wonder if this exercise is a bit like breaking the architecture, 
then turning around asking why it seems to be broken.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Tuesday, May 07, 2013 6:04 AM
To: Iñaki Baz Castillo; [email-masked]
Subject: Re: [dispatch] SIP outbound and in-dialog requests

Hi,

Regards,

Christer

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 7. toukokuuta 2013 12:21
To: [email-masked]
Cc: Dale R. Worley; Christer Holmberg; Olle E Johansson; Klaus Darilion
Subject: Re: [dispatch] SIP outbound and in-dialog requests

Scenario:

- YES OR NOT PLEASE???

  INFO sip:bob@BOB_IP

  BYE sip:bob@BOB_IP

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 May 2013 14:21:41 -0400

(Not replying to anyone in particular, just the thread to date)

I scanned the long list of messages in this thread over the last few 
days, and if I'm not mistaken, something may have been overlooked.

The route set is established at time of the initial invite, based on the 
contents of the Record-Route header. The Path header, used in REGISTER, 
subsequently affects *Route* headers put in outgoing requests from the 
home proxy. It doesn't necessarily affect what goes in Record-Route.

If edge proxies Record-Route in INVITEs that use a GRUU as the contact, 
they can easily make a big mess by spiraling requests. The alternative 
is for them to *not* R-R in that case, and count on the home proxy 
inserting the Path into the Route when processing a GRUU.

Does that solve the problem?

	Thanks,
	Paul

On 5/7/13 5:50 AM, Hugh Waite wrote:
>> 2013/5/6 Olle E. Johansson<[email-masked]>:
>>    BYEsip:[email-masked];gr=qweasdzxc
>>    Route:<sip:REGISTRAR>  (removed by REGISTRAR)
>>    Route:<sip:EDGE-BOB-NEW-PATH>
>>    Route:<sip:EDGE-BOB-OLD-PATH>  (removed by REGSISTRAR OR NOT ????)
>>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 11 May 2013 08:22:24 +0200

> - The REGISTRAR does GRUU lookup and retrieves the new Path that must

"Special considerations apply to the processing of any Path headers
   stored in the registration (see RFC 3327 [3]).  If the received
   request has Route header field values beyond the one pointing to the
  authoritative proxy itself (this will happen when the request is a
   mid-dialog request), the Path URI MUST be discarded.  This is
   permitted by RFC 3327 [3 as a matter of local policy; usage of GRUUs
   will require this policy in order to avoid call spirals and likely
   call failures."

This is from RFC 5627, section 6.1.

What I understand is that if you already have a route to the edge proxy that 
has the failed flow, you are still not allowed to change the route set based
on the Path header in the registration.

Now, if the edge proxy doesn't record-route we have a different situation.
In that case we have no flow token either.

Section 5.3.2 of RFC 5626 (outbound) has an interesting implementation note:

"Implementation note: Specific procedures at the edge proxy to
      ensure that mid-dialog requests are routed over an existing flow
      are not part of this specification.  However, an approach such as
      having the edge proxy add a Record-Route header with a flow token
      is one way to ensure that mid-dialog requests are routed over the
      correct flow."

/O

---

From: "Peter Dunkley" <[email-masked]>
Date: Sat, 11 May 2013 10:41:01 +0100

RFC 5626 section 4.3:
                                         If the UAC is using a Globally
   Routable UA URI (GRUU) [RFC5627] that was instantiated using a
   Contact header field value that included an "ob" parameter, the UAC
   sends the request over the flow used for registration, and subsequent
   requests will arrive over that same flow.  If the UAC is not using
   such a GRUU, then the UAC adds an "ob" parameter to its Contact
   header field value.

RFC 5626 section 5.3.2:
   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.

The effect here is that if GRUU is being used a flow-token will not be
added to the record-route added by the first edge proxy.  The impact of
this is that if the UA is behind a NAT device mid-dialog requests cannot
be routed to it.  The only way I can see to get these mid-dialog requests
to route correct is to replace the route-set with the Path:s from the
registrar.  The statement, "and subsequent requests will arrive over that
same flow" implies this too.

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd