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

[Iñaki Baz Castillo <[e-mail]>]

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
<[e-mail]>