[jitsi-dev] JITSI does not re-use the existing TLS connection to send IN-DIALOG requests in SIP


#1

Hi,
we try to use the TLS protocol with Jitsi in the SIP/SIMPLE
environment. And the Servers are behind NAT and can be reached via an
outbound proxy only. We configure the proxy to point the outbound
proxy. Everything is OK for UDP/TCP until we try to use TLS protocol.
With TLS, all INITIAL REQUESTs (REGISTER/MESSAGE/PUBLISH/SUBSCRIBE(not
in-dialog) go through outbound proxy and everything is ok. But we
found the problems for the in-dialog requests like:
- re SUBSCRIBE (in-dialog)
- ACK for the call (INVITE, 200 OK ...)
- BYE for the call

for these in-dialog requests, it seems iitsi does not send them to the
outbound proxy even the protocol is TLS, and fail with the following
error:

SEVERE: impl.protocol.sip.EventPackageSubscriber.run().1317 Can't
send the request
javax.sip.SipException: error sending message
  at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2690)
  at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2465)
  at net.java.sip.communicator.impl.protocol.sip.EventPackageSubscriber$SubscriptionRefreshTask.run(EventPackageSubscriber.java:1313)
  at java.util.TimerThread.mainLoop(Unknown Source)
  at java.util.TimerThread.run(Unknown Source)
Caused by: java.io.IOException: The provider that requested the SSL
Socket could not be found
  at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.getSSLSocketFactory(SslNetworkLayer.java:180)
  at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.createSSLSocket(SslNetworkLayer.java:257)
  at gov.nist.javax.sip.stack.IOHandler.sendBytes(IOHandler.java:466)
  at gov.nist.javax.sip.stack.TLSMessageChannel.sendMessage(TLSMessageChannel.java:374)
  at gov.nist.javax.sip.stack.MessageChannel.sendMessage(MessageChannel.java:281)
  at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:855)
  at gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:489)
  at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2672)

I don't know if it's a bug. But is it possible to force Jitsi to
always use outbound proxy for all outgoing messages that include also
in-dialog requests? This will be very useful for the far-end
Firewall/NAT traversal.

Thanks in advanced

Best Regards,
Laura


#2

Hi Emil,
please find the log in the attachment. We start Jitsi and register to
SIP server at 10:16 with TLS. the client can chat (MESSAGE) and
exchange presence status with others. The expire time for the
registration and subscription (presence) in the server is configured
about 10 minutes. In fact, after 10 minutes, the presence does not
work anymore because Jitsi fail to renew the subscription (in-dialog
SUBSCRIBE for the previous subscription). But others can still see my
status because it can still renew the registration (REGISTER is always
initial request and is sent to outbound proxy) and PUBLISH the
presence status (PUBLISH is always initial request and is sent to
outvound proxy). In fact, after more or less 10 minutes, the serer
does not receive further SUBSCRIBE anymore from my PC, but only
REGISTER and PUBLISH if I change the presence status from my Jitsi.

The same thing happen if I initiate an audio/video call, the sever
receive INVITE and send back the answer 200 OK from called party to
me, but does not receive ACK from my JITSI (ACK is an in-dialog
request too).

I think the problem could be the Record_Route received from 200/202 OK
by Jitsi, it use the first top Route built from Record_Route to send
the further in-dialog request instead of outbound proxy. In TCP and
UDP, it's OK because the static NAT can convert the proxy private
address to the corresponding public address, so the record_route
received by Jitsi from 200/202 OK contains the public address of the
Proxy. When in TLS, the NAT can not convert the private address to
public address because it's SSL, so the record_route received by Jitsi
from 200/202 OK (for INVITE/SUBSCRIBE) contains the private address of
the proxy. When Jitsi try to build the connection to that for
in-dialog request, it fails.

If Jitsi could always send the Request to the outbound proxy (initial
and in-dialog request), it may help the situation in the TLS protocol.

Thanks again.

Best Regards,
Laura

sip-communicator0.log.0 (53.3 KB)

···

On Wed, Oct 19, 2011 at 4:05 PM, Emil Ivov <emcho@jitsi.org> wrote:

Laura,

Could you please send complete logs from a session where the problem occurs?

Emil

--sent from my mobile

On 19 oct. 2011, at 15:55, laura testi <lau.testi@gmail.com> wrote:

