[reSIProcate] Setting via headers for STUN

[Cullen Jennings]

I think Matthais has hit on a solution that everyone can live with,  
applications that want to do this can add a message decorator at the  
DUM level and it does not need to be the default behavior of the stack.

On a side note, some of the phones vendors did that a long time ago  
to work with a very broken situation of one particular service  
provider - that has long since been fixed.

On Jun 3, 2006, at 2:18 PM, Matthias Moetje - TERASENS GmbH wrote:

> Cullen,
>
> thanks for your comments. Admittedly in some cases it
> might just not be required to change the via headers,
> but you can't expect this behaviour from all other parties.
>
> And I can't see why it should be wrong to do so.
> Some popular SIP phones we have examined are doing
> exactly the same thing.
> Furthermore I remember that we have been doing a
> test with a VoIP provider where the connection didn't
> work without changing the via header.
>
> Anyway, the problem has been solved through the new
> ability to add a message decorator in dum which can
> change the via headers after transport selection, so
> anyone can decide wether to change the via headers
> in a STUN scenario or not.
> I'd say, doing so will increase the chances of successfully
> establishing a connection with an arbitrary SIP
> implementation in a STUN scenario.
> Best regards,
>
> Matthias Moetje
>
> <TERASE1.jpg>
> TERASENS GmbH
> Augustenstraße 24
> 80333 Munich
> GERMANY
> Phone:
> Fax:
> e-mail:
> Web:+49.89.143370-0
> +49.89.143370-22
> info at terasens.com
> www.terasens.com
>
>
> From: Cullen Jennings [mailto:cullenfluffyjennings at gmail.com]
> Sent: Saturday, June 03, 2006 9:57 PM
> To: Matthias Moetje - TERASENS GmbH
> Cc: resiprocate-devel at list.sipfoundry.org
> Subject: Re: [reSIProcate] Setting via headers for STUN
>
>
> I don't think this is right. You should not be changing your VIA to  
> the STUN public address. You should use your private address. The  
> receiver will mark the received from to update.
>
>
> On Apr 4, 2006, at 3:25 PM, Matthias Moetje - TERASENS GmbH wrote:
>
>> Hi,
>>
>> I am currently encountering a problem while implementing
>> STUN support:
>>
>> When I adjust the via headers for sending an invite to
>> the discovered mapped ip address and port, the
>> TransportSelector tells that it is unable to determine
>> a matching transport. This is because it uses the first via
>> header to determine a matching transport.
>>
>> How can I work around this (change the via but use the
>> actual local IP and port for transport selection)?
>>
>> Best regards,
>>
>> Matthias Moetje
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.sipfoundry.org
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>