[reSIProcate] Setting via headers for STUN

Matthias Moetje - TERASENS GmbH moetje at terasens.com
Sat Jun 3 16:18:55 CDT 2006


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

 	
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 <mailto:info at terasens.com> 
www.terasens.com <http://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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060603/ce8c93db/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TERASE1.jpg
Type: image/jpeg
Size: 2937 bytes
Desc: TERASE1.jpg
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060603/ce8c93db/attachment.jpg>


More information about the resiprocate-devel mailing list