Subject: [dispatch] Surviving outbound

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 17 May 2013 14:53:46 +0200

It seems to me like the conclusion on the discussion on dialog survival during failure is 

A) When using GRUU there's a chance for survival of a dialog there's a possibility for the dialog to survive
B) If GRUU is not used, the dialog doesn't survive since the route set is fixed.

Is this correct?

If so, anyone interested in discussing a possible solution?

/O

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 17 May 2013 12:23:28 -0400 (EDT)

> From: "Olle E. Johansson" <[email-masked]>
> 

I don't see much value in worrying about the non-GRUU case, but the
GRUU case is best current practice and yet we do not currently have a
generally accepted/implemented solution to dialog survival.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 May 2013 19:21:10 +0200

> generally accepted/implemented solution to dialog survival.

It just works if the route set is modified by the intermediary
registrar (the route set between the registrar itself and the outbound
edge proxy the user is connected to). And for that to work, the
registrar must be able to remove Route headers pointing to the next
hop (the outbound proxy).

So yes, no real way.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2013 07:30:19 +0000

Hi,

I fail to see the GRUU vs non-GRUU aspect, but maybe that is not important :)

Perhaps there are scenarios where modifying the route set would work, but the point is that is goes against RFC 3261, and as soon as the new route set contains a new stateful proxy things will break, because it will reject mid-dialog requests for dialogs it is not aware of.

The way e.g. 3GPP solves this, for different types of scenarios, is by establishing a new dialog between the UA and some B2BUA. The dialog between the B2BUA and the remote UA is unchanged.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: 20. toukokuuta 2013 20:21
To: Dale R. Worley
Cc: [email-masked]
Subject: Re: [dispatch] Surviving outbound

> generally accepted/implemented solution to dialog survival.

It just works if the route set is modified by the intermediary registrar (the route set between the registrar itself and the outbound edge proxy the user is connected to). And for that to work, the registrar must be able to remove Route headers pointing to the next hop (the outbound proxy).

So yes, no real way.

--
Iñaki Baz Castillo
<[email-masked]>
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 21 May 2013 10:06:08 +0200

> Perhaps there are scenarios where modifying the route set would work, but the point is that is goes against RFC 3261, and as soon as the new route set contains a new stateful proxy things will brea…
You mean a call stateful proxy?
> The way e.g. 3GPP solves this, for different types of scenarios, is by establishing a new dialog between the UA and some B2BUA. The dialog between the B2BUA and the remote UA is unchanged.
Well, that's application specific but nothing we can rely on as a recommended solution.

Seems like there is a gap to fill here. Many workarounds, but most of them break RFC 3261.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2013 09:02:04 +0000

Hi,

>> Perhaps there are scenarios where modifying the route set would work, but the point is that is goes against 
>> RFC 3261, and as soon as the new route set contains a new stateful proxy things will break, because it will reject mid-dialog requests for dialogs it is not aware of.

Yes. 

> Seems like there is a gap to fill here. Many workarounds, but most of them break RFC 3261.

You could use the Replaces header field (RFC 3891), but you would still replace one dialog with another, rather than updating the route set for an existing dialog.

Regards,

Christer

---

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

> You could use the Replaces header field (RFC 3891), but you would still replace one dialog with another, rather than updating the route set for an existing dialog.

So the logic is that if a UA finds out that one flow is broken, it checks if there was any active dialogs running on that flow. If there was, you send INVITE with replaces to re-capture the calls on a working flow. In theory that could work regardless of b2bua. You restart ICE and reset any SRTP streams as well.

Yeah, that works. Interesting. Like outbound, you put the responsibility for dialog survival on the UA, which seems logical in a Spock sense.
Thanks for the feedback.

Anyone that sees problems with that? Could that become a BCP?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 May 2013 11:13:42 +0200

> Anyone that sees problems with that? Could that become a BCP?

The ellegant solution (without envolving re-negotiation of every
sessions) would be that the connection problem between the UA and its
outbound proxy (or registrar) was "fixed" by themself in a transparent
way.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2013 09:25:22 +0000

Hi,

>>>> Perhaps there are scenarios where modifying the route set would 
>>>> work, but the point is that is goes against RFC 3261, and as soon as the new route set contains a new stateful proxy things will break, because it will reject mid-dialog requests for dialogs it is not aware of.
> So the logic is that if a UA finds out that one flow is broken, it checks if there was any active dialogs running on that flow. If there was, you send INVITE with replaces to re-capture the calls on a working flow. 

Yes.

> In theory that could work regardless of b2bua. You restart ICE and reset any SRTP streams as well.

Sure. A B2BUA could "hide" the dialog change from the remote UE, but technically there is no difference.

> Yeah, that works.

As long as there is no intermediary changing the dialog identifier, resulting in the receiver not finding the dialog identified by the Replaces header field :)

Session-id could work, but I believe it is outside the scope to use it for this kind of functionality.

> Anyone that sees problems with that? Could that become a BCP?

If people think such BCP is needed, I would not object :)

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 21 May 2013 12:19:32 +0200

> outbound proxy (or registrar) was "fixed" by themself in a transparent

Absolutely. But that would require a new RFC.

If we go down that path - how would it look.

The path header that becomes part of the route set is the problem here, right. The route set can not change
during the lifetime of the dialog.

Typically the path header includes a flow token and an IP address.

Can we change the content of the path to something that doesn't point to a specific flow, but a set of
flows? A group of edge proxys?

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 21 May 2013 12:25:42 +0200

> flows? A group of edge proxys?

Why restrict a dialog to a specific flow, btw?

