[jitsi-users] SIP outgoing call are working but incoming calls...


#1

Hello,

I configured jitsi for SIP and I'm able to use it for calling other SIP
accounts (outgoing). However, when I receive a SIP call (incoming), the
call is signaled/ringing, but the (real, bidirectional, audio)
connection can't be established.

I wonder if this is a firewall problem, as I'm using a AVM FritzBox as
DSL router, that is a SIP endpoint in it own rights (i.e. it listens to
5060 on the internet). What is the way to change the INCOMING SIP port
in jitsi???

Kind regards,

Thomas

PS:
I'm using Jitsi 2.5.5057 (dev). On standard out I seeing the following
from time to time but it is NOT directly related to the connection problem:

16:23:07.234 Schwerwiegend: [1973]
service.protocol.AbstractProtocolProviderService.fireRegistrationStateChanged().165
An error occurred while executing
RegistrationStateChangeListener#registrationStateChanged(RegistrationStateChangeEvent)
of ProtocolProviderServiceSipImpl(032229960187 (personal-voip) (SIP))
java.lang.NullPointerException
        at
net.java.sip.communicator.impl.protocol.sip.SipStackSharing.stopListening(SipStackSharing.java:392)
        at
net.java.sip.communicator.impl.protocol.sip.SipStackSharing.removeSipListener(SipStackSharing.java:185)
        at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.registrationStateChanged(ProtocolProviderServiceSipImpl.java:2466)
        at
net.java.sip.communicator.service.protocol.AbstractProtocolProviderService.fireRegistrationStateChanged(AbstractProtocolProviderService.java:151)
        at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.setRegistrationState(SipRegistrarConnection.java:679)
        at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.register(SipRegistrarConnection.java:283)
        at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.registerUsingNextAddress(ProtocolProviderServiceSipImpl.java:2580)
        at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.register(ProtocolProviderServiceSipImpl.java:338)
        at
net.java.sip.communicator.plugin.reconnectplugin.ReconnectPluginActivator$ReconnectTask.run(ReconnectPluginActivator.java:949)
        at java.lang.Thread.run(Thread.java:744)
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.registerUsingNextAddress(ProtocolProviderServiceSipImpl.java:2580)
        at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.register(ProtocolProviderServiceSipImpl.java:338)
        at
net.java.sip.communicator.plugin.reconnectplugin.ReconnectPluginActivator$ReconnectTask.run(ReconnectPluginActivator.java:949)
        at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.NullPointerException
        at
gov.nist.javax.sip.SipProviderImpl.getNewCallId(SipProviderImpl.java:262)
        at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.register(SipRegistrarConnection.java:255)
        ... 4 more


#2

I configured jitsi for SIP and I'm able to use it for calling other SIP
accounts (outgoing). However, when I receive a SIP call (incoming), the
call is signaled/ringing, but the (real, bidirectional, audio)
connection can't be established.

Do you have a firewall on your computer that blocks UDP somehow? Otherwise
this is hard to tell, especially when outgoing calls work. The full logs
(https://jitsi.org/logs) might give a clue.

I wonder if this is a firewall problem, as I'm using a AVM FritzBox as
DSL router, that is a SIP endpoint in it own rights (i.e. it listens to
5060 on the internet).

I'm using a FritzBox too (with active SIP account on it), so you can exclude
it from being the problem.

What is the way to change the INCOMING SIP port
in jitsi???

Tools->Options->Advanced->SIP
But unless you are using a registrar-less account, this doesn't matter.

Kind regards,
Thomas

PS:
I'm using Jitsi 2.5.5057 (dev). On standard out I seeing the following
from time to time but it is NOT directly related to the connection

problem:

Should be fixed, in 5058.

Ingo


#3

Dear Ingo,

here is the log. Could you make sense of that?

Cheers,

Thomas

16:52:13.821 Information: [47] impl.gui.UIServiceImpl.serviceChanged().1075 Handling registration of a new Plugin Compon
ent.
16:52:13.822 Information: [47] plugin.branding.BrandingActivator.registerMenuEntryNonMacOSX().260 CHAT ABOUT WINDOW ...
[REGISTERED]
16:52:13.823 Information: [47] impl.gui.GuiActivator.run().191 UI Service ...[REGISTERED]
16:52:13.865 Information: [40] impl.gui.main.account.AccountRegWizardContainerImpl.serviceChanged().348 Handling registr
ation of a new Account Wizard.
16:52:13.971 Information: [30] org.jitsi.impl.neomedia.transform.zrtp.ZrtpFortunaEntropyGatherer.info() GatherEntropy go
t: 176400 bytes
16:53:10.102 Information: [72] plugin.reconnectplugin.ReconnectPluginActivator.run().610 Reconnect 032229960187 (persona
l-voip) (SIP) after 2000 ms.
16:53:10.106 Information: [35] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack tim
er gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
16:53:11.107 Information: [35] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack tim
er gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
16:53:12.103 Information: [73] plugin.reconnectplugin.ReconnectPluginActivator.run().946 Start reconnecting 032229960187
(personal-voip) (SIP)
16:53:12.111 Information: [73] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack tim
er gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
16:53:22.605 Schwerwiegend: [97] impl.protocol.sip.SipStackSharing.findTargetFor().846 no listeners
16:53:22.605 Schwerwiegend: [97] impl.protocol.sip.SipStackSharing.processRequest().634 couldn't find a ProtocolProvider
ServiceSipImpl to dispatch to
16:53:23.709 Information: [103] util.NetworkUtils.tryRange().123 Ignoring invalid port range [null to null]
16:53:23.709 Information: [103] util.NetworkUtils.createTracker().213 Ignoring invalid port range [null to null]
16:53:23.709 Information: [103] util.NetworkUtils.createTracker().213 Ignoring invalid port range [null to null]
16:53:23.710 Information: [103] util.NetworkUtils.createTracker().213 Ignoring invalid port range [null to null]
16:53:23.805 Information: [103] service.protocol.media.MediaHandler.registerDynamicPTsWithStream().955 Dynamic PT map: 97=rtpmap:-1 iLBC/8000 fmtp:mode=30; 101=rtpmap:-1 telephone-event/8000;
16:53:23.806 Information: [103] service.protocol.media.MediaHandler.registerDynamicPTsWithStream().972 PT overrides []
16:53:44.469 Information: [107] plugin.reconnectplugin.ReconnectPluginActivator.run().610 Reconnect 032229960187 (personal-voip) (SIP) after 5000 ms.
16:53:44.471 Information: [75] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
16:53:45.472 Information: [75] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
16:53:47.230 Information: [108] org.jitsi.impl.neomedia.MediaStreamImpl.info()
Receive stream stats: discarded RTP packets: 0
Receive stream stats: decoded with FEC: 0
16:53:47.235 Schwerwiegend: [108] impl.protocol.sip.CallPeerSipImpl.hangup().1048 Could not determine call peer state!
16:53:49.470 Information: [109] plugin.reconnectplugin.ReconnectPluginActivator.run().946 Start reconnecting 032229960187 (personal-voip) (SIP)
16:53:49.472 Information: [109] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started
16:53:52.713 Schwerwiegend: [124] impl.protocol.sip.SipStackSharing.findTargetFor().846 no listeners
16:53:52.714 Schwerwiegend: [124] impl.protocol.sip.SipStackSharing.processRequest().634 couldn't find a ProtocolProviderServiceSipImpl to dispatch to
16:54:21.965 Information: [126] plugin.reconnectplugin.ReconnectPluginActivator.run().610 Reconnect 032229960187 (personal-voip) (SIP) after 2000 ms.
16:54:21.970 Information: [111] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
16:54:22.972 Information: [111] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been stopped
16:54:23.967 Information: [127] plugin.reconnectplugin.ReconnectPluginActivator.run().946 Start reconnecting 032229960187 (personal-voip) (SIP)
16:54:23.974 Information: [127] impl.protocol.sip.SipLogger.logInfo().185 Info from the JAIN-SIP stack: the sip stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started

···

On 25.01.2014 16:35, Ingo Bauersachs wrote:

I configured jitsi for SIP and I'm able to use it for calling other SIP
accounts (outgoing). However, when I receive a SIP call (incoming), the
call is signaled/ringing, but the (real, bidirectional, audio)
connection can't be established.

Do you have a firewall on your computer that blocks UDP somehow? Otherwise
this is hard to tell, especially when outgoing calls work. The full logs
(https://jitsi.org/logs) might give a clue.

I wonder if this is a firewall problem, as I'm using a AVM FritzBox as
DSL router, that is a SIP endpoint in it own rights (i.e. it listens to
5060 on the internet).

I'm using a FritzBox too (with active SIP account on it), so you can exclude
it from being the problem.

What is the way to change the INCOMING SIP port
in jitsi???

Tools->Options->Advanced->SIP
But unless you are using a registrar-less account, this doesn't matter.

Kind regards,
Thomas

PS:
I'm using Jitsi 2.5.5057 (dev). On standard out I seeing the following
from time to time but it is NOT directly related to the connection

problem:

Should be fixed, in 5058.

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

here is the log. Could you make sense of that?

Is personal-voip your VoIP provider? If so, how did you configure the
account? In the SIP account wizard, you need to enter a domain, e.g.
032229960187@personal-voip.de.

Cheers,
Thomas

Ingo


#5

Nothing fancy. I just used my SIP account name (a number provided by my
SIP provider that appears under 'SIP-Kennung' in jitsi)

12******@personal-voip.de

and my password.

I can't see anything like 'domain' for configuration....

···

On 25.01.2014 17:13, Ingo Bauersachs wrote:

here is the log. Could you make sense of that?

Is personal-voip your VoIP provider? If so, how did you configure the
account? In the SIP account wizard, you need to enter a domain, e.g.
032229960187@personal-voip.de.

Cheers,
Thomas

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#6

Well,

after diving down a bit into the technical details, I consider this a
problem of establishing the (2) RTP connections after the (successful)
negotiation of connection details by the SIP protocol. In short, it
indicates a firewall problem.

I'm not sure, but I guess when calling, RTP (UDP) ports are defined and
the connection is established by my (jitsi) client. In contrast to that,
incoming calls indicate the RTP (UDP) ports to use and trying to
establish the RTP connection from the outside/internet. As normal DSL
routers allow all *outgoing* connections, outgoing calls are working,
whereas the attempt to connect to the (SIP defined) RTP (UDP) port(s)
*from* outside fails.

How to avoid the problem? I guess there are a few options, but I have no
idea if jitsi supports one of them. Can someone comment on this?

* STUN would NOT change the game, as SIP is working.

* If there was an option to define a RTP port range to use in jitsi,
incoming RTP connections could be routed to the right host by the DSL
router. Incoming calls would work, but only if the DSL router was
configured accordingly, and the port range was different on any jitsi
client behind the firewall/router.

* If there was an option in jitsi to publish negotiated (incoming) RTP
ports by UPnP, the DSL router could be configured to open ports on UPnP
requests. Incoming calls would work, but only if the DSL router accepted
UPnP Port forwarding requests.

* Use a SIP Session Border Controller (Proxy) *with* RTP routing support
on the router or an 'exposed' host behind the firewall. Incoming calls
would work, if jitsi could be configured to use the proxy and the DSL
router is configured to expose the host with the proxy.

* Use some sort of (incoming) UDP NAT tunneling, for example ICE
(Interactive Connectivity Establishment). I have no idea who of the
participants (jitsi, SIP provider, outside SIP client) must adhere/know
to this specification to make this work, though.

Kind regards,

Thomas

···

On 25.01.2014 17:24, Thomas Pasch wrote:

Nothing fancy. I just used my SIP account name (a number provided by my
SIP provider that appears under 'SIP-Kennung' in jitsi)

12******@personal-voip.de

and my password.

I can't see anything like 'domain' for configuration....

On 25.01.2014 17:13, Ingo Bauersachs wrote:

here is the log. Could you make sense of that?

Is personal-voip your VoIP provider? If so, how did you configure the
account? In the SIP account wizard, you need to enter a domain, e.g.
032229960187@personal-voip.de.

Cheers,
Thomas

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#7

Well,

after diving down a bit into the technical details, I consider this a
problem of establishing the (2) RTP connections after the (successful)
negotiation of connection details by the SIP protocol. In short, it
indicates a firewall problem.

I'm not sure, but I guess when calling, RTP (UDP) ports are defined and
the connection is established by my (jitsi) client. In contrast to that,
incoming calls indicate the RTP (UDP) ports to use and trying to
establish the RTP connection from the outside/internet. As normal DSL
routers allow all *outgoing* connections, outgoing calls are working,
whereas the attempt to connect to the (SIP defined) RTP (UDP) port(s)
*from* outside fails.

It is worth noting that as far as RTP flows are concerned, the
initiator of the call would make no difference. RTP would flow both
ways in each situation and ports would assigned in the same manner
regardless of who made the SDP Offer.

How to avoid the problem?

You seem to have sent your logs privately to Ingo so I am not sure
exactly what the problem is. Ingo's response indicates that Jitsi's
200 OK might either be lost on its way to the server or the server
might be choking while processing it. Either way you don't have a lot
of options. To confirm that this is indeed a provider issue, could you
please try creating an account at ippi.com and see if you can
reproduce the issue there?

Emil

···

On Tue, Jan 28, 2014 at 8:38 PM, Thomas Pasch <thomas.pasch@gmx.de> wrote:

--
https://jitsi.org


#8

Well,

after diving down a bit into the technical details, I consider this a
problem of establishing the (2) RTP connections after the (successful)
negotiation of connection details by the SIP protocol. In short, it
indicates a firewall problem.

I'm not sure, but I guess when calling, RTP (UDP) ports are defined and
the connection is established by my (jitsi) client. In contrast to that,
incoming calls indicate the RTP (UDP) ports to use and trying to
establish the RTP connection from the outside/internet. As normal DSL
routers allow all *outgoing* connections, outgoing calls are working,
whereas the attempt to connect to the (SIP defined) RTP (UDP) port(s)
*from* outside fails.

It is worth noting that as far as RTP flows are concerned, the
initiator of the call would make no difference. RTP would flow both
ways in each situation and ports would assigned in the same manner
regardless of who made the SDP Offer.

How to avoid the problem?

You seem to have sent your logs privately to Ingo so I am not sure
exactly what the problem is. Ingo's response indicates that Jitsi's
200 OK might either be lost on its way to the server or the server
might be choking while processing it. Either way you don't have a lot
of options. To confirm that this is a server-side issue, could you
please create an account at ippi.com and see if it works better there?

Emil

···

On Tue, Jan 28, 2014 at 8:38 PM, Thomas Pasch <thomas.pasch@gmx.de> wrote:

I guess there are a few options, but I have no
idea if jitsi supports one of them. Can someone comment on this?

* STUN would NOT change the game, as SIP is working.

* If there was an option to define a RTP port range to use in jitsi,
incoming RTP connections could be routed to the right host by the DSL
router. Incoming calls would work, but only if the DSL router was
configured accordingly, and the port range was different on any jitsi
client behind the firewall/router.

* If there was an option in jitsi to publish negotiated (incoming) RTP
ports by UPnP, the DSL router could be configured to open ports on UPnP
requests. Incoming calls would work, but only if the DSL router accepted
UPnP Port forwarding requests.

* Use a SIP Session Border Controller (Proxy) *with* RTP routing support
on the router or an 'exposed' host behind the firewall. Incoming calls
would work, if jitsi could be configured to use the proxy and the DSL
router is configured to expose the host with the proxy.

* Use some sort of (incoming) UDP NAT tunneling, for example ICE
(Interactive Connectivity Establishment). I have no idea who of the
participants (jitsi, SIP provider, outside SIP client) must adhere/know
to this specification to make this work, though.

Kind regards,

Thomas

On 25.01.2014 17:24, Thomas Pasch wrote:

Nothing fancy. I just used my SIP account name (a number provided by my
SIP provider that appears under 'SIP-Kennung' in jitsi)

12******@personal-voip.de

and my password.

I can't see anything like 'domain' for configuration....

On 25.01.2014 17:13, Ingo Bauersachs wrote:

here is the log. Could you make sense of that?

Is personal-voip your VoIP provider? If so, how did you configure the
account? In the SIP account wizard, you need to enter a domain, e.g.
032229960187@personal-voip.de.

Cheers,
Thomas

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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


#9

As it is for the greater glory of jitsi, these are the logs I sent to
Ingo before...

A test with ippi.com will follow in a few days.

Kind regards,

Thomas

2014-01-25@17.04.12-logs.zip (9.49 KB)

···

On 29.01.2014 10:38, Emil Ivov wrote:

On Tue, Jan 28, 2014 at 8:38 PM, Thomas Pasch <thomas.pasch@gmx.de> wrote:

Well,

after diving down a bit into the technical details, I consider this a
problem of establishing the (2) RTP connections after the (successful)
negotiation of connection details by the SIP protocol. In short, it
indicates a firewall problem.

I'm not sure, but I guess when calling, RTP (UDP) ports are defined and
the connection is established by my (jitsi) client. In contrast to that,
incoming calls indicate the RTP (UDP) ports to use and trying to
establish the RTP connection from the outside/internet. As normal DSL
routers allow all *outgoing* connections, outgoing calls are working,
whereas the attempt to connect to the (SIP defined) RTP (UDP) port(s)
*from* outside fails.

It is worth noting that as far as RTP flows are concerned, the
initiator of the call would make no difference. RTP would flow both
ways in each situation and ports would assigned in the same manner
regardless of who made the SDP Offer.

How to avoid the problem?

You seem to have sent your logs privately to Ingo so I am not sure
exactly what the problem is. Ingo's response indicates that Jitsi's
200 OK might either be lost on its way to the server or the server
might be choking while processing it. Either way you don't have a lot
of options. To confirm that this is a server-side issue, could you
please create an account at ippi.com and see if it works better there?

Emil

I guess there are a few options, but I have no
idea if jitsi supports one of them. Can someone comment on this?

* STUN would NOT change the game, as SIP is working.

* If there was an option to define a RTP port range to use in jitsi,
incoming RTP connections could be routed to the right host by the DSL
router. Incoming calls would work, but only if the DSL router was
configured accordingly, and the port range was different on any jitsi
client behind the firewall/router.

* If there was an option in jitsi to publish negotiated (incoming) RTP
ports by UPnP, the DSL router could be configured to open ports on UPnP
requests. Incoming calls would work, but only if the DSL router accepted
UPnP Port forwarding requests.

* Use a SIP Session Border Controller (Proxy) *with* RTP routing support
on the router or an 'exposed' host behind the firewall. Incoming calls
would work, if jitsi could be configured to use the proxy and the DSL
router is configured to expose the host with the proxy.

* Use some sort of (incoming) UDP NAT tunneling, for example ICE
(Interactive Connectivity Establishment). I have no idea who of the
participants (jitsi, SIP provider, outside SIP client) must adhere/know
to this specification to make this work, though.

Kind regards,

Thomas

On 25.01.2014 17:24, Thomas Pasch wrote:

Nothing fancy. I just used my SIP account name (a number provided by my
SIP provider that appears under 'SIP-Kennung' in jitsi)

12******@personal-voip.de

and my password.

I can't see anything like 'domain' for configuration....

On 25.01.2014 17:13, Ingo Bauersachs wrote:

here is the log. Could you make sense of that?

Is personal-voip your VoIP provider? If so, how did you configure the
account? In the SIP account wizard, you need to enter a domain, e.g.
032229960187@personal-voip.de.

Cheers,
Thomas

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#10

I confirm Ingo's findings. Your provider does not seem to be sending
an ACK (either that or there's a bug in Jitsi's / JSIP's packet
logging). Trying out with ippi should help clear that out.

Emil

···

On Wed, Jan 29, 2014 at 10:58 AM, Thomas Pasch <thomas.pasch@gmx.de> wrote:

As it is for the greater glory of jitsi, these are the logs I sent to
Ingo before...

A test with ippi.com will follow in a few days.

Kind regards,

Thomas

On 29.01.2014 10:38, Emil Ivov wrote:

On Tue, Jan 28, 2014 at 8:38 PM, Thomas Pasch <thomas.pasch@gmx.de> wrote:

Well,

after diving down a bit into the technical details, I consider this a
problem of establishing the (2) RTP connections after the (successful)
negotiation of connection details by the SIP protocol. In short, it
indicates a firewall problem.

I'm not sure, but I guess when calling, RTP (UDP) ports are defined and
the connection is established by my (jitsi) client. In contrast to that,
incoming calls indicate the RTP (UDP) ports to use and trying to
establish the RTP connection from the outside/internet. As normal DSL
routers allow all *outgoing* connections, outgoing calls are working,
whereas the attempt to connect to the (SIP defined) RTP (UDP) port(s)
*from* outside fails.

It is worth noting that as far as RTP flows are concerned, the
initiator of the call would make no difference. RTP would flow both
ways in each situation and ports would assigned in the same manner
regardless of who made the SDP Offer.

How to avoid the problem?

You seem to have sent your logs privately to Ingo so I am not sure
exactly what the problem is. Ingo's response indicates that Jitsi's
200 OK might either be lost on its way to the server or the server
might be choking while processing it. Either way you don't have a lot
of options. To confirm that this is a server-side issue, could you
please create an account at ippi.com and see if it works better there?

Emil

I guess there are a few options, but I have no
idea if jitsi supports one of them. Can someone comment on this?

* STUN would NOT change the game, as SIP is working.

* If there was an option to define a RTP port range to use in jitsi,
incoming RTP connections could be routed to the right host by the DSL
router. Incoming calls would work, but only if the DSL router was
configured accordingly, and the port range was different on any jitsi
client behind the firewall/router.

* If there was an option in jitsi to publish negotiated (incoming) RTP
ports by UPnP, the DSL router could be configured to open ports on UPnP
requests. Incoming calls would work, but only if the DSL router accepted
UPnP Port forwarding requests.

* Use a SIP Session Border Controller (Proxy) *with* RTP routing support
on the router or an 'exposed' host behind the firewall. Incoming calls
would work, if jitsi could be configured to use the proxy and the DSL
router is configured to expose the host with the proxy.

* Use some sort of (incoming) UDP NAT tunneling, for example ICE
(Interactive Connectivity Establishment). I have no idea who of the
participants (jitsi, SIP provider, outside SIP client) must adhere/know
to this specification to make this work, though.

Kind regards,

Thomas

On 25.01.2014 17:24, Thomas Pasch wrote:

Nothing fancy. I just used my SIP account name (a number provided by my
SIP provider that appears under 'SIP-Kennung' in jitsi)

12******@personal-voip.de

and my password.

I can't see anything like 'domain' for configuration....

On 25.01.2014 17:13, Ingo Bauersachs wrote:

here is the log. Could you make sense of that?

Is personal-voip your VoIP provider? If so, how did you configure the
account? In the SIP account wizard, you need to enter a domain, e.g.
032229960187@personal-voip.de.

Cheers,
Thomas

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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


#11

Hello,

I could now confirm that this is likely to be a problem of my Voip/Sip
Provider (pbx-network.de/personal-voip.de). Please find enclosed a log.
It contains 2 _incoming_ calls, one to 03222... on personal-voip.de. The
call is signaled/ringing, but audio connection fails.

The 2nd call is to 00883510... on ippi.fr. This call succeeds without
any problem.

I'm going to indicate the problem to the support team of
personal-voip.de. Can someone sum up what is the problem, i.e. which
part of the SIP specification they violate?

Kind regards,

Thomas

2014-01-31@18.09.46-logs.zip (16.5 KB)

···

On 29.01.2014 12:08, Emil Ivov wrote:

I confirm Ingo's findings. Your provider does not seem to be sending
an ACK (either that or there's a bug in Jitsi's / JSIP's packet
logging). Trying out with ippi should help clear that out.

Emil

On Wed, Jan 29, 2014 at 10:58 AM, Thomas Pasch <thomas.pasch@gmx.de> wrote:

As it is for the greater glory of jitsi, these are the logs I sent to
Ingo before...

A test with ippi.com will follow in a few days.

Kind regards,

Thomas

On 29.01.2014 10:38, Emil Ivov wrote:

On Tue, Jan 28, 2014 at 8:38 PM, Thomas Pasch <thomas.pasch@gmx.de> wrote:

Well,

after diving down a bit into the technical details, I consider this a
problem of establishing the (2) RTP connections after the (successful)
negotiation of connection details by the SIP protocol. In short, it
indicates a firewall problem.

I'm not sure, but I guess when calling, RTP (UDP) ports are defined and
the connection is established by my (jitsi) client. In contrast to that,
incoming calls indicate the RTP (UDP) ports to use and trying to
establish the RTP connection from the outside/internet. As normal DSL
routers allow all *outgoing* connections, outgoing calls are working,
whereas the attempt to connect to the (SIP defined) RTP (UDP) port(s)
*from* outside fails.

It is worth noting that as far as RTP flows are concerned, the
initiator of the call would make no difference. RTP would flow both
ways in each situation and ports would assigned in the same manner
regardless of who made the SDP Offer.

How to avoid the problem?

You seem to have sent your logs privately to Ingo so I am not sure
exactly what the problem is. Ingo's response indicates that Jitsi's
200 OK might either be lost on its way to the server or the server
might be choking while processing it. Either way you don't have a lot
of options. To confirm that this is a server-side issue, could you
please create an account at ippi.com and see if it works better there?

Emil

I guess there are a few options, but I have no
idea if jitsi supports one of them. Can someone comment on this?

* STUN would NOT change the game, as SIP is working.

* If there was an option to define a RTP port range to use in jitsi,
incoming RTP connections could be routed to the right host by the DSL
router. Incoming calls would work, but only if the DSL router was
configured accordingly, and the port range was different on any jitsi
client behind the firewall/router.

* If there was an option in jitsi to publish negotiated (incoming) RTP
ports by UPnP, the DSL router could be configured to open ports on UPnP
requests. Incoming calls would work, but only if the DSL router accepted
UPnP Port forwarding requests.

* Use a SIP Session Border Controller (Proxy) *with* RTP routing support
on the router or an 'exposed' host behind the firewall. Incoming calls
would work, if jitsi could be configured to use the proxy and the DSL
router is configured to expose the host with the proxy.

* Use some sort of (incoming) UDP NAT tunneling, for example ICE
(Interactive Connectivity Establishment). I have no idea who of the
participants (jitsi, SIP provider, outside SIP client) must adhere/know
to this specification to make this work, though.

Kind regards,

Thomas

On 25.01.2014 17:24, Thomas Pasch wrote:

Nothing fancy. I just used my SIP account name (a number provided by my
SIP provider that appears under 'SIP-Kennung' in jitsi)

12******@personal-voip.de

and my password.

I can't see anything like 'domain' for configuration....

On 25.01.2014 17:13, Ingo Bauersachs wrote:

here is the log. Could you make sense of that?

Is personal-voip your VoIP provider? If so, how did you configure the
account? In the SIP account wizard, you need to enter a domain, e.g.
032229960187@personal-voip.de.

Cheers,
Thomas

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#12

Hey Thomas,

You can just tell them that they are not sending the ACKs in client INVITE
transactions.

Emil

--sent from my mobile

···

On 31 Jan 2014 6:19 PM, "Thomas Pasch" <thomas.pasch@gmx.de> wrote:

Hello,

I could now confirm that this is likely to be a problem of my Voip/Sip
Provider (pbx-network.de/personal-voip.de). Please find enclosed a log.
It contains 2 _incoming_ calls, one to 03222... on personal-voip.de. The
call is signaled/ringing, but audio connection fails.

The 2nd call is to 00883510... on ippi.fr. This call succeeds without
any problem.

I'm going to indicate the problem to the support team of
personal-voip.de. Can someone sum up what is the problem, i.e. which
part of the SIP specification they violate?

Kind regards,

Thomas

On 29.01.2014 12:08, Emil Ivov wrote:
> I confirm Ingo's findings. Your provider does not seem to be sending
> an ACK (either that or there's a bug in Jitsi's / JSIP's packet
> logging). Trying out with ippi should help clear that out.
>
> Emil
>
> On Wed, Jan 29, 2014 at 10:58 AM, Thomas Pasch <thomas.pasch@gmx.de> > wrote:
>> As it is for the greater glory of jitsi, these are the logs I sent to
>> Ingo before...
>>
>> A test with ippi.com will follow in a few days.
>>
>> Kind regards,
>>
>> Thomas
>>
>> On 29.01.2014 10:38, Emil Ivov wrote:
>>> On Tue, Jan 28, 2014 at 8:38 PM, Thomas Pasch <thomas.pasch@gmx.de> > wrote:
>>>> Well,
>>>>
>>>> after diving down a bit into the technical details, I consider this a
>>>> problem of establishing the (2) RTP connections after the (successful)
>>>> negotiation of connection details by the SIP protocol. In short, it
>>>> indicates a firewall problem.
>>>>
>>>> I'm not sure, but I guess when calling, RTP (UDP) ports are defined
and
>>>> the connection is established by my (jitsi) client. In contrast to
that,
>>>> incoming calls indicate the RTP (UDP) ports to use and trying to
>>>> establish the RTP connection from the outside/internet. As normal DSL
>>>> routers allow all *outgoing* connections, outgoing calls are working,
>>>> whereas the attempt to connect to the (SIP defined) RTP (UDP) port(s)
>>>> *from* outside fails.
>>> It is worth noting that as far as RTP flows are concerned, the
>>> initiator of the call would make no difference. RTP would flow both
>>> ways in each situation and ports would assigned in the same manner
>>> regardless of who made the SDP Offer.
>>>
>>>> How to avoid the problem?
>>> You seem to have sent your logs privately to Ingo so I am not sure
>>> exactly what the problem is. Ingo's response indicates that Jitsi's
>>> 200 OK might either be lost on its way to the server or the server
>>> might be choking while processing it. Either way you don't have a lot
>>> of options. To confirm that this is a server-side issue, could you
>>> please create an account at ippi.com and see if it works better there?
>>>
>>> Emil
>>>
>>>> I guess there are a few options, but I have no
>>>> idea if jitsi supports one of them. Can someone comment on this?
>>>>
>>>> * STUN would NOT change the game, as SIP is working.
>>>>
>>>> * If there was an option to define a RTP port range to use in jitsi,
>>>> incoming RTP connections could be routed to the right host by the DSL
>>>> router. Incoming calls would work, but only if the DSL router was
>>>> configured accordingly, and the port range was different on any jitsi
>>>> client behind the firewall/router.
>>>>
>>>> * If there was an option in jitsi to publish negotiated (incoming) RTP
>>>> ports by UPnP, the DSL router could be configured to open ports on
UPnP
>>>> requests. Incoming calls would work, but only if the DSL router
accepted
>>>> UPnP Port forwarding requests.
>>>>
>>>> * Use a SIP Session Border Controller (Proxy) *with* RTP routing
support
>>>> on the router or an 'exposed' host behind the firewall. Incoming calls
>>>> would work, if jitsi could be configured to use the proxy and the DSL
>>>> router is configured to expose the host with the proxy.
>>>>
>>>> * Use some sort of (incoming) UDP NAT tunneling, for example ICE
>>>> (Interactive Connectivity Establishment). I have no idea who of the
>>>> participants (jitsi, SIP provider, outside SIP client) must
adhere/know
>>>> to this specification to make this work, though.
>>>>
>>>> Kind regards,
>>>>
>>>> Thomas
>>>>
>>>>
>>>> On 25.01.2014 17:24, Thomas Pasch wrote:
>>>>> Nothing fancy. I just used my SIP account name (a number provided by
my
>>>>> SIP provider that appears under 'SIP-Kennung' in jitsi)
>>>>>
>>>>> 12******@personal-voip.de
>>>>>
>>>>> and my password.
>>>>>
>>>>> I can't see anything like 'domain' for configuration....
>>>>>
>>>>> On 25.01.2014 17:13, Ingo Bauersachs wrote:
>>>>>>> here is the log. Could you make sense of that?
>>>>>> Is personal-voip your VoIP provider? If so, how did you configure
the
>>>>>> account? In the SIP account wizard, you need to enter a domain, e.g.
>>>>>> 032229960187@personal-voip.de.
>>>>>>
>>>>>>> Cheers,
>>>>>>> Thomas
>>>>>> Ingo
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> users mailing list
>>>>>> users@jitsi.org
>>>>>> Unsubscribe instructions and other list options:
>>>>>> http://lists.jitsi.org/mailman/listinfo/users
>>>>> _______________________________________________
>>>>> users mailing list
>>>>> users@jitsi.org
>>>>> Unsubscribe instructions and other list options:
>>>>> http://lists.jitsi.org/mailman/listinfo/users
>>>> _______________________________________________
>>>> users mailing list
>>>> users@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/users
>>>
>>
>> _______________________________________________
>> users mailing list
>> users@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/users
>
>

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users