On 9/30/16 12:39 PM, Alex Balashov wrote:
Hi,
I have a proxy implementation that adds a custom parameter to Via that
is not within the commonly seen subset of "maddr", "ttl", "received", or
"branch". It adds a parameter called "i", whose value is alphanumeric
(think hex nibbles).
I can't find any prose in RFC 3261 to explicitly support the idea that
arbitrary parameters are acceptable, but the ABNF appears to allow for it:
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.
OTOH, if you are *receiving* a SIP message and encounter via parameters
that you don't understand, because they aren't defined in the specs you
claim to support, then you are expected to ignore them. When forwarding
a message that you received, you are expected to pass those parameters
along even though you didn't understand them. There is no way that your
implementation can distinguish between a bogus parameter and one that
was validly defined in some extension you don't support.
Thanks,
Paul
Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ via-extension
via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address)
via-branch = "branch" EQUAL token
via-extension = generic-param
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
Moreover, RFC 3261 § 20.42 does say:
A Via header field value can also contain parameters such
as "maddr", "ttl", "received", and "branch", whose meaning
and use are described in other sections.
In my reading of this, the turn of phrase "such as" is chosen very
deliberately. But I could be wrong.
So, the question is, would something like 'i=d3adb33f' be acceptable for
a proxy to stamp on its own Via header? It sounds like it should be.
Yet, I'm dealing with a UAS that doesn't like it—more specifically, it
fails to parse the Via if it contains an alphanumeric value, although it
copes fine with a strictly numeric one. The result is that responses
from the UAS don't contain the proxy's Via header, leading it to barf on
processing them.
Thanks!
-- Alex
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
