I understand this is frustrating, but, believe it or not, this is not
quite the responsibility of SC/Jitsi. Read on.
На 03.02.11 00:31, email@example.com написа:
1) Emil, you wrote something about using TCP. So, how to use TCP?
Best case is: your provider supports it and indicates that TCP is the
default transport in the corresponding DNS NAPTR records. In this case
SIP communicator would automatically choose TCP and the user won't be
bothered with it.
If your provider/server does support TCP but has not configured NAPTR
records, then you need to modify your account settings and choose TCP as
the method for connecting to your proxy.
If your provider/server does not support TCP .... there's nothing SC
What are disadvantages of this method?
None that really matter. UDP is mostly used with SIP for historical
2) Does break something using the don't fragment bit in ip packets? If not, SIP
Communicator should use it.
Using the don't fragment bit simply means that your packets will be
dropped rather than fragmented.
3) Trying to discover the path with the maximum MTU allowed could be useful. Is
As Lee pointed out - this is the responsibility of the operating system.
What we could do is show a warning to users when we detect this and tell
them to disable codecs. Given that this is mostly the responsibility of
the provider though I'd have to admit that this would be rather low
I want only to remark that a lot of people could have this problem, and maybe
they thought about how bad SIP Communicator is. When releasing an 1.0 version we
should look to the non expert users too, and they will not understand why
firewall is blocking their callings (uh, what is firewall? It's something to
eat?). They expect SIP Communicator (Jitsi) working out-of-the-box, in any
circumstances. We should think about it. Changing something is needed: changing
SIP Communicator, changing SIP protocol,
As it was already said: SIP works with TCP and SC supports it. If your
provider does not: you should address your questions to them
As for XMPP: the problem simply does not exist. All major providers and
implementations use it with TCP (I am not even sure anyone has ever used
XMPP over UDP for anything else than research and experimentation).
changing IP protocol (ok, this was
done, but we cannot wait the moment when everyone will use IPv6. It seems that
it's better not having addresses for everyone than using the new IP version).
I am afraid I missed the point here ... or the meaning ... or both.