Hi,
we try to use the TLS protocol with Jitsi in the SIP/SIMPLE
environment. And the Servers are behind NAT and can be reached via an
outbound proxy only. We configure the proxy to point the outbound
proxy. Everything is OK for UDP/TCP until we try to use TLS protocol.
With TLS, all INITIAL REQUESTs (REGISTER/MESSAGE/PUBLISH/SUBSCRIBE(not
in-dialog) go through outbound proxy and everything is ok. But we
found the problems for the in-dialog requests like:
- re SUBSCRIBE (in-dialog)
- ACK for the call (INVITE, 200 OK ...)
- BYE for the call

for these in-dialog requests, it seems iitsi does not send them to the
outbound proxy even the protocol is TLS, and fail with the following
error:

SEVERE: impl.protocol.sip.EventPackageSubscriber.run().1317 Can't
send the request
javax.sip.SipException: error sending message
at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2690)
at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2465)
at net.java.sip.communicator.impl.protocol.sip.EventPackageSubscriber$SubscriptionRefreshTask.run(EventPackageSubscriber.java:1313)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
Caused by: java.io.IOException: The provider that requested the SSL
Socket could not be found
at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.getSSLSocketFactory(SslNetworkLayer.java:180)
at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.createSSLSocket(SslNetworkLayer.java:257)
at gov.nist.javax.sip.stack.IOHandler.sendBytes(IOHandler.java:466)
at gov.nist.javax.sip.stack.TLSMessageChannel.sendMessage(TLSMessageChannel.java:374)
at gov.nist.javax.sip.stack.MessageChannel.sendMessage(MessageChannel.java:281)
at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:855)
at gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:489)
at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2672)

I don't know if it's a bug. But is it possible to force Jitsi to
always use outbound proxy for all outgoing messages that include also
in-dialog requests? This will be very useful for the far-end
Firewall/NAT traversal.

Thanks in advanced

Best Regards,
Laura


#3

JITSI does not re-use the existing TLS connection to send IN-DIALOG
  requests in SIP

this thing has not been fixed.
the issue remains.

easy test :

Asterisk behind Nat

Jiti client behind Nat, registering using TLS only.

SIMPLE presence activated. The Jitsi client disconnects every 30 seconds.

CONFIDENTIALITY NOTICE - The information contained in this message and any accompanying documents may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.

NOTE DE CONFIDENTIALITE - Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, Ubiqus (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.


#4

Hi Laura,

is it possible to provide us with a test account (using a private
mail:) ) so we can easily test and correct this issue.
The exception in the logs really shows that the message is routed to a
different address than the used outbound proxy.

Thanks
damencho

···

On Thu, Oct 20, 2011 at 12:04 PM, laura testi <lau.testi@gmail.com> wrote:

Hi Emil,
please find the log in the attachment. We start Jitsi and register to
SIP server at 10:16 with TLS. the client can chat (MESSAGE) and
exchange presence status with others. The expire time for the
registration and subscription (presence) in the server is configured
about 10 minutes. In fact, after 10 minutes, the presence does not
work anymore because Jitsi fail to renew the subscription (in-dialog
SUBSCRIBE for the previous subscription). But others can still see my
status because it can still renew the registration (REGISTER is always
initial request and is sent to outbound proxy) and PUBLISH the
presence status (PUBLISH is always initial request and is sent to
outvound proxy). In fact, after more or less 10 minutes, the serer
does not receive further SUBSCRIBE anymore from my PC, but only
REGISTER and PUBLISH if I change the presence status from my Jitsi.

The same thing happen if I initiate an audio/video call, the sever
receive INVITE and send back the answer 200 OK from called party to
me, but does not receive ACK from my JITSI (ACK is an in-dialog
request too).

I think the problem could be the Record_Route received from 200/202 OK
by Jitsi, it use the first top Route built from Record_Route to send
the further in-dialog request instead of outbound proxy. In TCP and
UDP, it's OK because the static NAT can convert the proxy private
address to the corresponding public address, so the record_route
received by Jitsi from 200/202 OK contains the public address of the
Proxy. When in TLS, the NAT can not convert the private address to
public address because it's SSL, so the record_route received by Jitsi
from 200/202 OK (for INVITE/SUBSCRIBE) contains the private address of
the proxy. When Jitsi try to build the connection to that for
in-dialog request, it fails.

If Jitsi could always send the Request to the outbound proxy (initial
and in-dialog request), it may help the situation in the TLS protocol.

Thanks again.

Best Regards,
Laura

On Wed, Oct 19, 2011 at 4:05 PM, Emil Ivov <emcho@jitsi.org> wrote:

Laura,

Could you please send complete logs from a session where the problem occurs?

Emil

--sent from my mobile

On 19 oct. 2011, at 15:55, laura testi <lau.testi@gmail.com> wrote:

