Re: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net?



On 10/25/2010 05:26 AM, Eugen Dedu wrote:
Status-Line: SIP/2.0 606 Not Acceptable
I do not think the error comes from Contact, since I have myself:
REGISTER sip:ekiga.net SIP/2.0
[...]
Contact: <sip:eugen dedu 169 254 8 166>;q=1, <sip:eugen dedu 82 238 108 175>;q=0.667, <sip:eugen dedu 192 168 0 1>;q=0.334
and ekiga works.

You said something about ekiga not using the advertised port. Such a bug was fixed in ekiga 3.2.7, do you use this version or more ancient one? However, that bug prevented the packet to reach ekiga client, not making the sender send 606...
The bug fixed in 3.2.7 was to use the nat port for RTP connections, not the SIP connection. The nat port isn't used for the SIP connection because the registry wants to give out an IP,port that works from any public ip, not just the registry. This is why port forwarding must be used, and there can be only one SIP client behind a nat firewall. (I'm talking like an expert already, but I'm really not.)
This beginner thinks that it would be possible to proxy SIP traffic 
(which is low bandwidth) through the registry, using the nat port for 
SIP, and thereby support multiple simultaneous SIP clients behind the 
nat firewall.  This seems, in fact, to be what my companies commercial 
VOIP outfit (aptela.com) does, since it supports multiple SIP clients 
behind our iptables nat firewall.
I'm pretty sure I don't understand it all yet, because I don't see how 
STUN can give ekiga (the program) the nat port to use for an RTP 
connection (which would be to a different IP).
Send us the whole conversation (REGISTER and 606 answer I suppose).
Will do as soon as I get home.  But I discovered a new wrinkle last 
night.  If I load the ip_nat_sip module for the iptables nat at home, 
then ekiga.net lets me register.  However, diamondcard.us and aptela.com 
conversations then lose outgoing audio!   I also discovered that 
aptela.com will only let me register at home with STUN turned off.  
diamondcard.us works either way (except for losing outgoing audio with 
ip_nat_sip loaded).  Obviously, I'm not exactly sure what ip_nat_sip does...






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]