Wouldn't a UA break the SIP RFC if it would change the Record-routes? 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.
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. 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. If you would have a stateless light-weight mechanism for integrity verification, that would be something different... Cheers, -Dragos Martin Hoffmann wrote: > Heisann, > > the rr module has the ability to store attributes in a Record-Route > header and little pick them up from the Route headers. For this it uses > a proprietary URI parameter, which is considered bad style by some. The > outbound draft > > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-15.txt > > suggest in section 5.1 that a edge proxy may store the flow token in the > userpart of the URI of its Path header field value. This made me wonder > why we don't do the very same thing for the Record-Route headers? > > Is there any good reason for using a URI parameter (which may be dropped > by some stupid UA)? > > Regards, > Martin > _______________________________________________ > Serdev mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/serdev > > _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
