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:
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
