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
