Dragos Vingarzan wrote: > Wouldn't a UA break the SIP RFC if it would change the Record-routes?
Sure. But that has never been a good enough reason for not doing things. > Using the userpart, parameters or even ports to store information in > Path, Service-Route, Record-Route or even Route (short-term, only for > the transaction, when the message will be proxied back) headers is quite > common in IMS for example. My point was less the question whether to do it at all, but rather a possibly puristic frown upon the use of proprietary URI paramters. Whether it works or not, current guideline for SIP is to not invent your own stuff. > For storing simple things, like direction indications they are quite > beneficial... Like using a Path: <sip:[EMAIL PROTECTED]> - when you > get a request with a Route containing this, you can jump directly to the > route[] for the outbound direction on initial requests. With outbound, you are required to store a flow token in you Path header because you can have more than one flow (ie., TCP connection or UDP flow) with any given host. The draft says, you MAY store that token in the userpart. > but relying on those values and keeping you proxy more or less stateless > is something else. Think about the security implications of someone > changing those on purpose. Then it gets complicated, so besides storing > simple indications that would anyway need to be confirmed with locally > stored data, I would say that this mechanism is not worth the trouble to > plug all the exploitable holes. It all depends on what you store there. The current ser-oob.cfg stores some hint on session timers and NAT handling applied to the original INVITE. That seems fairly safe to me. Obviously, you don't put any sensitive data in unless you can encrypt it or at least ensure some integrity. Regards, Martin _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