Hi,
we try to use the TLS protocol with Jitsi in the SIP/SIMPLE
environment. And the Servers are behind NAT and can be reached via an
outbound proxy only. We configure the proxy to point the outbound
proxy. Everything is OK for UDP/TCP until we try to use TLS protocol.
With TLS, all INITIAL REQUESTs (REGISTER/MESSAGE/PUBLISH/SUBSCRIBE(not
in-dialog) go through outbound proxy and everything is ok. But we
found the problems for the in-dialog requests like:
- re SUBSCRIBE (in-dialog)
- ACK for the call (INVITE, 200 OK ...)
- BYE for the call

for these in-dialog requests, it seems iitsi does not send them to the
outbound proxy even the protocol is TLS, and fail with the following
error:

SEVERE: impl.protocol.sip.EventPackageSubscriber.run().1317 Can't
send the request
javax.sip.SipException: error sending message
at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2690)
at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2465)
at net.java.sip.communicator.impl.protocol.sip.EventPackageSubscriber$SubscriptionRefreshTask.run(EventPackageSubscriber.java:1313)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
Caused by: java.io.IOException: The provider that requested the SSL
Socket could not be found
at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.getSSLSocketFactory(SslNetworkLayer.java:180)
at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.createSSLSocket(SslNetworkLayer.java:257)
at gov.nist.javax.sip.stack.IOHandler.sendBytes(IOHandler.java:466)
at gov.nist.javax.sip.stack.TLSMessageChannel.sendMessage(TLSMessageChannel.java:374)
at gov.nist.javax.sip.stack.MessageChannel.sendMessage(MessageChannel.java:281)
at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:855)
at gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:489)
at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2672)

I don't know if it's a bug. But is it possible to force Jitsi to
always use outbound proxy for all outgoing messages that include also
in-dialog requests? This will be very useful for the far-end
Firewall/NAT traversal.

Thanks in advanced

Best Regards,
Laura


#5

Hi,

···

On Thu, Oct 20, 2011 at 12:04 PM, laura testi <lau.testi@gmail.com> wrote:

I think the problem could be the Record_Route received from 200/202 OK
by Jitsi, it use the first top Route built from Record_Route to send
the further in-dialog request instead of outbound proxy. In TCP and
UDP, it's OK because the static NAT can convert the proxy private
address to the corresponding public address, so the record_route
received by Jitsi from 200/202 OK contains the public address of the
Proxy. When in TLS, the NAT can not convert the private address to
public address because it's SSL, so the record_route received by Jitsi
from 200/202 OK (for INVITE/SUBSCRIBE) contains the private address of
the proxy.

What about removing those record route headers.
Other thing that I think may help is removing lr parameter from those headers.

Regards
damencho


#6

Can't reproduce this at all. Neither the problem described in your
subject line, nor the issue from the content of your mail. Logs might
help but this is likely something related to your environment.

Emil

···

On Tue, Apr 14, 2015 at 10:57 PM, Vincent Nguyen <vnguyen@ubiqus.com> wrote:

JITSI does not re-use the existing TLS connection to send IN-DIALOG requests
in SIP

this thing has not been fixed.
the issue remains.

easy test :

Asterisk behind Nat

Jiti client behind Nat, registering using TLS only.

SIMPLE presence activated. The Jitsi client disconnects every 30 seconds.

CONFIDENTIALITY NOTICE - The information contained in this message and any
accompanying documents may be privileged and confidential and protected from
disclosure. If the reader of this message is not the intended recipient, or
an employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by replying to the
message and deleting it from your computer. Thank you.

NOTE DE CONFIDENTIALITE - Ce message et toutes les pieces jointes (ci-apres
le "message") sont etablis a l'intention exclusive de ses destinataires et
sont confidentiels. Si vous recevez ce message par erreur, merci de le
detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion ou toute publication,
totale ou partielle, est interdite, sauf autorisation expresse. L'internet
ne permettant pas d'assurer l'integrite de ce message, Ubiqus (et ses
filiales) decline(nt) toute responsabilite au titre de ce message, dans
l'hypothese ou il aurait ete modifie.

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

--
https://jitsi.org


#7

Hey Laura,

It is also worth noting that when sending logs for debug we do prefer
having the log zip file as generated by Jitsi rather than a single .log
file.

This is actually what I meant when asking for "complete logs" but I
realize I might have been unclear. For more details please have a look at:

http://jitsi.org/faq/logs

Cheers,
Emil

На 21.10.11 10:06, Damian Minkov написа:

···

Hi Laura,

is it possible to provide us with a test account (using a private
mail:) ) so we can easily test and correct this issue.
The exception in the logs really shows that the message is routed to a
different address than the used outbound proxy.

