On Fri, Sep 30, 2016 at 5:38 PM, Alex Balashov
wrote:
> On 09/30/2016 03:52 PM, Roman Shpount wrote:
>
> 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. I
On 9/30/16 3:52 PM, Roman Shpount wrote:
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
On 09/30/2016 03:52 PM, Roman Shpount wrote:
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 unmodi
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
app
Right on. Well, I don't need the UAS to understand or do anything with
the proxy's proprietary parameter. I just need it to behave as it
normally would, returning the Via header in responses as-is, together
with any proprietary parameters.
What it's doing instead is sending replies to the prox
Roman,
On 9/30/16 2:27 PM, Roman Shpount wrote:
On Fri, Sep 30, 2016 at 2:03 PM, Paul Kyzivat 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 wha
Aah. That makes sense.
On September 30, 2016 2:34:29 PM EDT, Roman Shpount wrote:
>On Fri, Sep 30, 2016 at 2:28 PM, Alex Balashov
>
>wrote:
>
>> Yeah, but as I understand it, the spec is more explicit on arbitrary
>> parameters in the Route set than in Via.
>>
>> Route is where I'd expect the st
On Fri, Sep 30, 2016 at 2:28 PM, Alex Balashov
wrote:
> Yeah, but as I understand it, the spec is more explicit on arbitrary
> parameters in the Route set than in Via.
>
> Route is where I'd expect the state to go in this case, too—it's where all
> other state goes. But the implementors went with
On 09/30/2016 02:03 PM, Paul Kyzivat wrote:
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
Yeah, but as I understand it, the spec is more explicit on arbitrary
parameters in the Route set than in Via.
Route is where I'd expect the state to go in this case, too—it's where
all other state goes. But the implementors went with custom Via
parameters instead.
--
Alex Balashov | Principa
On Fri, Sep 30, 2016 at 2:03 PM, Paul Kyzivat 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 param
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 a
Alex,
From my experience a lot of proxies add generic parameters to Via headers,
so this is likely an implementation issue on the UAS side.
For instance here is the VIA header with custom parameters from Skype For
Business SIP INVITE:
Via: SIP/2.0/TLS 192.168.245.34:50087;received=
38.98.149.84;
PS. 'rport' would seem to provide strong evidence for the idea that
arbitrary parameters are supported.
But 'rport' is defined in RFC 3581. My question is specifically about
arbitrary parameters that aren't defined anywhere. Are implementations
required to ignore and conserve them?
--
Alex B
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 supp
15 matches
Mail list logo