Even RFC 3263 suggests sending in-dialog requests to other proxys if the first one fails. It doesn't specify how, but I suspect that the recommendation is to use DNS names in route headers, names that has multiple SRV records.

Just brainstorming.
/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 May 2013 13:14:40 +0200

> during the lifetime of the dialog.

So don't change the route set :)

> Typically the path header includes a flow token and an IP address.

Yes, if it is an outbound edge proxy.

> flows? A group of edge proxys?

That would require changes to Outbound so 100% discouraged IMHO. I
have another idea on mind:

- Client connects to the Outbound EDGE proxy (or registrar).

- Client sends REGISTER.

- The proxy assigns an Outbound Flow Token id and enters it into the
Path header.

- The registrar replies 200.

- The proxy adds a header to the 200 before routing it to the client:

  Outbound-Info: flow-token=ABCD;recovery-passwd=1234

- The client is in a dialog with Bob.

- The connection of the client is closed (proxy restarted or whatever).

- The client detects it, reconnects to the proxy, and sends a new
REGISTER (a refresh REGISTER) with an extra header:

  Outbound-Replace: flow-token=ABCD;recovery-passwd=1234

- The proxy assigns the *same* flow token to this new connection so
routes the REGISTER with same Path value as before.

- Bob sends BYE. BYE arrives to the Outbound Proxy with the Route
header including flow token ABCD (as usual).

- The outbound proxy routes it via the new connection that previously
replaced the old one.

Transparent, no route set changes, no Outbound changes (just an
extension to be supported by the client and its outbound proxy).

Cool?

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 21 May 2013 13:29:31 +0200

> - The proxy assigns an Outbound Flow Token id and enters it into the
What's in the Path header? Details, please!

>  Outbound-Replace: flow-token=ABCD;recovery-passwd=1234
The client should already have a working flow with another edge proxy. That's the idea
with outbound - we don't have to wait for a new flow to open up.

> extension to be supported by the client and its outbound proxy).
It would be faster if we could use the existing flow.

Try that for a challenge :-)

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 May 2013 13:40:01 +0200

> What's in the Path header? Details, please!

Usual content:

  Path: <sip:ABCD@IP_PROXY_1;lr;ob>

> with outbound - we don't have to wait for a new flow to open up.

Nobody cares about mobile networks? having two connections is really a
bad idea for a mobile (battery).

I don't like the "multi connection solution" proposed by RFC 5626. I prefer:

- Connection is closed.

- UA try to reconnect to the same server.

- If it fails connect to the other server (based on RFC 3263 and so on).

> It would be faster if we could use the existing flow.

But that exactly my proposal: the flow token id is the same in the nex
connection with the outbound proxy. It something like:

- Hi outbound proxy, my previous connection with flow token ABCD has
been closed, so let me assign flow token ABCD to this new connection
I'm establishing with you, so I will be able to receive incoming
requests for existing dialogs.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 21 May 2013 13:56:13 +0200

>  Path: <sip:ABCD@IP_PROXY_1;lr;ob>
That IP_PROXY is a problem for failover to another flow.
> bad idea for a mobile (battery).
I guess that's why IMS does the INVITE/REPLACE thing.
> connection with the outbound proxy. It something like:
No, you set up a new flow with the identifier of an old, broken, one. That's different.

> requests for existing dialogs.
Connection setup can take a long time - considering you set up TLS
to the server and verify with OCSP and the edge proxy sets up a new
TLS and verifies that one and then the registrar needs to talk with a 
database and... 
TCP setup is three roundtrip messages, TLS at least nine. Add digest auth
before your registration is done.

The client will be down for a long time - will a request coming in from the other
side survive this time or will the dialog fail anyway?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 May 2013 14:10:47 +0200

> That IP_PROXY is a problem for failover to another flow.

Yes. I insisit: I don't like the "two connections" approach :)

> I guess that's why IMS does the INVITE/REPLACE thing.

This is a SIP design fault if we need to renegotiate a session just
because the connection between the client and its outbound proxy has
been closed.

> No, you set up a new flow with the identifier of an old, broken, one. That's different.

But the "existing" flow is broken, right? :)
so how to use it?

> side survive this time or will the dialog fail anyway?

If the client had a single connection (true in 99% of cases and
appropriate for mobile networks) then a reconnection is needed anyway,
right?
The reconnection and re-registration could take may be 3 seconds. IMHO
it is not so hard to assume that we are not going to receive in-dialog
requests during that process.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 21 May 2013 14:36:11 +0200

> Yes. I insisit: I don't like the "two connections" approach :)
I insist that it is the intention of Outbound to have it. Let's try to divide
the discussion in "full outbound" and "half outbound" then.

> because the connection between the client and its outbound proxy has
A design fault we're trying to find a solution for.

> But the "existing" flow is broken, right? :)
In the "full outbound" case there's a working secondary flow up and active. In the 
"half outbound" case, you are right.
> appropriate for mobile networks) then a reconnection is needed anyway,
Yes, in the "half outbound" scenario. In the full outbound scenario, there's
no need to wait for a reconnection. It can happen in the background.

> requests during that process.
What's your T1 and your session timers? There is a chance that
something will be going on exactly then.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 May 2013 17:18:33 +0200

> no need to wait for a reconnection. It can happen in the background.

Ok, we need a solution for both "half" and "full" Outbound scenarios.

Main problem of the "full" case is that the route set points, of
course, to just one of the edge proxies. Using a domain with N SRV
records in the Path header is not a good idea since the edge proxy
does not know wheter the UA will also register via the other edge
proxy or not.

I'm pretty sure that the "full" scenario has no solution without
changing the route set.

Let's think about it :)

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