Subject: [sipcore] Need RFC 5627-bis (GRUU improvements and clarifications, and RFC 3261 update)

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 5 Jul 2013 14:55:09 +0200

Hi, after leading a lot with Outbound and GRUU I think there are well
known problems and specification issues that IMHO should be addressed
in some kind of RFC 5627-bis.

The problem
------------------

alice --- OP --- Registrar --- bob

- OP is an Outbound EDGE Proxy.
- Registrar is GRUU capable.

Flow showing the problem:

- alice registers requesting GRUU.
- OP adds Path.
- alice obtains a GRUU URI.

case A)

1) alice calls bob by using her GRUU in Contact. alice also requests
Outbound usage by adding ;ob in Contact of INVITE.

2) OP adds Record-Route.

3) OP routes to registrar which adds Record-Route and routes to Bob.

4) Bob sends INFO to alice.

5) Registrar receives INFO with GRUU RURI (;gr), removes Route
pointing to it, and still has Route with Outbound flow token
identifier pointing to OP.

6) Registrar decides to route based on RURI GRUU so performs lookup
and obtains the binding for such a GRUU URI, and of course adds Route
mirroring the registration Path.

7) INFO arrives to OP with Route belonging to the dialog (with
Outbound flow identifier) and *also* Route produced by the Path.
Typically this means "duplicated  route set". So it could fail routing
the request (loop), and OF COURSE, Route set is broken (RFC 3261)
since Route set has been modified within a dialog.

case B)

1) alice calls bob by using her GRUU in Contact. alice does NOT
request Outbound usage (she does NOT add ;ob in Contact of INVITE)

2) OP does NOT add R-R.

3) OP routes to registrar which adds Record-Route and routes to Bob.

4) Bob sends INFO to alice.

5) Registrar receives INFO with GRUU RURI (;gr), removes Route pointing to it.

6) Registrar routes based on GRUU so performs lookup and obtains the
binding for such a GRUU URI, and of course adds Route mirroring the
registration Path.

7) INFO arrives to OP with Route produced by the registration Path. OP
will be able to route the request, of course, but Route set has also
been modified (breaks RFC 3261).

8) Now alice wants to send BYE to bob. It just adds to the request the
Route mirroring R-R received in the 200 for the initial INVITE, which
just contains the Route pointing to the registrar (since OP did not
R-R).

9) OP receives an in-dialog request *without* a Route pointing to it.
In several proxy configurations this request would be rejected (why
does the in-dialog request arrive to OP if it did not R-R?). One could
argue "alice should send BYE to Registrar by following the Route set
rules", but this is not how things work in Outbound, even less if the
transport is WebSocket and the UA can just talk with OP).

In both cases Route set is modified during a dialog and breaks RFC
3261. My opinion: This is GOOD since it makes possible for the dialog
to continue alive even if the TCP connection between alice and OP was
closed and re-opened (new Outbound flow token identifier, refreshed in
a new registration so new Path).

The "nice" solution to avoid problem in case a) dot 7 is:

If a Registrar receives an in-dialog request with a GRUU RURI pointing
to it, it MUST remove all the Route header present in the request (and
ignore them), and then do lookup, replace RURI with the real binding
and add Route mirroring registration Path values. After lot of
thinking this seems to be the best and only? solution for GRUU to
properly work for in-dialog requests.

So I propose a new work RFC 5627-bis to clarify all of this, and also
to "update RFC 3261" stating that dialog Route set can be modified if
GRUU is used as Contact by any of the peers.

Thoughts?

Best regards.

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

---

From: José Luis Millán <[email-masked]>
Date: Tue, 9 Jul 2013 11:01:39 +0200

I do agree with Iñaki that this scenario, which takes more relevance with
the time, requires a clarification.

RFC 5627 Section 6.1 states that in order to avoid the exposed spiral case,
the Path URI Must be discarded when the request contains Route header/s,
but in fact, the Path determines the right route to the UA.

'''

Special considerations apply to the processing of any Path headers
stored in the registration (see RFC 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 by RFC 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.

'''

While RFC 5626 Section 7 states near the contrary. The proxy MUST send the
request over the flow determined by the Path header:

'''

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.

'''

2013/7/5 Iñaki Baz Castillo <[email-masked]>

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

-- 
José Luis Millán