[jitsi-dev] Cannot connect to SIP account


#1

Hello,

I cannot connect to my SIP account with build 3660.

The log says:

21:14:14.606 WARNING: impl.resources.ResourceManagementServiceImpl.getSettingsInt().753 Missing resource for key: net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
21:14:14.607 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
21:14:14.609 WARNING: impl.resources.ResourceManagementServiceImpl.getSettingsInt().753 Missing resource for key: net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
21:14:46.659 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
21:14:47.659 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped

These are the lines that appeared after initiating connection. The account works in another client (Linphone for example). I have this account set up for a long time (it uses a VPN with a tap device), it worked ok before.
After i explicitly set up the proxy to the same as the server, i have this:

21:19:11.300 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
21:19:11.301 WARNING: impl.resources.ResourceManagementServiceImpl.getSettingsInt().753 Missing resource for key: net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
21:19:43.363 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
21:19:44.364 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped

But still no connection.

···

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/


#2

Hi all,
today I seen that my SIP account can't connect anymore. Build 3613 was ok, build 3614 fail to connect (yes, I'm not using a lot SIP, maybe Jitsi is not as stable as I thought). The problem seems to be in the 8817 commit.
So I can confirm that this happened to me too:

Hello,

I cannot connect to my SIP account with build 3660.

The log says:

21:14:14.606 WARNING: impl.resources.ResourceManagementServiceImpl.getSettingsInt().753 Missing resource for key: net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
21:14:14.607 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
21:14:14.609 WARNING: impl.resources.ResourceManagementServiceImpl.getSettingsInt().753 Missing resource for key: net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
21:14:46.659 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
21:14:47.659 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped

These are the lines that appeared after initiating connection. The account works in another client (Linphone for example). I have this account set up for a long time (it uses a VPN with a tap device), it worked ok before.
After i explicitly set up the proxy to the same as the server, i have this:

21:19:11.300 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
21:19:11.301 WARNING: impl.resources.ResourceManagementServiceImpl.getSettingsInt().753 Missing resource for key: net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
21:19:43.363 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
21:19:44.364 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped

But still no connection.

--O zi buna,

Kertesz Laszlo

I have these lines in log:

18:47:54.915 INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from
the JAIN-SIP stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:47:55.916
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:47:58.913
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
18:47:58.914
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
18:47:58.918
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
18:48:31.042
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:48:32.045
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:48:39.039
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
18:48:39.041
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
18:48:39.053
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
18:49:11.180
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:49:12.182
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:49:27.181
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
18:49:27.183
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
18:49:27.187
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
18:49:59.304
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:50:00.306
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:50:31.301
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
18:50:31.302
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
18:50:31.306
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
18:51:03.428
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:51:04.429
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
18:52:07.425
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
18:52:07.427
INFO: impl.protocol.sip.SipLogger.logInfo().175 Info from the JAIN-SIP
stack: the sip stack timer
gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
18:52:07.430
AVVERTENZA:
impl.resources.ResourceManagementServiceImpl.getSettingsInt().753
Missing resource for key:
net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT

I have not tested with explicit proxy settings.
More info:
- Jitsi doesn't ask my SIP account password (even when the password is not saved);
- I'm using an iptel.org account;
- I see 6 REGISTER request in pcap with no response, but I have a suspicion about this line:
REGISTER sip:iptel.org;transport=tcp SIP/2.0
are we sure iptel.org does support tcp? I was remembering they only supported udp, but they could have changed this.
- I'm using linux (openSUSE 11.4) x86_64 with Sun JRE and I'm behind a router with NAT.

Regards,
Daniel


#3

Hey

[snip logs]

I have not tested with explicit proxy settings. More info: - Jitsi
doesn't ask my SIP account password (even when the password is not
saved); - I'm using an iptel.org account; - I see 6 REGISTER request in
pcap with no response, but I have a suspicion about this line: REGISTER
sip:iptel.org;transport=tcp SIP/2.0 are we sure iptel.org does support
tcp? I was remembering they only supported udp, but they could have
changed this. - I'm using linux (openSUSE 11.4) x86_64 with Sun JRE and
I'm behind a router with NAT.

As far as I can tell the problem is IPTel. They announce that they support SIP via TCP in DNS (using the SRV record _sip._tcp.iptel.org) but their server doesn't reply to requests there.
When updating the register code, we explicitly chose to try connecting in this order: TLS, TCP, UDP. As per RFC3263, SIP clients can freely choose the protocol preference [1]. So I definitely don't see this to be a bug, but we might have to consider this for the specific IPTel account plugin.

As a workaround you can manually set the proxy of the IPTel-Account to sip.iptel.org, port 5060 and transport UDP.

Regards,
Ingo

[1] http://tools.ietf.org/html/rfc3263:
   If no NAPTR records are found, the client constructs SRV queries for
   those transport protocols it supports, and does a query for each.
   Queries are done using the service identifier "_sip" for SIP URIs and
   "_sips" for SIPS URIs. A particular transport is supported if the
   query is successful. The client MAY use any transport protocol it
   desires which is supported by the server.


#4

Hi!

Hey

