Well, I agree with you in theory, but this is one of those horses which has been out of the barn for a long time. No amount of standards clarifications will resolve this now due to how common it is to add customer parameters to SIP headers and how many of those parameters are now used in legacy applications. It might be a good idea to test and warn of such custom header use during SipIt events to avoid them in the future.
As far as Via is concerned, the better and standard compliant practice is to encode any application specific data in VIA tag parameter using some sort of proprietary encryption scheme. It is guaranteed that Via tag will be returned to the proxy unmodified. Regards, _____________ Roman Shpount On Fri, Sep 30, 2016 at 3:16 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > Roman, > > On 9/30/16 2:27 PM, Roman Shpount wrote: > >> On Fri, Sep 30, 2016 at 2:03 PM, Paul Kyzivat <pkyzi...@alum.mit.edu >> <mailto:pkyzi...@alum.mit.edu>> wrote: >> >> The inclusion of generic-param is a provision for future extensions >> with backward compatibility. It doesn't mean that anybody is >> *permitted* to add whatever they want. (It takes a published RFC to >> validly define a new header field parameter.) So if you *insert* >> values that haven't been properly defined and registered then you >> are violating the specs. >> >> >> This interpretation would break a lot of SIP implementations. The reason >> for this is that Via and Route generic parameters are used by stateless >> proxies to store application specific state. There is no other place to >> put it. Skype for business was one example. I can probably find another >> 10-15 examples similar to that from other products. >> > > Maybe it would. But I think it is more than simply *my* interpretation. > > RFC3427 says: > > Anyone who thinks that the existing SIP protocol is applicable to > their application, yet not sufficient for their task must write an > individual Internet-Draft explaining the problem they are trying to > solve, why SIP is the applicable protocol, and why the existing SIP > protocol will not work. > > And RFC3968 says: > > SIP header field parameters and parameter values MUST be documented > in an RFC in order to be registered by IANA. This documentation MUST > fully explain the syntax, intended usage, and semantics of the > parameter or parameter value. The intent of this requirement is to > assure interoperability between independent implementations, and to > prevent accidental namespace collisions between implementations of > dissimilar features. > > How can you read those to allow use of unregistered values? > > If there is need for this, then there ought to be a revision to carve out > a namespace for proprietary header field parameters, in general, or perhaps > only for Via. > > Thanks, > Paul > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