Thanks
damencho

On Thu, Oct 20, 2011 at 12:04 PM, laura testi <lau.testi@gmail.com> wrote:

Hi Emil,
please find the log in the attachment. We start Jitsi and register to
SIP server at 10:16 with TLS. the client can chat (MESSAGE) and
exchange presence status with others. The expire time for the
registration and subscription (presence) in the server is configured
about 10 minutes. In fact, after 10 minutes, the presence does not
work anymore because Jitsi fail to renew the subscription (in-dialog
SUBSCRIBE for the previous subscription). But others can still see my
status because it can still renew the registration (REGISTER is always
initial request and is sent to outbound proxy) and PUBLISH the
presence status (PUBLISH is always initial request and is sent to
outvound proxy). In fact, after more or less 10 minutes, the serer
does not receive further SUBSCRIBE anymore from my PC, but only
REGISTER and PUBLISH if I change the presence status from my Jitsi.

The same thing happen if I initiate an audio/video call, the sever
receive INVITE and send back the answer 200 OK from called party to
me, but does not receive ACK from my JITSI (ACK is an in-dialog
request too).

I think the problem could be the Record_Route received from 200/202 OK
by Jitsi, it use the first top Route built from Record_Route to send
the further in-dialog request instead of outbound proxy. In TCP and
UDP, it's OK because the static NAT can convert the proxy private
address to the corresponding public address, so the record_route
received by Jitsi from 200/202 OK contains the public address of the
Proxy. When in TLS, the NAT can not convert the private address to
public address because it's SSL, so the record_route received by Jitsi
from 200/202 OK (for INVITE/SUBSCRIBE) contains the private address of
the proxy. When Jitsi try to build the connection to that for
in-dialog request, it fails.

If Jitsi could always send the Request to the outbound proxy (initial
and in-dialog request), it may help the situation in the TLS protocol.

Thanks again.

Best Regards,
Laura

On Wed, Oct 19, 2011 at 4:05 PM, Emil Ivov <emcho@jitsi.org> wrote:

Laura,

Could you please send complete logs from a session where the problem occurs?

Emil

--sent from my mobile

On 19 oct. 2011, at 15:55, laura testi <lau.testi@gmail.com> wrote:

Hi,
we try to use the TLS protocol with Jitsi in the SIP/SIMPLE
environment. And the Servers are behind NAT and can be reached via an
outbound proxy only. We configure the proxy to point the outbound
proxy. Everything is OK for UDP/TCP until we try to use TLS protocol.
With TLS, all INITIAL REQUESTs (REGISTER/MESSAGE/PUBLISH/SUBSCRIBE(not
in-dialog) go through outbound proxy and everything is ok. But we
found the problems for the in-dialog requests like:
- re SUBSCRIBE (in-dialog)
- ACK for the call (INVITE, 200 OK ...)
- BYE for the call

for these in-dialog requests, it seems iitsi does not send them to the
outbound proxy even the protocol is TLS, and fail with the following
error:

SEVERE: impl.protocol.sip.EventPackageSubscriber.run().1317 Can't
send the request
javax.sip.SipException: error sending message
   at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2690)
   at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2465)
   at net.java.sip.communicator.impl.protocol.sip.EventPackageSubscriber$SubscriptionRefreshTask.run(EventPackageSubscriber.java:1313)
   at java.util.TimerThread.mainLoop(Unknown Source)
   at java.util.TimerThread.run(Unknown Source)
Caused by: java.io.IOException: The provider that requested the SSL
Socket could not be found
   at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.getSSLSocketFactory(SslNetworkLayer.java:180)
   at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.createSSLSocket(SslNetworkLayer.java:257)
   at gov.nist.javax.sip.stack.IOHandler.sendBytes(IOHandler.java:466)
   at gov.nist.javax.sip.stack.TLSMessageChannel.sendMessage(TLSMessageChannel.java:374)
   at gov.nist.javax.sip.stack.MessageChannel.sendMessage(MessageChannel.java:281)
   at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:855)
   at gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:489)
   at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2672)

I don't know if it's a bug. But is it possible to force Jitsi to
always use outbound proxy for all outgoing messages that include also
in-dialog requests? This will be very useful for the far-end
Firewall/NAT traversal.

Thanks in advanced

Best Regards,
Laura

--
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


#8

Hello,

fyi, since maybe it helps you to troubleshoot independently -- you can use voipuser.org service, where you can create an account yourself and it is running latest kamailio version with TLS enabled.

Cheers,
Daniel

···

On 10/21/11 10:06 AM, Damian Minkov wrote:

Hi Laura,

is it possible to provide us with a test account (using a private
mail:) ) so we can easily test and correct this issue.
The exception in the logs really shows that the message is routed to a
different address than the used outbound proxy.

Thanks
damencho

On Thu, Oct 20, 2011 at 12:04 PM, laura testi<lau.testi@gmail.com> wrote:

Hi Emil,
please find the log in the attachment. We start Jitsi and register to
SIP server at 10:16 with TLS. the client can chat (MESSAGE) and
exchange presence status with others. The expire time for the
registration and subscription (presence) in the server is configured
about 10 minutes. In fact, after 10 minutes, the presence does not
work anymore because Jitsi fail to renew the subscription (in-dialog
SUBSCRIBE for the previous subscription). But others can still see my
status because it can still renew the registration (REGISTER is always
initial request and is sent to outbound proxy) and PUBLISH the
presence status (PUBLISH is always initial request and is sent to
outvound proxy). In fact, after more or less 10 minutes, the serer
does not receive further SUBSCRIBE anymore from my PC, but only
REGISTER and PUBLISH if I change the presence status from my Jitsi.

The same thing happen if I initiate an audio/video call, the sever
receive INVITE and send back the answer 200 OK from called party to
me, but does not receive ACK from my JITSI (ACK is an in-dialog
request too).

I think the problem could be the Record_Route received from 200/202 OK
by Jitsi, it use the first top Route built from Record_Route to send
the further in-dialog request instead of outbound proxy. In TCP and
UDP, it's OK because the static NAT can convert the proxy private
address to the corresponding public address, so the record_route
received by Jitsi from 200/202 OK contains the public address of the
Proxy. When in TLS, the NAT can not convert the private address to
public address because it's SSL, so the record_route received by Jitsi
from 200/202 OK (for INVITE/SUBSCRIBE) contains the private address of
the proxy. When Jitsi try to build the connection to that for
in-dialog request, it fails.

If Jitsi could always send the Request to the outbound proxy (initial
and in-dialog request), it may help the situation in the TLS protocol.

Thanks again.

Best Regards,
Laura

On Wed, Oct 19, 2011 at 4:05 PM, Emil Ivov<emcho@jitsi.org> wrote:

Laura,

Could you please send complete logs from a session where the problem occurs?

Emil

--sent from my mobile

On 19 oct. 2011, at 15:55, laura testi<lau.testi@gmail.com> wrote:

Hi,
we try to use the TLS protocol with Jitsi in the SIP/SIMPLE
environment. And the Servers are behind NAT and can be reached via an
outbound proxy only. We configure the proxy to point the outbound
proxy. Everything is OK for UDP/TCP until we try to use TLS protocol.
With TLS, all INITIAL REQUESTs (REGISTER/MESSAGE/PUBLISH/SUBSCRIBE(not
in-dialog) go through outbound proxy and everything is ok. But we
found the problems for the in-dialog requests like:
- re SUBSCRIBE (in-dialog)
- ACK for the call (INVITE, 200 OK ...)
- BYE for the call

for these in-dialog requests, it seems iitsi does not send them to the
outbound proxy even the protocol is TLS, and fail with the following
error:

SEVERE: impl.protocol.sip.EventPackageSubscriber.run().1317 Can't
send the request
javax.sip.SipException: error sending message
    at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2690)
    at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2465)
    at net.java.sip.communicator.impl.protocol.sip.EventPackageSubscriber$SubscriptionRefreshTask.run(EventPackageSubscriber.java:1313)
    at java.util.TimerThread.mainLoop(Unknown Source)
    at java.util.TimerThread.run(Unknown Source)
Caused by: java.io.IOException: The provider that requested the SSL
Socket could not be found
    at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.getSSLSocketFactory(SslNetworkLayer.java:180)
    at net.java.sip.communicator.impl.protocol.sip.net.SslNetworkLayer.createSSLSocket(SslNetworkLayer.java:257)
    at gov.nist.javax.sip.stack.IOHandler.sendBytes(IOHandler.java:466)
    at gov.nist.javax.sip.stack.TLSMessageChannel.sendMessage(TLSMessageChannel.java:374)
    at gov.nist.javax.sip.stack.MessageChannel.sendMessage(MessageChannel.java:281)
    at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:855)
    at gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:489)
    at gov.nist.javax.sip.stack.SIPDialog.sendRequest(SIPDialog.java:2672)

I don't know if it's a bug. But is it possible to force Jitsi to
always use outbound proxy for all outgoing messages that include also
in-dialog requests? This will be very useful for the far-end
Firewall/NAT traversal.

Thanks in advanced

Best Regards,
Laura

--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda