Thomas Monjalon wrote:
Darshaka Pathirana wrote:
On 24.02.2008 18:58, Thomas Monjalon wrote:
Darshaka Pathirana wrote:
I am not even able to login. Are my settings correct? Does
anybody
have experience with connecting Wengophone to the ekiga.net
server?
I tried this (it didn't work) and the result of my test was: the
HTTP
tunnel proxy which helps to pass through NAT doesn't work
with a generic
SIP account.
Does that mean WengoPhone is not (and never was) able to connect to
any other SIP-Provider (because the HTTP tunnel proxy does not
support that)? This IS serious (at least for me). Any ideas on how
to overcome this limitation?
In rare cases where tunnelling is useless, I think it is possible to
use generic SIP account. A solution is to implement another tunnel
proxy but the bandwidth is difficult to support. Maybe that the best
solution is to have distributed proxies like Skype do.
I don't remember why you have a response to the SIP ping but
not for the
true register. I think that the solution is in HTTP proxy...
Could you send your wireshark log ?
Yes I have the same concern. I've attached the pcap-file of my trace...
It seems that your NAT allow SIP because you have a response to your
SIP ping in a true UDP packet. But the second register doesn't have
a response. What is the difference ? Maybe the via line with local
address... Could you try to remove the via ? You can comment
osip_message_set_via() in wifo/eXosip/src/jrequest.c
The HTTP tunnel is not implemented in generic SIP. You can check it
in
SipAccount::discoverForSIP
(wengophone/src/model/account/SipAccount.cpp)
and in WengoAccount::discoverForSIP
(wengophone/src/model/account/wengo/WengoAccount.cpp).
I ever tried to implement HTTP tunnel in generic SIP but it
didn't work.
I think that it is a political reason in proxy implementation.
Ok. Thank you for pointing out. I had no idea that SIP is tunneled
through a HTTP tunnel. Is there no other solution? It seems that I
have to read into it...
It's VERY long shot on my part but it seems that
we're seek here anti-DOS behaviour from ekiga....
I sees first REGISTER replies 401 and expect to get REGISTER
with authorization header,
Instead of that 350 msec later it gets another REGISTER from
the same IP adress with different From.
It thinks that somebody doing penetration test and
starts ignoring incomiong traffic from that
IP address for some period of time.
ipcop software works like this for HTTP traffic
I think sending OPTIONS instead of REGISTER for
network connectivity discovery was better idea.
Vadim
Hello,
is there any progress in this direction? i mean is there at least a change to
get wengophone with ekiga-account working?
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
