Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path

[Christer Holmberg <[e-mail]>]

Hi,

>>>> Some proposed new text based on your comment regarding symmetric path.
>>> I think the statements you have added below seem reasonable as far as
>>> they go, but they only go half way. They say nothing about what the
>>> *recipient* of keepalives must do when sending requests.
>>
>>That is meant to be covered by the text I suggetsed for section 4.4. It says that the receiver of keep-alives must send messages towards the sender of those keep-alives using the address and port from where the keep-alives arrived.
>
>I don't think that is sufficient for TCP. AFAIK it actually has to be on
>the same connection. So for instance, if it attempted to open a new
>connection in the reverse direction to the same address and port, it
>would quite probably fail.

That is true, and at least from my experience that is also how entities providing NAT traversal (with or without outbound) work.

>>>And I have a strong suspicion this is pretty far along toward reinventing -outbound-.
>>
>>I don't agree. Symmetric routing wasn't invented by Outbound. It is used in NAT scenarios even if you don't use Outbound, in order to ensure that messages pass NATs.
>>
>>For example, entities providing NAT traversal using anchoring/latching use symmetric routing.
>>
>>We also already have mechanisms like rport to request symmetric response routing.
>
>In the case of TCP this comes down to connection reuse, which is covered
>by outbound on the edge, and by the connection-reuse draft elsewhere.

Yes.

So, there are two options:

1. We say that, for TCP, a connection re-use must be used.
2. We mandate the support of the connection re-use spec (RFC 5923).

I guess the only difference between 1) and 2) is that 2) would require the usage of the "alias" parameter, defined in 5923, while 1) means that support of keep-alive implicitly also indicates support of connection re-use.

Section 6 talks about connection reuse. But, we will most likely have to modify (or even remove) the section, based on above.

>I think you are talking about much the same, unless you are restricting to UDP.

Absolutely not :)

Regards,

Christer