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

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 29 Apr 2013 11:49:40 +0200

In the Kamailio project, we've worked on a registrar and edge-proxy implementation of SIP outbound (RFC 5626) for a while.

We now stumble into the handling of in-dialog requests.

The RFC is clear how to handle dialog-forming requests and failover in regards to these. But it doesn't really say anything
clear on how to handle in-dialog requests in case of a failed flow.

The route set, based on the Path header at registration, now contains a flow token for a failed flow. This route set can
not change, even though we know that we have a secondary flow to the same instance ID that works (another Reg-id).
The dialog has to die since we can not route according to the route set.

I do remember a discussion about this on a SIPit event but don't remember if we found a solution.

Any ideas on how to handle this situation? Anyone working on this issue?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Apr 2013 21:47:31 +0200

> Any ideas on how to handle this situation? Anyone working on this issue?

The only solution is using GRUU so if the client looses the connection
during a dialog, it registers again and the location-server (i.e. the
registrar) would route in-dialog requests via the new Route set.

Tested ;)

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 29 Apr 2013 21:56:47 +0200

> registrar) would route in-dialog requests via the new Route set.

Which means that you actually change the in-dialog route set?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Apr 2013 22:49:37 +0200

Yes! And it breaks RFC3261 :)

--
Iñaki Baz Castillo
<[email-masked]>
El 29/04/2013 21:56, "Olle E. Johansson" <[email-masked]> escribió:

> >> The route set, based on the Path header at registration, now contains a
> flow token for a failed flow. This route set can
> >> not change, even though we know that we have a secondary flow to the
> same instance ID that works (another Reg-id).

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 30 Apr 2013 08:26:27 +0200

> Yes! And it breaks RFC3261 :)
That's what we agreed on the Kamailio developer mailing lists too.

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?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Apr 2013 11:41:43 +0200

> route change to an existing dialog?

Is not cool enough? :)

Right, RFC 5627 should say "something" about it.

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