Re: draft-zourzouvillys-sip-via-cookie

On Tue, Feb 24, 2009 at 9:29 PM, Adam Roach <[email protected]> wrote:
> Ah -- "statelessly" means something very different to you than it does to
> me. I think you need to explicitly call out that you're proposing a
> modification to the basic INVITE transaction model defined in RFC 3261 for
> this new response.

will do

> It sounds like you're currently setting this up so that it can't work
> transitively -- that is, if you have a chain of proxies, some of them
> compliant to this behavior, others that aren't, then any proxy past a
> non-compliant one can't check return routability. That seems like an
> artificial limitation. If you had some other way of indicating support by a
> client that could be checked by every proxy in the chain, then you could
> perform routability checks all the way back to the client regardless of
> intervening older proxies.

While I did initially consider this problem, and indeed came up with a
potential solution in the form of a new authentication scheme or a
header that the client then used to insert in it's own via header,
HERFP as well as multi-hop authentication just seemed to make any
solution i could come up with very complex compared to this method -
which while it has it's downsides in terms of backward compatibility,
the beauty is in it's simplicity and that it should hopefully not be a
burden for stacks to add with no change outside of the
transaction/transport layer.

 ~ Theo
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip