Re: [reSIProcate] Setting via headers for STUN
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@xxxxxxxxxxxx
www.terasens.com
From: Cullen Jennings [mailto:cullenfluffyjennings@xxxxxxxxx]
Sent: Saturday, June 03, 2006 9:57 PM
To: Matthias Moetje - TERASENS GmbH
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel