RE: [reSIProcate] Setting via headers for STUN

["Matthias Moetje - TERASENS GmbH" <moetje@xxxxxxxxxxxx>]

Gentlemen,

thanks for your comments on this issue.

First I'd like to stress, that by default
the via headers are NOT modified.
To accomplish this you need to create a
message decorator that does this modification
after transport selection.

Second, "everybody does it" is reason enough 
for me :-) Being standards compliant (if at all,
see below) but less compatible doesn't help
any of our customers.. 

Third, I don't see which "potential problems"
could be the result of this approach, please
specify.

Fourth, I'd be interested where exactly in 
any RFC it is stated that the via headers
MUST not be modified to the public IP address
when STUN is used. The principle of STUN is
to entirely replace all instances of the 
private IP address (in the contact header,
in the SDP and for all RTP stuff) and act
as if the client had the NAT device's public
IP. I can't see any reason nor any specification
against doing so for the via header, too.

And finally @Jason: Your e-mail address suggests
that you are working for Counterpath. X-Lite
which is created by Counterpath (but probably 
not using reSIProcate?) does the exact same 
via header modification that we are doing.


Best regards,

Matthias Moetje
______________________________________________

TERASENS GmbH       Phone:  +49.89.143370-0
Augustenstraße 24   Fax:    +49.89.143370-22
80333 Munich        e-mail: info@xxxxxxxxxxxx
GERMANY             Web:    www.terasens.com
______________________________________________ 

> -----Original Message-----
> From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] 
> On Behalf Of Jason Fischl
> Sent: Sunday, June 04, 2006 4:54 AM
> To: Alan Hawrylyshen
> Cc: Matthias Moetje - TERASENS GmbH; Cullen Jennings; 
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Setting via headers for STUN
> 
> >
> >
> > I think you will find some resistance to making this the 
> default behavior.
> > Please consider doing this locally only or we should have a fairly 
> > open discussion around this. I fear other list members will 
> object. I 
> > object mildly - we have had a general philosophy of not 
> doing things 
> > in reSIProcate that are against the standard. At the same time, the 
> > stack should provide enough flexibility for a local user to do what 
> > every they like with the stack.
> >
> 
> I'll kick in my opinion that we should NOT do this approach 
> by default in the stack.
>