На 31.10.11 15:54, firstname.lastname@example.org написа:
I have noticed that when Jitsi issues a REGISTER, the Contact header
includes the local port of the socket used to send the message (ie:
local port of the TCP socket connecting to an outbound proxy, or
directly to the REGISTRAR).
Indeed. This is quite intentional though. This way we are certain the
server would be able to respond on that port.
So while the REGISTRAR records that port, Jitsi still only listen on tcp
port 5060 / 5061.
If by "listen" you mean having a port open in a LISTEN mode then yes
that's true. Of course we also "listen" to whatever messages arrive from
the server on the client socket we used to connect to it.
So any agent trying to open a tcp socket using that binding will fail.
The server would be able to reach us there. Others would indeed fail.
But netstat reveals that port 14668 is the local port of an active
socket to the outbound proxy. The listening point for TCP is still only
on 5060. SIP requests coming from other agents than the proxy will fail
if they use the binding.
I’m thinking port 5060 should have been used in the Contact header, and
14668 should have only been visible in the Via header.
That was initially the case (a couple of years ago) and we had to change
it to what we have today. Here's the reasoning:
Generally, servers don't care what port a user is connecting from when
that user is sending requests from behind a NAT (i.e. the majority of
Again, generally, servers only respect that port when the UA is
registering with a public address, or an address that is directly
reachable by the server. The problem here is that, despite the absence
of a NAT, the majority of the users that have public IP addresses, do
have a firewall protecting them. Such firewalls would almost always drop
incoming TCP connections and would only allow packets in cases where an
outbound connection has been established from within the internal network.
In other words: since Jitsi never uses 5060 to send TCP requests to a
server (or to anyone for that matter), then no one would be able to
contact Jitsi on port 5060.
As a result, TCP connections were failing for all users that were
connecting with public IP addresses (which is quite funny when you think
of it )
We had two choices to resolve this: we either use 5060 to make outbound
TCP connections or we tell servers to contact us on whatever port we are
using to connect to them.
The former implies a whole lot of refactoring in the JSIP stack so we
settled for the latter.
Indeed that does imply that the only entity that could reach us via TCP
is the one we've registered with ... but this is what happens the
overwhelming majority of the cases out there so it wasn't really such of
a big deal.
Could you maybe tell us a bit more about your use case and why you need
others to be able to contact Jitsi directly rather than using a proxy?
I checked through Jira but couldn’t find anything related to this. I’m
using version 1.0-beta1-nightly.build.3689.
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
email@example.com PHONE: +18.104.22.168.43.30
http://jitsi.org FAX: +22.214.171.124.47.31