[snip logs]

I have not tested with explicit proxy settings. More info: - Jitsi
doesn't ask my SIP account password (even when the password is not
saved); - I'm using an iptel.org account; - I see 6 REGISTER request in
pcap with no response, but I have a suspicion about this line: REGISTER
sip:iptel.org;transport=tcp SIP/2.0 are we sure iptel.org does support
tcp? I was remembering they only supported udp, but they could have
changed this. - I'm using linux (openSUSE 11.4) x86_64 with Sun JRE and
I'm behind a router with NAT.

As far as I can tell the problem is IPTel. They announce that they support SIP via TCP in DNS (using the SRV record _sip._tcp.iptel.org) but their server doesn't reply to requests there.
When updating the register code, we explicitly chose to try connecting in this order: TLS, TCP, UDP. As per RFC3263, SIP clients can freely choose the protocol preference [1]. So I definitely don't see this to be a bug, but >we might have to consider this for the specific IPTel account plugin.

As a workaround you can manually set the proxy of the IPTel-Account to sip.iptel.org, port 5060 and transport UDP.

Regards,
Ingo

Thanks for the help, it works. But it's a shame that such an historic provider has this bug.

Regards,
Daniel

···

[1] http://tools.ietf.org/html/rfc3263:
If no NAPTR records are found, the client constructs SRV queries for
those transport protocols it supports, and does a query for each.
Queries are done using the service identifier "_sip" for SIP URIs and
"_sips" for SIPS URIs. A particular transport is supported if the
query is successful. The client MAY use any transport protocol it
desires which is supported by the server.


#5

На 20.09.11 21:10, Daniel Zucchetto написа:

Hi!

Hey

[snip logs]

I have not tested with explicit proxy settings. More info: - Jitsi
doesn't ask my SIP account password (even when the password is not
saved); - I'm using an iptel.org account; - I see 6 REGISTER request in
pcap with no response, but I have a suspicion about this line: REGISTER
sip:iptel.org;transport=tcp SIP/2.0 are we sure iptel.org does support
tcp? I was remembering they only supported udp, but they could have
changed this. - I'm using linux (openSUSE 11.4) x86_64 with Sun JRE and
I'm behind a router with NAT.

As far as I can tell the problem is IPTel. They announce that they support SIP via TCP in DNS (using the SRV record _sip._tcp.iptel.org) but their server doesn't reply to requests there.
When updating the register code, we explicitly chose to try connecting in this order: TLS, TCP, UDP. As per RFC3263, SIP clients can freely choose the protocol preference [1]. So I definitely don't see this to be a bug, but >we might have to consider this for the specific IPTel account plugin.

As a workaround you can manually set the proxy of the IPTel-Account to sip.iptel.org, port 5060 and transport UDP.

Regards,
Ingo

Thanks for the help, it works. But it's a shame that such an historic provider has this bug.

Feel free to report this to their list:

http://lists.iptel.org/mailman/listinfo/services

They've always been very helpful.

Cheers,
Emil

···

Regards,
Daniel

[1] http://tools.ietf.org/html/rfc3263:
   If no NAPTR records are found, the client constructs SRV queries for
   those transport protocols it supports, and does a query for each.
   Queries are done using the service identifier "_sip" for SIP URIs and
   "_sips" for SIPS URIs. A particular transport is supported if the
   query is successful. The client MAY use any transport protocol it
   desires which is supported by the server.

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#6

Just wanted to add my two cents...

When updating the register code, we explicitly chose to try connecting in this order: TLS, TCP, UDP [...]

I would suggest the following order:

1. TLS - best option (secure)
2. UDP - second best (no difference compared to TCP from Client -
Jitsi point of view, better option from Server - Service Provider
point of view - no need to keep "expensive" TCP connections open for
each connected client)
3. TCP - third best (not secure, "expensive" persistent connections to
the client need to be maintained on the server)

Best regards,
Chris


#7

Hey Chris,

На 21.09.11 19:24, Chris Maciejewski написа:

Just wanted to add my two cents...

When updating the register code, we explicitly chose to try connecting in this order: TLS, TCP, UDP [...]

I would suggest the following order:

1. TLS - best option (secure)

Agreed.

2. UDP - second best (no difference compared to TCP from Client -
Jitsi point of view, better option from Server - Service Provider
point of view - no need to keep "expensive" TCP connections open for
each connected client)

Well, UDP is increasingly incompatible with Jitsi's requirements. A
typical INVITE generated by Jitsi would almost always go way above 1500
bytes. This means that IP packets would almost always be fragmented and
there is a significant number of gateways and networks that would drop
IP fragments.

3. TCP - third best (not secure, "expensive" persistent connections to
the client need to be maintained on the server)

Note that services such as GTalk and Facebook are running XMPP servers
for hundreds of millions and don't seem to have issues with TCP. Of
course, the same is valid for most of today's web applications.

All in all, I think you are being a bit too harsh with TCP.

That said, if for some reason a provider has a problem with it, all they
need to do is remove it from their DNS SRV declarations or simply point
their NAPTR record to UDP. Jitsi would of course comply.

Does this make sense?

Emil