[jitsi-dev] Re: Video Call through SIP (Freeswitch) not working


#1

(Sorry 4 topposting, forced upon me by BB)

Yes, i've experimenting with sip-video as well, but with asterisk.
I've seen same behaviour* as you, but mostly (!) It boils down, to. Video-codec mismatch between client1/pbx and client2/pbx, or client1/client2.

*even difference between client1 calling client2 and client2 calling client1 :frowning:

With xmpp nothing is inbetween, which can be an advantage, but also a serious limitation.

路路路

Van: Privus 007 [mailto:privus007@gmail.com]
Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time
Aan: dev@jitsi.java.net <dev@jitsi.java.net>
Onderwerp: [jitsi-dev] Video Call through SIP (Freeswitch) not working

Hello,

I've been trying to get video working on a basic SIP call between 2 jitsi (latest nightly) clients. One on windows 7, the other on Mint 14. I'm using Freeswitch as the SIP server and have enabled the "proxy media" variable in the SIP profile. This should theoretically let the 2 jitsi endpoints talk to each other directly with little interference from the server.

My results aren't good. Basically the video box remains greyed out on both sides during the call, and there seems to be no video media in the call (although audio works). I've tried playing around with VP8 and H264, to no avail. Also, I often have to hangup the first attempt and try again since jitsi seems to hang after "dialing" (and I see in the server that it never receives anything from jitsi). On the second try Jitsi is able to reach the server as it should, although video still doesn't work.

Frustrated with this SIP experiment and Freeswitch, I set up an XMPP server (openfire) and tried the same experiment. This time video worked as it should (most of the time, I still get inconsistent results). Even ZRTP worked well in both audio and video.

Before I start sending logs, etc, I was wondering if anyone has been able to use Jitsi's video with SIP, and with Freeswitch in particular.

I've also setup the videobridge with openfire and that seemed to work well, although I only tested a little bit.

Thanks

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.


#2

Thanks for your reply.

Hmmm. So it seems it is not just some incompatibility with Freeswitch but
rather an incompatibility with SIP in general.

That seems like a pretty serious limitation to jitsi's video capability,
no? I've also tried putting VP8 at the top of the codec list on both jitsi
clients and I still have the same problems and inconsistency described
above.

Has anyone else had any success (consistently) with jitsi video through a
SIP server?

Thanks

路路路

On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl> wrote:

(Sorry 4 topposting, forced upon me by BB)

Yes, i've experimenting with sip-video as well, but with asterisk.
I've seen same behaviour* as you, but mostly (!) It boils down, to.
Video-codec mismatch between client1/pbx and client2/pbx, or
client1/client2.

*even difference between client1 calling client2 and client2 calling
client1 :frowning:

With xmpp nothing is inbetween, which can be an advantage, but also a
serious limitation.

*Van*: Privus 007 [mailto:privus007@gmail.com]
*Verzonden*: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time
*Aan*: dev@jitsi.java.net <dev@jitsi.java.net>
*Onderwerp*: [jitsi-dev] Video Call through SIP (Freeswitch) not working

Hello,

I've been trying to get video working on a basic SIP call between 2 jitsi
(latest nightly) clients. One on windows 7, the other on Mint 14. I'm using
Freeswitch as the SIP server and have enabled the "proxy media" variable in
the SIP profile. This should theoretically let the 2 jitsi endpoints talk
to each other directly with little interference from the server.

My results aren't good. Basically the video box remains greyed out on both
sides during the call, and there seems to be no video media in the call
(although audio works). I've tried playing around with VP8 and H264, to no
avail. Also, I often have to hangup the first attempt and try again since
jitsi seems to hang after "dialing" (and I see in the server that it never
receives anything from jitsi). On the second try Jitsi is able to reach the
server as it should, although video still doesn't work.

Frustrated with this SIP experiment and Freeswitch, I set up an XMPP
server (openfire) and tried the same experiment. This time video worked as
it should (most of the time, I still get inconsistent results). Even ZRTP
worked well in both audio and video.

Before I start sending logs, etc, I was wondering if anyone has been able
to use Jitsi's video with SIP, and with Freeswitch in particular.

I've also setup the videobridge with openfire and that seemed to work
well, although I only tested a little bit.

Thanks
------------------------------
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
niet de geadresseerde bent of dit bericht abusievelijk aan u is
toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
welke aard ook, die verband houdt met risico's verbonden aan het
electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you
are not the addressee or if this message was sent to you by mistake, you
are requested to inform the sender and delete the message. The State
accepts no liability for damage of any kind resulting from the risks
inherent in the electronic transmission of messages.


#3

Hi,

Freeswitch is a proxy as opposed to a B2BUA so should have no issues routing audio or video. In fact, the the codecs chosen are selected by negotiation between endpoints.

In the case you describe, if you are doing a call from Jitsi to another Jitsi client and it works sometimes but not others, I don't think the issue is related to Jitsi.

Is all this on a private network or are the clients going through a firewall or NAT? This is the usual cause of SIP issues.

Thanks.

marc.

路路路

__________________
+1-949-270-0935

On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com> wrote:

Thanks for your reply.

Hmmm. So it seems it is not just some incompatibility with Freeswitch but rather an incompatibility with SIP in general.

That seems like a pretty serious limitation to jitsi's video capability, no? I've also tried putting VP8 at the top of the codec list on both jitsi clients and I still have the same problems and inconsistency described above.

Has anyone else had any success (consistently) with jitsi video through a SIP server?

Thanks

On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl> wrote:
(Sorry 4 topposting, forced upon me by BB)

Yes, i've experimenting with sip-video as well, but with asterisk.
I've seen same behaviour* as you, but mostly (!) It boils down, to. Video-codec mismatch between client1/pbx and client2/pbx, or client1/client2.

*even difference between client1 calling client2 and client2 calling client1 :frowning:

With xmpp nothing is inbetween, which can be an advantage, but also a serious limitation.

Van: Privus 007 [mailto:privus007@gmail.com]
Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time
Aan: dev@jitsi.java.net <dev@jitsi.java.net>
Onderwerp: [jitsi-dev] Video Call through SIP (Freeswitch) not working

Hello,

I've been trying to get video working on a basic SIP call between 2 jitsi (latest nightly) clients. One on windows 7, the other on Mint 14. I'm using Freeswitch as the SIP server and have enabled the "proxy media" variable in the SIP profile. This should theoretically let the 2 jitsi endpoints talk to each other directly with little interference from the server.

My results aren't good. Basically the video box remains greyed out on both sides during the call, and there seems to be no video media in the call (although audio works). I've tried playing around with VP8 and H264, to no avail. Also, I often have to hangup the first attempt and try again since jitsi seems to hang after "dialing" (and I see in the server that it never receives anything from jitsi). On the second try Jitsi is able to reach the server as it should, although video still doesn't work.

Frustrated with this SIP experiment and Freeswitch, I set up an XMPP server (openfire) and tried the same experiment. This time video worked as it should (most of the time, I still get inconsistent results). Even ZRTP worked well in both audio and video.

Before I start sending logs, etc, I was wondering if anyone has been able to use Jitsi's video with SIP, and with Freeswitch in particular.

I've also setup the videobridge with openfire and that seemed to work well, although I only tested a little bit.

Thanks
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.


#4

Hi Marc,

Thanks for your reply and sorry it took so long for me to respond.
Yes indeed NAT issues are the most common problem with SIP, but I don't
think this is the case, specially since audio works and other SIP clients I
have also work flawlessly on this same network setup. Also, the openfire
xmpp server I use is on the same machine as the Freeswitch server, and as I
stated before video works ok when using XMPP transport without any NAT or
firewall issues.
So I'm inclined to believe it is a jitsi issue and/or Freeswitch problem
rather than a NAT/firewall one.
Has anyone actually thoroughly tested Jitsi's video with a SIP server. If
so what were the results? Any special configuration settings?

Thanks

路路路

On Thu, Apr 11, 2013 at 7:21 PM, Marc Abrams <marca56@gmail.com> wrote:

Hi,

Freeswitch is a proxy as opposed to a B2BUA so should have no issues
routing audio or video. In fact, the the codecs chosen are selected by
negotiation between endpoints.

In the case you describe, if you are doing a call from Jitsi to another
Jitsi client and it works sometimes but not others, I don't think the issue
is related to Jitsi.

Is all this on a private network or are the clients going through a
firewall or NAT? This is the usual cause of SIP issues.

Thanks.

marc.
__________________
+1-949-270-0935

On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com> wrote:

Thanks for your reply.

Hmmm. So it seems it is not just some incompatibility with Freeswitch but
rather an incompatibility with SIP in general.

That seems like a pretty serious limitation to jitsi's video capability,
no? I've also tried putting VP8 at the top of the codec list on both jitsi
clients and I still have the same problems and inconsistency described
above.

Has anyone else had any success (consistently) with jitsi video through a
SIP server?

Thanks

On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl> wrote:

(Sorry 4 topposting, forced upon me by BB)

Yes, i've experimenting with sip-video as well, but with asterisk.
I've seen same behaviour* as you, but mostly (!) It boils down, to.
Video-codec mismatch between client1/pbx and client2/pbx, or
client1/client2.

*even difference between client1 calling client2 and client2 calling
client1 :frowning:

With xmpp nothing is inbetween, which can be an advantage, but also a
serious limitation.

*Van*: Privus 007 [mailto:privus007@gmail.com]
*Verzonden*: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time
*Aan*: dev@jitsi.java.net <dev@jitsi.java.net>
*Onderwerp*: [jitsi-dev] Video Call through SIP (Freeswitch) not working

Hello,

I've been trying to get video working on a basic SIP call between 2 jitsi
(latest nightly) clients. One on windows 7, the other on Mint 14. I'm using
Freeswitch as the SIP server and have enabled the "proxy media" variable in
the SIP profile. This should theoretically let the 2 jitsi endpoints talk
to each other directly with little interference from the server.

My results aren't good. Basically the video box remains greyed out on
both sides during the call, and there seems to be no video media in the
call (although audio works). I've tried playing around with VP8 and H264,
to no avail. Also, I often have to hangup the first attempt and try again
since jitsi seems to hang after "dialing" (and I see in the server that it
never receives anything from jitsi). On the second try Jitsi is able to
reach the server as it should, although video still doesn't work.

Frustrated with this SIP experiment and Freeswitch, I set up an XMPP
server (openfire) and tried the same experiment. This time video worked as
it should (most of the time, I still get inconsistent results). Even ZRTP
worked well in both audio and video.

Before I start sending logs, etc, I was wondering if anyone has been able
to use Jitsi's video with SIP, and with Freeswitch in particular.

I've also setup the videobridge with openfire and that seemed to work
well, although I only tested a little bit.

Thanks
------------------------------
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
niet de geadresseerde bent of dit bericht abusievelijk aan u is
toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
welke aard ook, die verband houdt met risico's verbonden aan het
electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you
are not the addressee or if this message was sent to you by mistake, you
are requested to inform the sender and delete the message. The State
accepts no liability for damage of any kind resulting from the risks
inherent in the electronic transmission of messages.


#5

Hey Marc,

Hi,

Freeswitch is a proxy as opposed to a B2BUA so should have no issues >

routing audio or video. In fact, the the codecs chosen are selected by

negotiation between endpoints.

Chiming in for a quick comment: I don't have a lot of experience with FS
but as far as I know, it is exactly the opposite of a proxy and the very
definition of a B2BUA. This is one of the reasons why Jitsi's Opus support
wasn't working there until they recently fixed it.

Emil

--sent from my mobile

In the case you describe, if you are doing a call from Jitsi to another

Jitsi client and it works sometimes but not others, I don't think the issue
is related to Jitsi.

Is all this on a private network or are the clients going through a

firewall or NAT? This is the usual cause of SIP issues.

Thanks.

marc.
__________________
+1-949-270-0935

Thanks for your reply.

Hmmm. So it seems it is not just some incompatibility with Freeswitch

but rather an incompatibility with SIP in general.

That seems like a pretty serious limitation to jitsi's video capability,

no? I've also tried putting VP8 at the top of the codec list on both jitsi
clients and I still have the same problems and inconsistency described
above.

Has anyone else had any success (consistently) with jitsi video through

a SIP server?

Thanks

(Sorry 4 topposting, forced upon me by BB)

Yes, i've experimenting with sip-video as well, but with asterisk.
I've seen same behaviour* as you, but mostly (!) It boils down, to.

Video-codec mismatch between client1/pbx and client2/pbx, or
client1/client2.

*even difference between client1 calling client2 and client2 calling

client1 :frowning:

With xmpp nothing is inbetween, which can be an advantage, but also a

serious limitation.

Van: Privus 007 [mailto:privus007@gmail.com]
Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time
Aan: dev@jitsi.java.net <dev@jitsi.java.net>
Onderwerp: [jitsi-dev] Video Call through SIP (Freeswitch) not working

Hello,

I've been trying to get video working on a basic SIP call between 2

jitsi (latest nightly) clients. One on windows 7, the other on Mint 14. I'm
using Freeswitch as the SIP server and have enabled the "proxy media"
variable in the SIP profile. This should theoretically let the 2 jitsi
endpoints talk to each other directly with little interference from the
server.

My results aren't good. Basically the video box remains greyed out on

both sides during the call, and there seems to be no video media in the
call (although audio works). I've tried playing around with VP8 and H264,
to no avail. Also, I often have to hangup the first attempt and try again
since jitsi seems to hang after "dialing" (and I see in the server that it
never receives anything from jitsi). On the second try Jitsi is able to
reach the server as it should, although video still doesn't work.

Frustrated with this SIP experiment and Freeswitch, I set up an XMPP

server (openfire) and tried the same experiment. This time video worked as
it should (most of the time, I still get inconsistent results). Even ZRTP
worked well in both audio and video.

Before I start sending logs, etc, I was wondering if anyone has been

able to use Jitsi's video with SIP, and with Freeswitch in particular.

I've also setup the videobridge with openfire and that seemed to work

well, although I only tested a little bit.

Thanks
________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien

u niet de geadresseerde bent of dit bericht abusievelijk aan u is
toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
welke aard ook, die verband houdt met risico's verbonden aan het
electronisch verzenden van berichten.

This message may contain information that is not intended for you. If

you are not the addressee or if this message was sent to you by mistake,
you are requested to inform the sender and delete the message. The State
accepts no liability for damage of any kind resulting from the risks
inherent in the electronic transmission of messages.

路路路

On Apr 11, 2013 8:21 PM, "Marc Abrams" <marca56@gmail.com> wrote:

On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com> wrote:

On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl> wrote:


#6

Hi,

I have tested it pretty thoroughly with 2600hz in a hosted environment and it worked very well. The core of their service is based on Freeswitch. However, they are doing maintenance on the part of their system that would allow video and have turned it off for the moment so I can't retest for you now.

Thanks.

marc.

路路路

__________________
+1-949-270-0935

On Apr 12, 2013, at 11:38 AM, Privus 007 <privus007@gmail.com> wrote:

Hi Marc,

Thanks for your reply and sorry it took so long for me to respond.
Yes indeed NAT issues are the most common problem with SIP, but I don't think this is the case, specially since audio works and other SIP clients I have also work flawlessly on this same network setup. Also, the openfire xmpp server I use is on the same machine as the Freeswitch server, and as I stated before video works ok when using XMPP transport without any NAT or firewall issues.
So I'm inclined to believe it is a jitsi issue and/or Freeswitch problem rather than a NAT/firewall one.
Has anyone actually thoroughly tested Jitsi's video with a SIP server. If so what were the results? Any special configuration settings?

Thanks

On Thu, Apr 11, 2013 at 7:21 PM, Marc Abrams <marca56@gmail.com> wrote:
Hi,

Freeswitch is a proxy as opposed to a B2BUA so should have no issues routing audio or video. In fact, the the codecs chosen are selected by negotiation between endpoints.

In the case you describe, if you are doing a call from Jitsi to another Jitsi client and it works sometimes but not others, I don't think the issue is related to Jitsi.

Is all this on a private network or are the clients going through a firewall or NAT? This is the usual cause of SIP issues.

Thanks.

marc.
__________________
+1-949-270-0935

On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com> wrote:

Thanks for your reply.

Hmmm. So it seems it is not just some incompatibility with Freeswitch but rather an incompatibility with SIP in general.

That seems like a pretty serious limitation to jitsi's video capability, no? I've also tried putting VP8 at the top of the codec list on both jitsi clients and I still have the same problems and inconsistency described above.

Has anyone else had any success (consistently) with jitsi video through a SIP server?

Thanks

On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl> wrote:
(Sorry 4 topposting, forced upon me by BB)

Yes, i've experimenting with sip-video as well, but with asterisk.
I've seen same behaviour* as you, but mostly (!) It boils down, to. Video-codec mismatch between client1/pbx and client2/pbx, or client1/client2.

*even difference between client1 calling client2 and client2 calling client1 :frowning:

With xmpp nothing is inbetween, which can be an advantage, but also a serious limitation.

Van: Privus 007 [mailto:privus007@gmail.com]
Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time
Aan: dev@jitsi.java.net <dev@jitsi.java.net>
Onderwerp: [jitsi-dev] Video Call through SIP (Freeswitch) not working

Hello,

I've been trying to get video working on a basic SIP call between 2 jitsi (latest nightly) clients. One on windows 7, the other on Mint 14. I'm using Freeswitch as the SIP server and have enabled the "proxy media" variable in the SIP profile. This should theoretically let the 2 jitsi endpoints talk to each other directly with little interference from the server.

My results aren't good. Basically the video box remains greyed out on both sides during the call, and there seems to be no video media in the call (although audio works). I've tried playing around with VP8 and H264, to no avail. Also, I often have to hangup the first attempt and try again since jitsi seems to hang after "dialing" (and I see in the server that it never receives anything from jitsi). On the second try Jitsi is able to reach the server as it should, although video still doesn't work.

Frustrated with this SIP experiment and Freeswitch, I set up an XMPP server (openfire) and tried the same experiment. This time video worked as it should (most of the time, I still get inconsistent results). Even ZRTP worked well in both audio and video.

Before I start sending logs, etc, I was wondering if anyone has been able to use Jitsi's video with SIP, and with Freeswitch in particular.

I've also setup the videobridge with openfire and that seemed to work well, although I only tested a little bit.

Thanks
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.


#7

Hi,

I use Freeswitch with Jitsi as our main phone system and for audio it works well.

But for video when using Freeswitch or the XMPP video bridge, we've had nothing but problems with it, and have yet to get a successful video conference working.

The only thing that seems to work is the "echo" test, whereby it echos a video and audio stream back to you.

This at least proves the video and audio is working.

But as soon as I try and open multiple video streams concurrently (using either XMPP jit.si service, or a freeswitch video conference) one or more of the video streams just displays a black window, and usually Jitsi becomes unresponsive.

I'm not sure what I am doing differently to others who have go it working.

We are using Windows 7 32bit, and the latest stable release with these web cams http://www.ebuyer.com/336948-microsoft-lifecam-hd-3000-for-business-win-usb-t4h-00004

We are also using single window mode.

Not sure what it is that is causing us problems, but most of our users have gone back to Google hang outs now anyway.

Tom

路路路

On 12/04/13 20:00, Marc Abrams wrote:

Hi,

I have tested it pretty thoroughly with 2600hz in a hosted environment and it worked very well. The core of their service is based on Freeswitch. However, they are doing maintenance on the part of their system that would allow video and have turned it off for the moment so I can't retest for you now.

Thanks.

marc.
__________________
+1-949-270-0935

On Apr 12, 2013, at 11:38 AM, Privus 007 <privus007@gmail.com > <mailto:privus007@gmail.com>> wrote:

Hi Marc,

Thanks for your reply and sorry it took so long for me to respond.
Yes indeed NAT issues are the most common problem with SIP, but I don't think this is the case, specially since audio works and other SIP clients I have also work flawlessly on this same network setup. Also, the openfire xmpp server I use is on the same machine as the Freeswitch server, and as I stated before video works ok when using XMPP transport without any NAT or firewall issues.
So I'm inclined to believe it is a jitsi issue and/or Freeswitch problem rather than a NAT/firewall one.
Has anyone actually thoroughly tested Jitsi's video with a SIP server. If so what were the results? Any special configuration settings?

Thanks

On Thu, Apr 11, 2013 at 7:21 PM, Marc Abrams <marca56@gmail.com >> <mailto:marca56@gmail.com>> wrote:

聽聽聽聽Hi,

聽聽聽聽Freeswitch is a proxy as opposed to a B2BUA so should have no
聽聽聽聽issues routing audio or video. In fact, the the codecs chosen are
聽聽聽聽selected by negotiation between endpoints.

聽聽聽聽In the case you describe, if you are doing a call from Jitsi to
聽聽聽聽another Jitsi client and it works sometimes but not others, I
聽聽聽聽don't think the issue is related to Jitsi.

聽聽聽聽Is all this on a private network or are the clients going through
聽聽聽聽a firewall or NAT? This is the usual cause of SIP issues.

聽聽聽聽Thanks.

聽聽聽聽marc.
聽聽聽聽__________________
聽聽聽聽+1-949-270-0935 <tel:%2B1-949-270-0935>

聽聽聽聽On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com >> <mailto:privus007@gmail.com>> wrote:

聽聽聽聽Thanks for your reply.

聽聽聽聽Hmmm. So it seems it is not just some incompatibility with
聽聽聽聽Freeswitch but rather an incompatibility with SIP in general.

聽聽聽聽That seems like a pretty serious limitation to jitsi's video
聽聽聽聽capability, no? I've also tried putting VP8 at the top of the
聽聽聽聽codec list on both jitsi clients and I still have the same
聽聽聽聽problems and inconsistency described above.

聽聽聽聽Has anyone else had any success (consistently) with jitsi video
聽聽聽聽through a SIP server?

聽聽聽聽Thanks

聽聽聽聽On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl >>> <mailto:J.Witvliet@mindef.nl>> wrote:

聽聽聽聽聽聽聽聽(Sorry 4 topposting, forced upon me by BB)

聽聽聽聽聽聽聽聽Yes, i've experimenting with sip-video as well, but with
聽聽聽聽聽聽聽聽asterisk.
聽聽聽聽聽聽聽聽I've seen same behaviour* as you, but mostly (!) It boils
聽聽聽聽聽聽聽聽down, to. Video-codec mismatch between client1/pbx and
聽聽聽聽聽聽聽聽client2/pbx, or client1/client2.

聽聽聽聽聽聽聽聽*even difference between client1 calling client2 and client2
聽聽聽聽聽聽聽聽calling client1 :frowning:

聽聽聽聽聽聽聽聽With xmpp nothing is inbetween, which can be an advantage,
聽聽聽聽聽聽聽聽but also a serious limitation.

聽聽聽聽聽聽聽聽*Van*: Privus 007 [mailto:privus007@gmail.com
聽聽聽聽聽聽聽聽<mailto:privus007@gmail.com>]
聽聽聽聽聽聽聽聽*Verzonden*: Tuesday, April 09, 2013 07:35 PM W. Europe
聽聽聽聽聽聽聽聽Standard Time
聽聽聽聽聽聽聽聽*Aan*: dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽聽聽聽聽<dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
聽聽聽聽聽聽聽聽*Onderwerp*: [jitsi-dev] Video Call through SIP (Freeswitch)
聽聽聽聽聽聽聽聽not working

聽聽聽聽聽聽聽聽Hello,

聽聽聽聽聽聽聽聽I've been trying to get video working on a basic SIP call
聽聽聽聽聽聽聽聽between 2 jitsi (latest nightly) clients. One on windows 7,
聽聽聽聽聽聽聽聽the other on Mint 14. I'm using Freeswitch as the SIP server
聽聽聽聽聽聽聽聽and have enabled the "proxy media" variable in the SIP
聽聽聽聽聽聽聽聽profile. This should theoretically let the 2 jitsi endpoints
聽聽聽聽聽聽聽聽talk to each other directly with little interference from
聽聽聽聽聽聽聽聽the server.

聽聽聽聽聽聽聽聽My results aren't good. Basically the video box remains
聽聽聽聽聽聽聽聽greyed out on both sides during the call, and there seems to
聽聽聽聽聽聽聽聽be no video media in the call (although audio works). I've
聽聽聽聽聽聽聽聽tried playing around with VP8 and H264, to no avail. Also, I
聽聽聽聽聽聽聽聽often have to hangup the first attempt and try again since
聽聽聽聽聽聽聽聽jitsi seems to hang after "dialing" (and I see in the server
聽聽聽聽聽聽聽聽that it never receives anything from jitsi). On the second
聽聽聽聽聽聽聽聽try Jitsi is able to reach the server as it should, although
聽聽聽聽聽聽聽聽video still doesn't work.

聽聽聽聽聽聽聽聽Frustrated with this SIP experiment and Freeswitch, I set up
聽聽聽聽聽聽聽聽an XMPP server (openfire) and tried the same experiment.
聽聽聽聽聽聽聽聽This time video worked as it should (most of the time, I
聽聽聽聽聽聽聽聽still get inconsistent results). Even ZRTP worked well in
聽聽聽聽聽聽聽聽both audio and video.

聽聽聽聽聽聽聽聽Before I start sending logs, etc, I was wondering if anyone
聽聽聽聽聽聽聽聽has been able to use Jitsi's video with SIP, and with
聽聽聽聽聽聽聽聽Freeswitch in particular.

聽聽聽聽聽聽聽聽I've also setup the videobridge with openfire and that
聽聽聽聽聽聽聽聽seemed to work well, although I only tested a little bit.

聽聽聽聽聽聽聽聽Thanks
聽聽聽聽聽聽聽聽------------------------------------------------------------------------
聽聽聽聽聽聽聽聽Dit bericht kan informatie bevatten die niet voor u is
聽聽聽聽聽聽聽聽bestemd. Indien u niet de geadresseerde bent of dit bericht
聽聽聽聽聽聽聽聽abusievelijk aan u is toegezonden, wordt u verzocht dat aan
聽聽聽聽聽聽聽聽de afzender te melden en het bericht te verwijderen. De
聽聽聽聽聽聽聽聽Staat aanvaardt geen aansprakelijkheid voor schade, van
聽聽聽聽聽聽聽聽welke aard ook, die verband houdt met risico's verbonden aan
聽聽聽聽聽聽聽聽het electronisch verzenden van berichten.

聽聽聽聽聽聽聽聽This message may contain information that is not intended
聽聽聽聽聽聽聽聽for you. If you are not the addressee or if this message was
聽聽聽聽聽聽聽聽sent to you by mistake, you are requested to inform the
聽聽聽聽聽聽聽聽sender and delete the message. The State accepts no
聽聽聽聽聽聽聽聽liability for damage of any kind resulting from the risks
聽聽聽聽聽聽聽聽inherent in the electronic transmission of messages.


#8

Correct, From their wiki here
http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch

"FreeSWITCH is a B2BUA (back-to-back user agent). This means that it
actually parses each of the SIP messages it receives. FreeSWITCH can not
act as a proxy, for instance by forwarding SIP registrations to a registrar
server."

However, I have configured FS in proxy media mode in order to allow 2 jitsi
clients to establish a ZRTP audio call between them.
Again, per the wiki here http://wiki.freeswitch.org/wiki/Proxy_Media

聽聽聽- Proxy: media flows through FS, no media processing options

- RTP proxied by FreeSWITCH (c= modified, that's it)
- FreeSWITCH has no control or even understanding of other SDP
parameters (pass through)
- Endpoints *MUST* agree on same codec because FreeSWITCH can't help them
- Virtually no features available

路路路

On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Marc,

On Apr 11, 2013 8:21 PM, "Marc Abrams" <marca56@gmail.com> wrote:
>
> Hi,
>
> Freeswitch is a proxy as opposed to a B2BUA so should have no issues >
routing audio or video. In fact, the the codecs chosen are selected by
> negotiation between endpoints.

Chiming in for a quick comment: I don't have a lot of experience with FS
but as far as I know, it is exactly the opposite of a proxy and the very
definition of a B2BUA. This is one of the reasons why Jitsi's Opus support
wasn't working there until they recently fixed it.

Emil

--sent from my mobile
>

> In the case you describe, if you are doing a call from Jitsi to another
Jitsi client and it works sometimes but not others, I don't think the issue
is related to Jitsi.
>
> Is all this on a private network or are the clients going through a
firewall or NAT? This is the usual cause of SIP issues.
>
> Thanks.
>
> marc.
> __________________
> +1-949-270-0935
>
>
>
> On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com> wrote:
>
>> Thanks for your reply.
>>
>> Hmmm. So it seems it is not just some incompatibility with Freeswitch
but rather an incompatibility with SIP in general.
>>
>> That seems like a pretty serious limitation to jitsi's video
capability, no? I've also tried putting VP8 at the top of the codec list on
both jitsi clients and I still have the same problems and inconsistency
described above.
>>
>> Has anyone else had any success (consistently) with jitsi video through
a SIP server?
>>
>> Thanks
>>
>>
>> On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl> wrote:
>>>
>>> (Sorry 4 topposting, forced upon me by BB)
>>>
>>> Yes, i've experimenting with sip-video as well, but with asterisk.
>>> I've seen same behaviour* as you, but mostly (!) It boils down, to.
Video-codec mismatch between client1/pbx and client2/pbx, or
client1/client2.
>>>
>>> *even difference between client1 calling client2 and client2 calling
client1 :frowning:
>>>
>>>
>>> With xmpp nothing is inbetween, which can be an advantage, but also a
serious limitation.
>>>
>>>
>>> Van: Privus 007 [mailto:privus007@gmail.com]
>>> Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time
>>> Aan: dev@jitsi.java.net <dev@jitsi.java.net>
>>> Onderwerp: [jitsi-dev] Video Call through SIP (Freeswitch) not working
>>>
>>> Hello,
>>>
>>> I've been trying to get video working on a basic SIP call between 2
jitsi (latest nightly) clients. One on windows 7, the other on Mint 14. I'm
using Freeswitch as the SIP server and have enabled the "proxy media"
variable in the SIP profile. This should theoretically let the 2 jitsi
endpoints talk to each other directly with little interference from the
server.
>>>
>>> My results aren't good. Basically the video box remains greyed out on
both sides during the call, and there seems to be no video media in the
call (although audio works). I've tried playing around with VP8 and H264,
to no avail. Also, I often have to hangup the first attempt and try again
since jitsi seems to hang after "dialing" (and I see in the server that it
never receives anything from jitsi). On the second try Jitsi is able to
reach the server as it should, although video still doesn't work.
>>>
>>> Frustrated with this SIP experiment and Freeswitch, I set up an XMPP
server (openfire) and tried the same experiment. This time video worked as
it should (most of the time, I still get inconsistent results). Even ZRTP
worked well in both audio and video.
>>>
>>> Before I start sending logs, etc, I was wondering if anyone has been
able to use Jitsi's video with SIP, and with Freeswitch in particular.
>>>
>>> I've also setup the videobridge with openfire and that seemed to work
well, although I only tested a little bit.
>>>
>>> Thanks
>>> ________________________________
>>> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien
u niet de geadresseerde bent of dit bericht abusievelijk aan u is
toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
welke aard ook, die verband houdt met risico's verbonden aan het
electronisch verzenden van berichten.
>>>
>>> This message may contain information that is not intended for you. If
you are not the addressee or if this message was sent to you by mistake,
you are requested to inform the sender and delete the message. The State
accepts no liability for damage of any kind resulting from the risks
inherent in the electronic transmission of messages.
>>
>>
>


#9

Hey,

But as soon as I try and open multiple video streams concurrently (using
either XMPP jit.si service, or a freeswitch video conference) one or more
of the video streams just displays a black window, and usually Jitsi
becomes unresponsive.

You might want to try again with the latest nightly, as there was a similar
problem fixed just yesterday (in revision 10756).

I'm not sure what I am doing differently to others who have go it working.

We are using Windows 7 32bit, and the latest stable release with these web
cams
http://www.ebuyer.com/336948-microsoft-lifecam-hd-3000-for-business-win-usb-t4h-00004

We are also using single window mode.

Single window mode hasn't been tested as much as the "regular" one. Can you
turn it off and see if it works?

If you have specific issues, please describe them here, and make sure
you're running the latest nightlies, because they contain multiple fixes.

Regards,
Boris

路路路

On Fri, Apr 12, 2013 at 10:09 PM, Tom Parrott <tomp@tomp.co.uk> wrote:


#10

Hey there,

Correct, From their wiki here
http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch

"FreeSWITCH is a B2BUA (back-to-back user agent). This means that it
actually parses each of the SIP messages it receives. FreeSWITCH can not
act as a proxy, for instance by forwarding SIP registrations to a
registrar server."

OK, thanks for the pointer.

However, I have configured FS in proxy media mode in order to allow 2
jitsi clients to establish a ZRTP audio call between them.
Again, per the wiki here http://wiki.freeswitch.org/wiki/Proxy_Media

聽聽* Proxy: media flows through FS, no media processing options

- RTP proxied by FreeSWITCH (c= modified, that's it)
- FreeSWITCH has no control or even understanding of other SDP parameters (pass through)

Oh ... this is actually wrong from an RFC perspective but I don't think
it is related to your problems.

- Endpoints *MUST* agree on same codec because FreeSWITCH can't help them
- Virtually no features available

By the way, in order to eliminate FreeSWITCH as a factor here and
confirm that your problems really are in Jitsi, could you please create
a SIP account at http://ippi.com and do your tests there?

(From what we've tried this works so I am inclined to think FS is
messing up something here ... or at least both Jitsi and FS contribute
to a global mess, so these tests would help narrow it down).

Cheers,
Emil

路路路

On 19.04.13, 18:46, Privus 007 wrote:

On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

聽聽聽聽Hey Marc,

聽聽聽聽On Apr 11, 2013 8:21 PM, "Marc Abrams" <marca56@gmail.com > <mailto:marca56@gmail.com>> wrote:
聽聽聽聽>
聽聽聽聽> Hi,
聽聽聽聽>
聽聽聽聽> Freeswitch is a proxy as opposed to a B2BUA so should have no
聽聽聽聽issues > routing audio or video. In fact, the the codecs chosen are
聽聽聽聽selected by
聽聽聽聽> negotiation between endpoints.

聽聽聽聽Chiming in for a quick comment: I don't have a lot of experience
聽聽聽聽with FS but as far as I know, it is exactly the opposite of a proxy
聽聽聽聽and the very definition of a B2BUA. This is one of the reasons why
聽聽聽聽Jitsi's Opus support wasn't working there until they recently fixed it.

聽聽聽聽Emil

聽聽聽聽--sent from my mobile
聽聽聽聽>

聽聽聽聽> In the case you describe, if you are doing a call from Jitsi to
聽聽聽聽another Jitsi client and it works sometimes but not others, I don't
聽聽聽聽think the issue is related to Jitsi.
聽聽聽聽>
聽聽聽聽> Is all this on a private network or are the clients going through
聽聽聽聽a firewall or NAT? This is the usual cause of SIP issues.
聽聽聽聽>
聽聽聽聽> Thanks.
聽聽聽聽>
聽聽聽聽> marc.
聽聽聽聽> __________________
聽聽聽聽> +1-949-270-0935 <tel:%2B1-949-270-0935>
聽聽聽聽>
聽聽聽聽>
聽聽聽聽>
聽聽聽聽> On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com > <mailto:privus007@gmail.com>> wrote:
聽聽聽聽>
聽聽聽聽>> Thanks for your reply.
聽聽聽聽>>
聽聽聽聽>> Hmmm. So it seems it is not just some incompatibility with
聽聽聽聽Freeswitch but rather an incompatibility with SIP in general.
聽聽聽聽>>
聽聽聽聽>> That seems like a pretty serious limitation to jitsi's video
聽聽聽聽capability, no? I've also tried putting VP8 at the top of the codec
聽聽聽聽list on both jitsi clients and I still have the same problems and
聽聽聽聽inconsistency described above.
聽聽聽聽>>
聽聽聽聽>> Has anyone else had any success (consistently) with jitsi video
聽聽聽聽through a SIP server?
聽聽聽聽>>
聽聽聽聽>> Thanks
聽聽聽聽>>
聽聽聽聽>>
聽聽聽聽>> On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl > <mailto:J.Witvliet@mindef.nl>> wrote:
聽聽聽聽>>>
聽聽聽聽>>> (Sorry 4 topposting, forced upon me by BB)
聽聽聽聽>>>
聽聽聽聽>>> Yes, i've experimenting with sip-video as well, but with asterisk.
聽聽聽聽>>> I've seen same behaviour* as you, but mostly (!) It boils down,
聽聽聽聽to. Video-codec mismatch between client1/pbx and client2/pbx, or
聽聽聽聽client1/client2.
聽聽聽聽>>>
聽聽聽聽>>> *even difference between client1 calling client2 and client2
聽聽聽聽calling client1 :frowning:
聽聽聽聽>>>
聽聽聽聽>>>
聽聽聽聽>>> With xmpp nothing is inbetween, which can be an advantage, but
聽聽聽聽also a serious limitation.
聽聽聽聽>>>
聽聽聽聽>>>
聽聽聽聽>>> Van: Privus 007 [mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>]
聽聽聽聽>>> Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time
聽聽聽聽>>> Aan: dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
聽聽聽聽>>> Onderwerp: [jitsi-dev] Video Call through SIP (Freeswitch) not
聽聽聽聽working
聽聽聽聽>>>
聽聽聽聽>>> Hello,
聽聽聽聽>>>
聽聽聽聽>>> I've been trying to get video working on a basic SIP call
聽聽聽聽between 2 jitsi (latest nightly) clients. One on windows 7, the
聽聽聽聽other on Mint 14. I'm using Freeswitch as the SIP server and have
聽聽聽聽enabled the "proxy media" variable in the SIP profile. This should
聽聽聽聽theoretically let the 2 jitsi endpoints talk to each other directly
聽聽聽聽with little interference from the server.
聽聽聽聽>>>
聽聽聽聽>>> My results aren't good. Basically the video box remains greyed
聽聽聽聽out on both sides during the call, and there seems to be no video
聽聽聽聽media in the call (although audio works). I've tried playing around
聽聽聽聽with VP8 and H264, to no avail. Also, I often have to hangup the
聽聽聽聽first attempt and try again since jitsi seems to hang after
聽聽聽聽"dialing" (and I see in the server that it never receives anything
聽聽聽聽from jitsi). On the second try Jitsi is able to reach the server as
聽聽聽聽it should, although video still doesn't work.
聽聽聽聽>>>
聽聽聽聽>>> Frustrated with this SIP experiment and Freeswitch, I set up an
聽聽聽聽XMPP server (openfire) and tried the same experiment. This time
聽聽聽聽video worked as it should (most of the time, I still get
聽聽聽聽inconsistent results). Even ZRTP worked well in both audio and video.
聽聽聽聽>>>
聽聽聽聽>>> Before I start sending logs, etc, I was wondering if anyone has
聽聽聽聽been able to use Jitsi's video with SIP, and with Freeswitch in
聽聽聽聽particular.
聽聽聽聽>>>
聽聽聽聽>>> I've also setup the videobridge with openfire and that seemed to
聽聽聽聽work well, although I only tested a little bit.
聽聽聽聽>>>
聽聽聽聽>>> Thanks
聽聽聽聽>>> ________________________________
聽聽聽聽>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
聽聽聽聽Indien u niet de geadresseerde bent of dit bericht abusievelijk aan
聽聽聽聽u is toegezonden, wordt u verzocht dat aan de afzender te melden en
聽聽聽聽het bericht te verwijderen. De Staat aanvaardt geen
聽聽聽聽aansprakelijkheid voor schade, van welke aard ook, die verband houdt
聽聽聽聽met risico's verbonden aan het electronisch verzenden van berichten.
聽聽聽聽>>>
聽聽聽聽>>> This message may contain information that is not intended for
聽聽聽聽you. If you are not the addressee or if this message was sent to you
聽聽聽聽by mistake, you are requested to inform the sender and delete the
聽聽聽聽message. The State accepts no liability for damage of any kind
聽聽聽聽resulting from the risks inherent in the electronic transmission of
聽聽聽聽messages.
聽聽聽聽>>
聽聽聽聽>>
聽聽聽聽>

--
https://jitsi.org


#11

OK thanks Boris, will give that a go on Monday when I'm at work with the cameras.

Tom

路路路

On 12/04/13 21:35, Boris Grozev wrote:

Hey,

On Fri, Apr 12, 2013 at 10:09 PM, Tom Parrott <tomp@tomp.co.uk > <mailto:tomp@tomp.co.uk>> wrote:

聽聽聽聽But as soon as I try and open multiple video streams concurrently
聽聽聽聽(using either XMPP jit.si <http://jit.si> service, or a freeswitch
聽聽聽聽video conference) one or more of the video streams just displays a
聽聽聽聽black window, and usually Jitsi becomes unresponsive.

You might want to try again with the latest nightly, as there was a similar problem fixed just yesterday (in revision 10756).

聽聽聽聽I'm not sure what I am doing differently to others who have go it
聽聽聽聽working.

聽聽聽聽We are using Windows 7 32bit, and the latest stable release with
聽聽聽聽these web cams
聽聽聽聽http://www.ebuyer.com/336948-microsoft-lifecam-hd-3000-for-business-win-usb-t4h-00004

聽聽聽聽We are also using single window mode.

Single window mode hasn't been tested as much as the "regular" one. Can you turn it off and see if it works?

If you have specific issues, please describe them here, and make sure you're running the latest nightlies, because they contain multiple fixes.

Regards,
Boris


#12

Hi

By the way, in order to eliminate FreeSWITCH as a factor here and
confirm that your problems really are in Jitsi, could you please create
a SIP account at http://ippi.com and do your tests there?

Will get around to it this weekend and I'll let you know the results.

Thanks

路路路

On Fri, Apr 19, 2013 at 5:56 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey there,

On 19.04.13, 18:46, Privus 007 wrote:
> Correct, From their wiki here
> http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch
>
> "FreeSWITCH is a B2BUA (back-to-back user agent). This means that it
> actually parses each of the SIP messages it receives. FreeSWITCH can not
> act as a proxy, for instance by forwarding SIP registrations to a
> registrar server."

OK, thanks for the pointer.
>
> However, I have configured FS in proxy media mode in order to allow 2
> jitsi clients to establish a ZRTP audio call between them.
> Again, per the wiki here http://wiki.freeswitch.org/wiki/Proxy_Media
>
> * Proxy: media flows through FS, no media processing options
>
> - RTP proxied by FreeSWITCH (c= modified, that's it)
> - FreeSWITCH has no control or even understanding of other SDP
parameters (pass through)

Oh ... this is actually wrong from an RFC perspective but I don't think
it is related to your problems.

> - Endpoints *MUST* agree on same codec because FreeSWITCH can't help them
> - Virtually no features available

By the way, in order to eliminate FreeSWITCH as a factor here and
confirm that your problems really are in Jitsi, could you please create
a SIP account at http://ippi.com and do your tests there?

(From what we've tried this works so I am inclined to think FS is
messing up something here ... or at least both Jitsi and FS contribute
to a global mess, so these tests would help narrow it down).

Cheers,
Emil
>
>
>
>
> On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov <emcho@jitsi.org > > <mailto:emcho@jitsi.org>> wrote:
>
> Hey Marc,
>
> On Apr 11, 2013 8:21 PM, "Marc Abrams" <marca56@gmail.com > > <mailto:marca56@gmail.com>> wrote:
> >
> > Hi,
> >
> > Freeswitch is a proxy as opposed to a B2BUA so should have no
> issues > routing audio or video. In fact, the the codecs chosen are
> selected by
> > negotiation between endpoints.
>
> Chiming in for a quick comment: I don't have a lot of experience
> with FS but as far as I know, it is exactly the opposite of a proxy
> and the very definition of a B2BUA. This is one of the reasons why
> Jitsi's Opus support wasn't working there until they recently fixed
it.
>
> Emil
>
> --sent from my mobile
> >
>
>
> > In the case you describe, if you are doing a call from Jitsi to
> another Jitsi client and it works sometimes but not others, I don't
> think the issue is related to Jitsi.
> >
> > Is all this on a private network or are the clients going through
> a firewall or NAT? This is the usual cause of SIP issues.
> >
> > Thanks.
> >
> > marc.
> > __________________
> > +1-949-270-0935 <tel:%2B1-949-270-0935>
> >
> >
> >
> > On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com > > <mailto:privus007@gmail.com>> wrote:
> >
> >> Thanks for your reply.
> >>
> >> Hmmm. So it seems it is not just some incompatibility with
> Freeswitch but rather an incompatibility with SIP in general.
> >>
> >> That seems like a pretty serious limitation to jitsi's video
> capability, no? I've also tried putting VP8 at the top of the codec
> list on both jitsi clients and I still have the same problems and
> inconsistency described above.
> >>
> >> Has anyone else had any success (consistently) with jitsi video
> through a SIP server?
> >>
> >> Thanks
> >>
> >>
> >> On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl > > <mailto:J.Witvliet@mindef.nl>> wrote:
> >>>
> >>> (Sorry 4 topposting, forced upon me by BB)
> >>>
> >>> Yes, i've experimenting with sip-video as well, but with
asterisk.
> >>> I've seen same behaviour* as you, but mostly (!) It boils down,
> to. Video-codec mismatch between client1/pbx and client2/pbx, or
> client1/client2.
> >>>
> >>> *even difference between client1 calling client2 and client2
> calling client1 :frowning:
> >>>
> >>>
> >>> With xmpp nothing is inbetween, which can be an advantage, but
> also a serious limitation.
> >>>
> >>>
> >>> Van: Privus 007 [mailto:privus007@gmail.com
> <mailto:privus007@gmail.com>]
> >>> Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe Standard
Time
> >>> Aan: dev@jitsi.java.net <mailto:dev@jitsi.java.net>
> <dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
> >>> Onderwerp: [jitsi-dev] Video Call through SIP (Freeswitch) not
> working
> >>>
> >>> Hello,
> >>>
> >>> I've been trying to get video working on a basic SIP call
> between 2 jitsi (latest nightly) clients. One on windows 7, the
> other on Mint 14. I'm using Freeswitch as the SIP server and have
> enabled the "proxy media" variable in the SIP profile. This should
> theoretically let the 2 jitsi endpoints talk to each other directly
> with little interference from the server.
> >>>
> >>> My results aren't good. Basically the video box remains greyed
> out on both sides during the call, and there seems to be no video
> media in the call (although audio works). I've tried playing around
> with VP8 and H264, to no avail. Also, I often have to hangup the
> first attempt and try again since jitsi seems to hang after
> "dialing" (and I see in the server that it never receives anything
> from jitsi). On the second try Jitsi is able to reach the server as
> it should, although video still doesn't work.
> >>>
> >>> Frustrated with this SIP experiment and Freeswitch, I set up an
> XMPP server (openfire) and tried the same experiment. This time
> video worked as it should (most of the time, I still get
> inconsistent results). Even ZRTP worked well in both audio and video.
> >>>
> >>> Before I start sending logs, etc, I was wondering if anyone has
> been able to use Jitsi's video with SIP, and with Freeswitch in
> particular.
> >>>
> >>> I've also setup the videobridge with openfire and that seemed to
> work well, although I only tested a little bit.
> >>>
> >>> Thanks
> >>> ________________________________
> >>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan
> u is toegezonden, wordt u verzocht dat aan de afzender te melden en
> het bericht te verwijderen. De Staat aanvaardt geen
> aansprakelijkheid voor schade, van welke aard ook, die verband houdt
> met risico's verbonden aan het electronisch verzenden van berichten.
> >>>
> >>> This message may contain information that is not intended for
> you. If you are not the addressee or if this message was sent to you
> by mistake, you are requested to inform the sender and delete the
> message. The State accepts no liability for damage of any kind
> resulting from the risks inherent in the electronic transmission of
> messages.
> >>
> >>
> >
>
>

--
https://jitsi.org


#13

I find that if you disable the video and re-enable during a call it
seems to allow 2 parallel video streams to work.

The issue seems to be
related to multiple video streams, any usage that only requires a single
video stream (for example the echo test, or a single party-speaking
conference) works fine.

But if you try and see the video from multiple
parties at once it starts to fail.

Hi

By the way, in order to eliminate FreeSWITCH as a

factor here and

>confirm that your problems really are in Jitsi, could

you please create

>a SIP account at http://ippi.com [3] and do your

tests there?

Will get around to it this weekend and I'll let you

know the results.

Thanks

Hey there,

> Correct, From their wiki here
>

http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch [1]

> "FreeSWITCH is a B2BUA (back-to-back user agent). This means that

it

> actually parses each of the SIP messages it receives. FreeSWITCH

can not

> act as a proxy, for instance by forwarding SIP

registrations to a

> registrar server."

OK, thanks for the

pointer.

> However, I have configured FS in proxy media mode

in order to allow 2

> jitsi clients to establish a ZRTP audio call

between them.

> Again, per the wiki here

http://wiki.freeswitch.org/wiki/Proxy_Media [2]

> > * Proxy: media

flows through FS, no media processing options

> - RTP

proxied by FreeSWITCH (c= modified, that's it)

> - FreeSWITCH has no

control or even understanding of other SDP parameters (pass through)

Oh ... this is actually wrong from an RFC perspective but I don't

think

it is related to your problems.

> - Endpoints *MUST*

agree on same codec because FreeSWITCH can't help them

> - Virtually

no features available

By the way, in order to eliminate

FreeSWITCH as a factor here and

confirm that your problems really are

in Jitsi, could you please create

a SIP account at http://ippi.com

[3] and do your tests there?

(From what we've tried this works so

I am inclined to think FS is

messing up something here ... or at

least both Jitsi and FS contribute

to a global mess, so these tests

would help narrow it down).

Cheers,
Emil

>
>

>
> Hey Marc,
>
> >
> > Hi,
> >
> >

Freeswitch is a proxy as opposed to a B2BUA so should have no

>

issues > routing audio or video. In fact, the the codecs chosen are

>

selected by

> > negotiation between endpoints.
>
> Chiming in

for a quick comment: I don't have a lot of experience

> with FS but

as far as I know, it is exactly the opposite of a proxy

> and the

very definition of a B2BUA. This is one of the reasons why

> Jitsi's

Opus support wasn't working there until they recently fixed it.

>

Emil

>
> --sent from my mobile
> >
>
>
> > In the

case you describe, if you are doing a call from Jitsi to

> another

Jitsi client and it works sometimes but not others, I don't

> think

the issue is related to Jitsi.

> >
> > Is all this on a private

network or are the clients going through

> a firewall or NAT? This is

the usual cause of SIP issues.

> >
> > Thanks.
> >
> >

marc.

> > __________________ > > +1-949-270-0935 [4]

<tel:%2B1-949-270-0935>

>

> >
> >
> >
> >> Thanks for your

reply.

> >>
> >> Hmmm. So it seems it is not just some

incompatibility with

> Freeswitch but rather an incompatibility with

SIP in general.

> >>
> >> That seems like a pretty serious

limitation to jitsi's video

> capability, no? I've also tried putting

VP8 at the top of the codec

> list on both jitsi clients and I still

have the same problems and

> inconsistency described above.
>

> >> Has anyone else had any success (consistently) with jitsi

video

> through a SIP server?
> >>
> >> Thanks
> >>
>

> >>>
> >>> (Sorry 4

topposting, forced upon me by BB)

> >>>
> >>> Yes, i've

experimenting with sip-video as well, but with asterisk.

> >>> I've

seen same behaviour* as you, but mostly (!) It boils down,

> to.

Video-codec mismatch between client1/pbx and client2/pbx, or

>

client1/client2.

> >>>
> >>> *even difference between client1

calling client2 and client2

> calling client1 :frowning:
> >>>
> >>>

>>> With xmpp nothing is inbetween, which can be an advantage, but

also a serious limitation.

> >>>
> >>>
> >>> Van: Privus 007

[mailto:privus007@gmail.com

> <mailto:privus007@gmail.com>]
> >>>

Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe Standard Time >

Aan: dev@jitsi.java.net <mailto:dev@jitsi.java.net>

>

<dev@jitsi.java.net <mailto:dev@jitsi.java.net>>

>>> Onderwerp:

[jitsi-dev] Video Call through SIP (Freeswitch) not

> working
>

> >>> Hello,
> >>>
> >>> I've been trying to get video

working on a basic SIP call

> between 2 jitsi (latest nightly)

clients. One on windows 7, the

> other on Mint 14. I'm using

Freeswitch as the SIP server and have

> enabled the "proxy media"

variable in the SIP profile. This should

> theoretically let the 2

jitsi endpoints talk to each other directly

> with little

interference from the server.

> >>>
> >>> My results aren't good.

Basically the video box remains greyed

> out on both sides during the

call, and there seems to be no video

> media in the call (although

audio works). I've tried playing around

> with VP8 and H264, to no

avail. Also, I often have to hangup the

> first attempt and try again

since jitsi seems to hang after

> "dialing" (and I see in the server

that it never receives anything

> from jitsi). On the second try

Jitsi is able to reach the server as

> it should, although video

still doesn't work.

> >>>
> >>> Frustrated with this SIP

experiment and Freeswitch, I set up an

> XMPP server (openfire) and

tried the same experiment. This time

> video worked as it should

(most of the time, I still get

> inconsistent results). Even ZRTP

worked well in both audio and video.

> >>>
> >>> Before I start

sending logs, etc, I was wondering if anyone has

> been able to use

Jitsi's video with SIP, and with Freeswitch in

> particular.
>

> >>> I've also setup the videobridge with openfire and that

seemed to

> work well, although I only tested a little bit.
>

> >>> Thanks
> >>> ________________________________
> >>>

Dit bericht kan informatie bevatten die niet voor u is bestemd.

>

Indien u niet de geadresseerde bent of dit bericht abusievelijk aan

>

u is toegezonden, wordt u verzocht dat aan de afzender te melden en

>

het bericht te verwijderen. De Staat aanvaardt geen

>

aansprakelijkheid voor schade, van welke aard ook, die verband houdt

met risico's verbonden aan het electronisch verzenden van

berichten.

> >>>
> >>> This message may contain information that

is not intended for

> you. If you are not the addressee or if this

message was sent to you

> by mistake, you are requested to inform the

sender and delete the

> message. The State accepts no liability for

damage of any kind

> resulting from the risks inherent in the

electronic transmission of

> messages.
> >>
> >>
> >
>

--
https://jitsi.org [5]

Links:

路路路

On 2013-04-19 17:59, Privus 007 wrote:

On Fri, Apr 19, 2013 at 5:56 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 19.04.13, 18:46, Privus 007 wrote:
> On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov <emcho@jitsi.org >>> <mailto:emcho@jitsi.org>> wrote:
> On Apr 11, 2013 8:21 PM, "Marc Abrams" <marca56@gmail.com >>> <mailto:marca56@gmail.com>> wrote:
> > On Apr 11, 2013, at 10:13 AM, Privus 007 <privus007@gmail.com >>> <mailto:privus007@gmail.com>> wrote:
> >> On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl >>> <mailto:J.Witvliet@mindef.nl>> wrote:

------
[1]
http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch
[2]
http://wiki.freeswitch.org/wiki/Proxy_Media
[3] http://ippi.com
[4]
tel:%2B1-949-270-0935
[5] https://jitsi.org


#14

I find that if you disable the video and re-enable during a call it
seems to allow 2 parallel video streams to work.

Interesting. Can you also give it a try on ippi.com and let us know how
it goes there?

The issue seems to be related to multiple video streams, any usage that
only requires a single video stream (for example the echo test, or a
single party-speaking conference) works fine.

But if you try and see the video from multiple parties at once it starts
to fail.

Hmm this sounds like it might be FS's fault. We've never tested multiple
video recipients with FS but when you do this you have to make sure
every new receiver gets a key frame or otherwise they won't be able to
decode the stream. Jitsi does send AVPF PLI requests over RTCP but FS
has to relay those.

Is your environment available for a test from the Internet?

Emil

路路路

On 19.04.13, 19:15, tomp@tomp.co.uk wrote:

On 2013-04-19 17:59, Privus 007 wrote:

Hi

>By the way, in order to eliminate FreeSWITCH as a factor here and
>confirm that your problems really are in Jitsi, could you please create
>a SIP account at http://ippi.com and do your tests there?

Will get around to it this weekend and I'll let you know the results.

Thanks

On Fri, Apr 19, 2013 at 5:56 PM, Emil Ivov <emcho@jitsi.org >> <mailto:emcho@jitsi.org>> wrote:

聽聽聽聽Hey there,

聽聽聽聽On 19.04.13, 18:46, Privus 007 wrote:
聽聽聽聽> Correct, From their wiki here
聽聽聽聽> http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch
聽聽聽聽>
聽聽聽聽> "FreeSWITCH is a B2BUA (back-to-back user agent). This means that it
聽聽聽聽> actually parses each of the SIP messages it receives. FreeSWITCH
聽聽聽聽can not
聽聽聽聽> act as a proxy, for instance by forwarding SIP registrations to a
聽聽聽聽> registrar server."

聽聽聽聽OK, thanks for the pointer.
聽聽聽聽>
聽聽聽聽> However, I have configured FS in proxy media mode in order to
聽聽聽聽allow 2
聽聽聽聽> jitsi clients to establish a ZRTP audio call between them.
聽聽聽聽> Again, per the wiki here http://wiki.freeswitch.org/wiki/Proxy_Media
聽聽聽聽>
聽聽聽聽> * Proxy: media flows through FS, no media processing options
聽聽聽聽>
聽聽聽聽> - RTP proxied by FreeSWITCH (c= modified, that's it)
聽聽聽聽> - FreeSWITCH has no control or even understanding of other SDP
聽聽聽聽parameters (pass through)

聽聽聽聽Oh ... this is actually wrong from an RFC perspective but I don't
聽聽聽聽think
聽聽聽聽it is related to your problems.

聽聽聽聽> - Endpoints *MUST* agree on same codec because FreeSWITCH can't
聽聽聽聽help them
聽聽聽聽> - Virtually no features available

聽聽聽聽By the way, in order to eliminate FreeSWITCH as a factor here and
聽聽聽聽confirm that your problems really are in Jitsi, could you please
聽聽聽聽create
聽聽聽聽a SIP account at http://ippi.com and do your tests there?

聽聽聽聽(From what we've tried this works so I am inclined to think FS is
聽聽聽聽messing up something here ... or at least both Jitsi and FS contribute
聽聽聽聽to a global mess, so these tests would help narrow it down).

聽聽聽聽Cheers,
聽聽聽聽Emil
聽聽聽聽>
聽聽聽聽>
聽聽聽聽>
聽聽聽聽>
聽聽聽聽> On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov <emcho@jitsi.org >> <mailto:emcho@jitsi.org> >> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
聽聽聽聽>
聽聽聽聽> Hey Marc,
聽聽聽聽>
聽聽聽聽> On Apr 11, 2013 8:21 PM, "Marc Abrams" <marca56@gmail.com >> <mailto:marca56@gmail.com> >> > <mailto:marca56@gmail.com <mailto:marca56@gmail.com>>> wrote:
聽聽聽聽> >
聽聽聽聽> > Hi,
聽聽聽聽> >
聽聽聽聽> > Freeswitch is a proxy as opposed to a B2BUA so should have no
聽聽聽聽> issues > routing audio or video. In fact, the the codecs
聽聽聽聽chosen are
聽聽聽聽> selected by
聽聽聽聽> > negotiation between endpoints.
聽聽聽聽>
聽聽聽聽> Chiming in for a quick comment: I don't have a lot of experience
聽聽聽聽> with FS but as far as I know, it is exactly the opposite of
聽聽聽聽a proxy
聽聽聽聽> and the very definition of a B2BUA. This is one of the
聽聽聽聽reasons why
聽聽聽聽> Jitsi's Opus support wasn't working there until they
聽聽聽聽recently fixed it.
聽聽聽聽>
聽聽聽聽> Emil
聽聽聽聽>
聽聽聽聽> --sent from my mobile
聽聽聽聽> >
聽聽聽聽>
聽聽聽聽>
聽聽聽聽> > In the case you describe, if you are doing a call from
聽聽聽聽Jitsi to
聽聽聽聽> another Jitsi client and it works sometimes but not others,
聽聽聽聽I don't
聽聽聽聽> think the issue is related to Jitsi.
聽聽聽聽> >
聽聽聽聽> > Is all this on a private network or are the clients going
聽聽聽聽through
聽聽聽聽> a firewall or NAT? This is the usual cause of SIP issues.
聽聽聽聽> >
聽聽聽聽> > Thanks.
聽聽聽聽> >
聽聽聽聽> > marc.
聽聽聽聽> > __________________
聽聽聽聽> > +1-949-270-0935 <tel:%2B1-949-270-0935>
聽聽聽聽<tel:%2B1-949-270-0935>
聽聽聽聽> >
聽聽聽聽> >
聽聽聽聽> >
聽聽聽聽> > On Apr 11, 2013, at 10:13 AM, Privus 007 >> <privus007@gmail.com <mailto:privus007@gmail.com> >> > <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>> >> wrote:
聽聽聽聽> >
聽聽聽聽> >> Thanks for your reply.
聽聽聽聽> >>
聽聽聽聽> >> Hmmm. So it seems it is not just some incompatibility with
聽聽聽聽> Freeswitch but rather an incompatibility with SIP in general.
聽聽聽聽> >>
聽聽聽聽> >> That seems like a pretty serious limitation to jitsi's video
聽聽聽聽> capability, no? I've also tried putting VP8 at the top of
聽聽聽聽the codec
聽聽聽聽> list on both jitsi clients and I still have the same
聽聽聽聽problems and
聽聽聽聽> inconsistency described above.
聽聽聽聽> >>
聽聽聽聽> >> Has anyone else had any success (consistently) with jitsi
聽聽聽聽video
聽聽聽聽> through a SIP server?
聽聽聽聽> >>
聽聽聽聽> >> Thanks
聽聽聽聽> >>
聽聽聽聽> >>
聽聽聽聽> >> On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl >> <mailto:J.Witvliet@mindef.nl> >> > <mailto:J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>>> >> wrote:
聽聽聽聽> >>>
聽聽聽聽> >>> (Sorry 4 topposting, forced upon me by BB)
聽聽聽聽> >>>
聽聽聽聽> >>> Yes, i've experimenting with sip-video as well, but with
聽聽聽聽asterisk.
聽聽聽聽> >>> I've seen same behaviour* as you, but mostly (!) It
聽聽聽聽boils down,
聽聽聽聽> to. Video-codec mismatch between client1/pbx and client2/pbx, or
聽聽聽聽> client1/client2.
聽聽聽聽> >>>
聽聽聽聽> >>> *even difference between client1 calling client2 and client2
聽聽聽聽> calling client1 :frowning:
聽聽聽聽> >>>
聽聽聽聽> >>>
聽聽聽聽> >>> With xmpp nothing is inbetween, which can be an
聽聽聽聽advantage, but
聽聽聽聽> also a serious limitation.
聽聽聽聽> >>>
聽聽聽聽> >>>
聽聽聽聽> >>> Van: Privus 007 [mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>
聽聽聽聽> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>]
聽聽聽聽> >>> Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe
聽聽聽聽Standard Time
聽聽聽聽> >>> Aan: dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
聽聽聽聽> <dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>
聽聽聽聽> >>> Onderwerp: [jitsi-dev] Video Call through SIP
聽聽聽聽(Freeswitch) not
聽聽聽聽> working
聽聽聽聽> >>>
聽聽聽聽> >>> Hello,
聽聽聽聽> >>>
聽聽聽聽> >>> I've been trying to get video working on a basic SIP call
聽聽聽聽> between 2 jitsi (latest nightly) clients. One on windows 7, the
聽聽聽聽> other on Mint 14. I'm using Freeswitch as the SIP server and
聽聽聽聽have
聽聽聽聽> enabled the "proxy media" variable in the SIP profile. This
聽聽聽聽should
聽聽聽聽> theoretically let the 2 jitsi endpoints talk to each other
聽聽聽聽directly
聽聽聽聽> with little interference from the server.
聽聽聽聽> >>>
聽聽聽聽> >>> My results aren't good. Basically the video box remains
聽聽聽聽greyed
聽聽聽聽> out on both sides during the call, and there seems to be no
聽聽聽聽video
聽聽聽聽> media in the call (although audio works). I've tried playing
聽聽聽聽around
聽聽聽聽> with VP8 and H264, to no avail. Also, I often have to hangup the
聽聽聽聽> first attempt and try again since jitsi seems to hang after
聽聽聽聽> "dialing" (and I see in the server that it never receives
聽聽聽聽anything
聽聽聽聽> from jitsi). On the second try Jitsi is able to reach the
聽聽聽聽server as
聽聽聽聽> it should, although video still doesn't work.
聽聽聽聽> >>>
聽聽聽聽> >>> Frustrated with this SIP experiment and Freeswitch, I
聽聽聽聽set up an
聽聽聽聽> XMPP server (openfire) and tried the same experiment. This time
聽聽聽聽> video worked as it should (most of the time, I still get
聽聽聽聽> inconsistent results). Even ZRTP worked well in both audio
聽聽聽聽and video.
聽聽聽聽> >>>
聽聽聽聽> >>> Before I start sending logs, etc, I was wondering if
聽聽聽聽anyone has
聽聽聽聽> been able to use Jitsi's video with SIP, and with Freeswitch in
聽聽聽聽> particular.
聽聽聽聽> >>>
聽聽聽聽> >>> I've also setup the videobridge with openfire and that
聽聽聽聽seemed to
聽聽聽聽> work well, although I only tested a little bit.
聽聽聽聽> >>>
聽聽聽聽> >>> Thanks
聽聽聽聽> >>> ________________________________
聽聽聽聽> >>> Dit bericht kan informatie bevatten die niet voor u is
聽聽聽聽bestemd.
聽聽聽聽> Indien u niet de geadresseerde bent of dit bericht
聽聽聽聽abusievelijk aan
聽聽聽聽> u is toegezonden, wordt u verzocht dat aan de afzender te
聽聽聽聽melden en
聽聽聽聽> het bericht te verwijderen. De Staat aanvaardt geen
聽聽聽聽> aansprakelijkheid voor schade, van welke aard ook, die
聽聽聽聽verband houdt
聽聽聽聽> met risico's verbonden aan het electronisch verzenden van
聽聽聽聽berichten.
聽聽聽聽> >>>
聽聽聽聽> >>> This message may contain information that is not
聽聽聽聽intended for
聽聽聽聽> you. If you are not the addressee or if this message was
聽聽聽聽sent to you
聽聽聽聽> by mistake, you are requested to inform the sender and
聽聽聽聽delete the
聽聽聽聽> message. The State accepts no liability for damage of any kind
聽聽聽聽> resulting from the risks inherent in the electronic
聽聽聽聽transmission of
聽聽聽聽> messages.
聽聽聽聽> >>
聽聽聽聽> >>
聽聽聽聽> >
聽聽聽聽>
聽聽聽聽>

聽聽聽聽--
聽聽聽聽https://jitsi.org

--
https://jitsi.org


#15

Hi,

Well I just finished testing with 2 ippi accounts and today's nightly build
on a windows 7 machine and a mint 14 laptop.
Indeed the video worked rather well (sometimes I had to hangup and try
again but on the 2nd try it always worked). Now desktop sharing seems still
a little buggy since when I tried remote control both times the call was
dropped.
Still, this test does seem to point the "blame" to FS (or, more likely,
something I've misconfigured) since I can never get video working with FS
(and audio doesn't work with the nightly, only with 2.0 stable and with my
csipsimple and groundwire clients).
I'm not sure what the issue is with FS, but tomorrow I'll do some more
testing and try, for example, to enable "bypass media" in the FS profile to
see if that helps. I'm not sure where the problem lies, but I'll keep
reporting on my progress since it is such a shame that FS seems to have
issues with jitsi.

Cheers

P.S. I just realised that jitsi doesn't have any STUN or ICE options with
the SIP transport (or am I blind?), only with XMPP. Perhaps that's why I
can get video working when using the openfire server located on the same
machine as FS? Maybe it is a NAT issue with SIP after all? Just a thought.

路路路

On Fri, Apr 19, 2013 at 7:32 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 19.04.13, 19:15, tomp@tomp.co.uk wrote:
> I find that if you disable the video and re-enable during a call it
> seems to allow 2 parallel video streams to work.

Interesting. Can you also give it a try on ippi.com and let us know how
it goes there?

> The issue seems to be related to multiple video streams, any usage that
> only requires a single video stream (for example the echo test, or a
> single party-speaking conference) works fine.
>
>
>
> But if you try and see the video from multiple parties at once it starts
> to fail.

Hmm this sounds like it might be FS's fault. We've never tested multiple
video recipients with FS but when you do this you have to make sure
every new receiver gets a key frame or otherwise they won't be able to
decode the stream. Jitsi does send AVPF PLI requests over RTCP but FS
has to relay those.

Is your environment available for a test from the Internet?

Emil

>
> On 2013-04-19 17:59, Privus 007 wrote:
>
>> Hi
>>
>> >By the way, in order to eliminate FreeSWITCH as a factor here and
>> >confirm that your problems really are in Jitsi, could you please create
>> >a SIP account at http://ippi.com and do your tests there?
>>
>> Will get around to it this weekend and I'll let you know the results.
>>
>> Thanks
>>
>>
>> On Fri, Apr 19, 2013 at 5:56 PM, Emil Ivov <emcho@jitsi.org > >> <mailto:emcho@jitsi.org>> wrote:
>>
>> Hey there,
>>
>> On 19.04.13, 18:46, Privus 007 wrote:
>> > Correct, From their wiki here
>> > http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch
>> >
>> > "FreeSWITCH is a B2BUA (back-to-back user agent). This means that
it
>> > actually parses each of the SIP messages it receives. FreeSWITCH
>> can not
>> > act as a proxy, for instance by forwarding SIP registrations to a
>> > registrar server."
>>
>> OK, thanks for the pointer.
>> >
>> > However, I have configured FS in proxy media mode in order to
>> allow 2
>> > jitsi clients to establish a ZRTP audio call between them.
>> > Again, per the wiki here
http://wiki.freeswitch.org/wiki/Proxy_Media
>> >
>> > * Proxy: media flows through FS, no media processing options
>> >
>> > - RTP proxied by FreeSWITCH (c= modified, that's it)
>> > - FreeSWITCH has no control or even understanding of other SDP
>> parameters (pass through)
>>
>> Oh ... this is actually wrong from an RFC perspective but I don't
>> think
>> it is related to your problems.
>>
>> > - Endpoints *MUST* agree on same codec because FreeSWITCH can't
>> help them
>> > - Virtually no features available
>>
>> By the way, in order to eliminate FreeSWITCH as a factor here and
>> confirm that your problems really are in Jitsi, could you please
>> create
>> a SIP account at http://ippi.com and do your tests there?
>>
>> (From what we've tried this works so I am inclined to think FS is
>> messing up something here ... or at least both Jitsi and FS
contribute
>> to a global mess, so these tests would help narrow it down).
>>
>> Cheers,
>> Emil
>> >
>> >
>> >
>> >
>> > On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov <emcho@jitsi.org > >> <mailto:emcho@jitsi.org> > >> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
>> >
>> > Hey Marc,
>> >
>> > On Apr 11, 2013 8:21 PM, "Marc Abrams" <marca56@gmail.com > >> <mailto:marca56@gmail.com> > >> > <mailto:marca56@gmail.com <mailto:marca56@gmail.com>>> wrote:
>> > >
>> > > Hi,
>> > >
>> > > Freeswitch is a proxy as opposed to a B2BUA so should have
no
>> > issues > routing audio or video. In fact, the the codecs
>> chosen are
>> > selected by
>> > > negotiation between endpoints.
>> >
>> > Chiming in for a quick comment: I don't have a lot of
experience
>> > with FS but as far as I know, it is exactly the opposite of
>> a proxy
>> > and the very definition of a B2BUA. This is one of the
>> reasons why
>> > Jitsi's Opus support wasn't working there until they
>> recently fixed it.
>> >
>> > Emil
>> >
>> > --sent from my mobile
>> > >
>> >
>> >
>> > > In the case you describe, if you are doing a call from
>> Jitsi to
>> > another Jitsi client and it works sometimes but not others,
>> I don't
>> > think the issue is related to Jitsi.
>> > >
>> > > Is all this on a private network or are the clients going
>> through
>> > a firewall or NAT? This is the usual cause of SIP issues.
>> > >
>> > > Thanks.
>> > >
>> > > marc.
>> > > __________________
>> > > +1-949-270-0935 <tel:%2B1-949-270-0935>
>> <tel:%2B1-949-270-0935>
>> > >
>> > >
>> > >
>> > > On Apr 11, 2013, at 10:13 AM, Privus 007 > >> <privus007@gmail.com <mailto:privus007@gmail.com> > >> > <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>> > >> wrote:
>> > >
>> > >> Thanks for your reply.
>> > >>
>> > >> Hmmm. So it seems it is not just some incompatibility with
>> > Freeswitch but rather an incompatibility with SIP in general.
>> > >>
>> > >> That seems like a pretty serious limitation to jitsi's
video
>> > capability, no? I've also tried putting VP8 at the top of
>> the codec
>> > list on both jitsi clients and I still have the same
>> problems and
>> > inconsistency described above.
>> > >>
>> > >> Has anyone else had any success (consistently) with jitsi
>> video
>> > through a SIP server?
>> > >>
>> > >> Thanks
>> > >>
>> > >>
>> > >> On Wed, Apr 10, 2013 at 8:42 AM, <J.Witvliet@mindef.nl > >> <mailto:J.Witvliet@mindef.nl> > >> > <mailto:J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>>> > >> wrote:
>> > >>>
>> > >>> (Sorry 4 topposting, forced upon me by BB)
>> > >>>
>> > >>> Yes, i've experimenting with sip-video as well, but with
>> asterisk.
>> > >>> I've seen same behaviour* as you, but mostly (!) It
>> boils down,
>> > to. Video-codec mismatch between client1/pbx and client2/pbx,
or
>> > client1/client2.
>> > >>>
>> > >>> *even difference between client1 calling client2 and
client2
>> > calling client1 :frowning:
>> > >>>
>> > >>>
>> > >>> With xmpp nothing is inbetween, which can be an
>> advantage, but
>> > also a serious limitation.
>> > >>>
>> > >>>
>> > >>> Van: Privus 007 [mailto:privus007@gmail.com
>> <mailto:privus007@gmail.com>
>> > <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>]
>> > >>> Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe
>> Standard Time
>> > >>> Aan: dev@jitsi.java.net <mailto:dev@jitsi.java.net>
>> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
>> > <dev@jitsi.java.net <mailto:dev@jitsi.java.net>
>> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>
>> > >>> Onderwerp: [jitsi-dev] Video Call through SIP
>> (Freeswitch) not
>> > working
>> > >>>
>> > >>> Hello,
>> > >>>
>> > >>> I've been trying to get video working on a basic SIP call
>> > between 2 jitsi (latest nightly) clients. One on windows 7,
the
>> > other on Mint 14. I'm using Freeswitch as the SIP server and
>> have
>> > enabled the "proxy media" variable in the SIP profile. This
>> should
>> > theoretically let the 2 jitsi endpoints talk to each other
>> directly
>> > with little interference from the server.
>> > >>>
>> > >>> My results aren't good. Basically the video box remains
>> greyed
>> > out on both sides during the call, and there seems to be no
>> video
>> > media in the call (although audio works). I've tried playing
>> around
>> > with VP8 and H264, to no avail. Also, I often have to hangup
the
>> > first attempt and try again since jitsi seems to hang after
>> > "dialing" (and I see in the server that it never receives
>> anything
>> > from jitsi). On the second try Jitsi is able to reach the
>> server as
>> > it should, although video still doesn't work.
>> > >>>
>> > >>> Frustrated with this SIP experiment and Freeswitch, I
>> set up an
>> > XMPP server (openfire) and tried the same experiment. This
time
>> > video worked as it should (most of the time, I still get
>> > inconsistent results). Even ZRTP worked well in both audio
>> and video.
>> > >>>
>> > >>> Before I start sending logs, etc, I was wondering if
>> anyone has
>> > been able to use Jitsi's video with SIP, and with Freeswitch
in
>> > particular.
>> > >>>
>> > >>> I've also setup the videobridge with openfire and that
>> seemed to
>> > work well, although I only tested a little bit.
>> > >>>
>> > >>> Thanks
>> > >>> ________________________________
>> > >>> Dit bericht kan informatie bevatten die niet voor u is
>> bestemd.
>> > Indien u niet de geadresseerde bent of dit bericht
>> abusievelijk aan
>> > u is toegezonden, wordt u verzocht dat aan de afzender te
>> melden en
>> > het bericht te verwijderen. De Staat aanvaardt geen
>> > aansprakelijkheid voor schade, van welke aard ook, die
>> verband houdt
>> > met risico's verbonden aan het electronisch verzenden van
>> berichten.
>> > >>>
>> > >>> This message may contain information that is not
>> intended for
>> > you. If you are not the addressee or if this message was
>> sent to you
>> > by mistake, you are requested to inform the sender and
>> delete the
>> > message. The State accepts no liability for damage of any kind
>> > resulting from the risks inherent in the electronic
>> transmission of
>> > messages.
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>> --
>> https://jitsi.org
>>
>

--
https://jitsi.org


#16

Hey there,

Hi,

Well I just finished testing with 2 ippi accounts and today's nightly
build on a windows 7 machine and a mint 14 laptop.
Indeed the video worked rather well

OK, that's good to hear!

(sometimes I had to hangup and try
again but on the 2nd try it always worked). Now desktop sharing seems
still a little buggy since when I tried remote control both times the
call was dropped.

OK, sorry to come up with excuses all the time but this really is their
fault :). We send desktop control messages through signalling and
sometimes the server gets confused and starts sending back error
responses. (Which is why we are thinking of launching a proof-of-concept
SIP service on jit.si, similar to the XMPP one we already have there).

Still, this test does seem to point the "blame" to FS (or, more likely,
something I've misconfigured) since I can never get video working with
FS (and audio doesn't work with the nightly, only with 2.0 stable and
with my csipsimple and groundwire clients).

Maybe that has something to do with Opus. I know they had an issue with
it that was fixed in trunk at some point, but I am not sure if that
particular revision has already made it into a release.

I'm not sure what the issue is with FS, but tomorrow I'll do some more
testing and try, for example, to enable "bypass media" in the FS profile
to see if that helps. I'm not sure where the problem lies, but I'll keep
reporting on my progress since it is such a shame that FS seems to have
issues with jitsi.

Thanks!

P.S. I just realised that jitsi doesn't have any STUN or ICE options
with the SIP transport (or am I blind?), only with XMPP.

You are not blind! :slight_smile: We do only have ICE for XMPP currently. SIP should
follow soon (we'd need that for WebRTC interop) but I can't give you an
ETA. Hopefully we'd have it this summer.

Perhaps that's
why I can get video working when using the openfire server located on
the same machine as FS? Maybe it is a NAT issue with SIP after all? Just
a thought.

Mmmm ... I didn't get what the relationship with Openfire. If you have
Openfire (and as long as you have jingle nodes enabled) then you should
be using ICE to pick a route.

With SIP we rely on Hosted NAT Traversal (and latching) which most SIP
services provide.

Again, we are also thinking of doing ICE with SIP but that's not there yet.

Cheers,
Emil

路路路

On 19.04.13, 23:03, Privus 007 wrote:

On Fri, Apr 19, 2013 at 7:32 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

聽聽聽聽On 19.04.13, 19:15, tomp@tomp.co.uk <mailto:tomp@tomp.co.uk> wrote:
聽聽聽聽> I find that if you disable the video and re-enable during a call it
聽聽聽聽> seems to allow 2 parallel video streams to work.

聽聽聽聽Interesting. Can you also give it a try on ippi.com
聽聽聽聽<http://ippi.com> and let us know how
聽聽聽聽it goes there?

聽聽聽聽> The issue seems to be related to multiple video streams, any usage
聽聽聽聽that
聽聽聽聽> only requires a single video stream (for example the echo test, or a
聽聽聽聽> single party-speaking conference) works fine.
聽聽聽聽>
聽聽聽聽>
聽聽聽聽>
聽聽聽聽> But if you try and see the video from multiple parties at once it
聽聽聽聽starts
聽聽聽聽> to fail.

聽聽聽聽Hmm this sounds like it might be FS's fault. We've never tested multiple
聽聽聽聽video recipients with FS but when you do this you have to make sure
聽聽聽聽every new receiver gets a key frame or otherwise they won't be able to
聽聽聽聽decode the stream. Jitsi does send AVPF PLI requests over RTCP but FS
聽聽聽聽has to relay those.

聽聽聽聽Is your environment available for a test from the Internet?

聽聽聽聽Emil

聽聽聽聽>
聽聽聽聽> On 2013-04-19 17:59, Privus 007 wrote:
聽聽聽聽>
聽聽聽聽>> Hi
聽聽聽聽>>
聽聽聽聽>> >By the way, in order to eliminate FreeSWITCH as a factor here and
聽聽聽聽>> >confirm that your problems really are in Jitsi, could you please
聽聽聽聽create
聽聽聽聽>> >a SIP account at http://ippi.com and do your tests there?
聽聽聽聽>>
聽聽聽聽>> Will get around to it this weekend and I'll let you know the results.
聽聽聽聽>>
聽聽聽聽>> Thanks
聽聽聽聽>>
聽聽聽聽>>
聽聽聽聽>> On Fri, Apr 19, 2013 at 5:56 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org> > >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
聽聽聽聽>>
聽聽聽聽>> Hey there,
聽聽聽聽>>
聽聽聽聽>> On 19.04.13, 18:46, Privus 007 wrote:
聽聽聽聽>> > Correct, From their wiki here
聽聽聽聽>> > http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch
聽聽聽聽>> >
聽聽聽聽>> > "FreeSWITCH is a B2BUA (back-to-back user agent). This
聽聽聽聽means that it
聽聽聽聽>> > actually parses each of the SIP messages it receives.
聽聽聽聽FreeSWITCH
聽聽聽聽>> can not
聽聽聽聽>> > act as a proxy, for instance by forwarding SIP
聽聽聽聽registrations to a
聽聽聽聽>> > registrar server."
聽聽聽聽>>
聽聽聽聽>> OK, thanks for the pointer.
聽聽聽聽>> >
聽聽聽聽>> > However, I have configured FS in proxy media mode in order to
聽聽聽聽>> allow 2
聽聽聽聽>> > jitsi clients to establish a ZRTP audio call between them.
聽聽聽聽>> > Again, per the wiki here
聽聽聽聽http://wiki.freeswitch.org/wiki/Proxy_Media
聽聽聽聽>> >
聽聽聽聽>> > * Proxy: media flows through FS, no media processing options
聽聽聽聽>> >
聽聽聽聽>> > - RTP proxied by FreeSWITCH (c= modified, that's it)
聽聽聽聽>> > - FreeSWITCH has no control or even understanding of other SDP
聽聽聽聽>> parameters (pass through)
聽聽聽聽>>
聽聽聽聽>> Oh ... this is actually wrong from an RFC perspective but I
聽聽聽聽don't
聽聽聽聽>> think
聽聽聽聽>> it is related to your problems.
聽聽聽聽>>
聽聽聽聽>> > - Endpoints *MUST* agree on same codec because FreeSWITCH can't
聽聽聽聽>> help them
聽聽聽聽>> > - Virtually no features available
聽聽聽聽>>
聽聽聽聽>> By the way, in order to eliminate FreeSWITCH as a factor here and
聽聽聽聽>> confirm that your problems really are in Jitsi, could you please
聽聽聽聽>> create
聽聽聽聽>> a SIP account at http://ippi.com and do your tests there?
聽聽聽聽>>
聽聽聽聽>> (From what we've tried this works so I am inclined to think FS is
聽聽聽聽>> messing up something here ... or at least both Jitsi and FS
聽聽聽聽contribute
聽聽聽聽>> to a global mess, so these tests would help narrow it down).
聽聽聽聽>>
聽聽聽聽>> Cheers,
聽聽聽聽>> Emil
聽聽聽聽>> >
聽聽聽聽>> >
聽聽聽聽>> >
聽聽聽聽>> >
聽聽聽聽>> > On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org> > >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>> > >> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>> wrote:
聽聽聽聽>> >
聽聽聽聽>> > Hey Marc,
聽聽聽聽>> >
聽聽聽聽>> > On Apr 11, 2013 8:21 PM, "Marc Abrams" > <marca56@gmail.com <mailto:marca56@gmail.com> > >> <mailto:marca56@gmail.com <mailto:marca56@gmail.com>> > >> > <mailto:marca56@gmail.com <mailto:marca56@gmail.com> > <mailto:marca56@gmail.com <mailto:marca56@gmail.com>>>> wrote:
聽聽聽聽>> > >
聽聽聽聽>> > > Hi,
聽聽聽聽>> > >
聽聽聽聽>> > > Freeswitch is a proxy as opposed to a B2BUA so should
聽聽聽聽have no
聽聽聽聽>> > issues > routing audio or video. In fact, the the codecs
聽聽聽聽>> chosen are
聽聽聽聽>> > selected by
聽聽聽聽>> > > negotiation between endpoints.
聽聽聽聽>> >
聽聽聽聽>> > Chiming in for a quick comment: I don't have a lot of
聽聽聽聽experience
聽聽聽聽>> > with FS but as far as I know, it is exactly the opposite of
聽聽聽聽>> a proxy
聽聽聽聽>> > and the very definition of a B2BUA. This is one of the
聽聽聽聽>> reasons why
聽聽聽聽>> > Jitsi's Opus support wasn't working there until they
聽聽聽聽>> recently fixed it.
聽聽聽聽>> >
聽聽聽聽>> > Emil
聽聽聽聽>> >
聽聽聽聽>> > --sent from my mobile
聽聽聽聽>> > >
聽聽聽聽>> >
聽聽聽聽>> >
聽聽聽聽>> > > In the case you describe, if you are doing a call from
聽聽聽聽>> Jitsi to
聽聽聽聽>> > another Jitsi client and it works sometimes but not others,
聽聽聽聽>> I don't
聽聽聽聽>> > think the issue is related to Jitsi.
聽聽聽聽>> > >
聽聽聽聽>> > > Is all this on a private network or are the clients going
聽聽聽聽>> through
聽聽聽聽>> > a firewall or NAT? This is the usual cause of SIP issues.
聽聽聽聽>> > >
聽聽聽聽>> > > Thanks.
聽聽聽聽>> > >
聽聽聽聽>> > > marc.
聽聽聽聽>> > > __________________
聽聽聽聽>> > > +1-949-270-0935 <tel:%2B1-949-270-0935>
聽聽聽聽<tel:%2B1-949-270-0935>
聽聽聽聽>> <tel:%2B1-949-270-0935>
聽聽聽聽>> > >
聽聽聽聽>> > >
聽聽聽聽>> > >
聽聽聽聽>> > > On Apr 11, 2013, at 10:13 AM, Privus 007
聽聽聽聽>> <privus007@gmail.com <mailto:privus007@gmail.com>
聽聽聽聽<mailto:privus007@gmail.com <mailto:privus007@gmail.com>>
聽聽聽聽>> > <mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com> <mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>>>>
聽聽聽聽>> wrote:
聽聽聽聽>> > >
聽聽聽聽>> > >> Thanks for your reply.
聽聽聽聽>> > >>
聽聽聽聽>> > >> Hmmm. So it seems it is not just some
聽聽聽聽incompatibility with
聽聽聽聽>> > Freeswitch but rather an incompatibility with SIP in
聽聽聽聽general.
聽聽聽聽>> > >>
聽聽聽聽>> > >> That seems like a pretty serious limitation to
聽聽聽聽jitsi's video
聽聽聽聽>> > capability, no? I've also tried putting VP8 at the top of
聽聽聽聽>> the codec
聽聽聽聽>> > list on both jitsi clients and I still have the same
聽聽聽聽>> problems and
聽聽聽聽>> > inconsistency described above.
聽聽聽聽>> > >>
聽聽聽聽>> > >> Has anyone else had any success (consistently) with
聽聽聽聽jitsi
聽聽聽聽>> video
聽聽聽聽>> > through a SIP server?
聽聽聽聽>> > >>
聽聽聽聽>> > >> Thanks
聽聽聽聽>> > >>
聽聽聽聽>> > >>
聽聽聽聽>> > >> On Wed, Apr 10, 2013 at 8:42 AM,
聽聽聽聽<J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>
聽聽聽聽>> <mailto:J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>>
聽聽聽聽>> > <mailto:J.Witvliet@mindef.nl
聽聽聽聽<mailto:J.Witvliet@mindef.nl> <mailto:J.Witvliet@mindef.nl
聽聽聽聽<mailto:J.Witvliet@mindef.nl>>>>
聽聽聽聽>> wrote:
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> (Sorry 4 topposting, forced upon me by BB)
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> Yes, i've experimenting with sip-video as well, but
聽聽聽聽with
聽聽聽聽>> asterisk.
聽聽聽聽>> > >>> I've seen same behaviour* as you, but mostly (!) It
聽聽聽聽>> boils down,
聽聽聽聽>> > to. Video-codec mismatch between client1/pbx and
聽聽聽聽client2/pbx, or
聽聽聽聽>> > client1/client2.
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> *even difference between client1 calling client2
聽聽聽聽and client2
聽聽聽聽>> > calling client1 :frowning:
聽聽聽聽>> > >>>
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> With xmpp nothing is inbetween, which can be an
聽聽聽聽>> advantage, but
聽聽聽聽>> > also a serious limitation.
聽聽聽聽>> > >>>
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> Van: Privus 007 [mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>
聽聽聽聽>> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>
聽聽聽聽>> > <mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com> <mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>>>]
聽聽聽聽>> > >>> Verzonden: Tuesday, April 09, 2013 07:35 PM W. Europe
聽聽聽聽>> Standard Time
聽聽聽聽>> > >>> Aan: dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
聽聽聽聽>> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>
聽聽聽聽>> > <dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
聽聽聽聽>> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>>
聽聽聽聽>> > >>> Onderwerp: [jitsi-dev] Video Call through SIP
聽聽聽聽>> (Freeswitch) not
聽聽聽聽>> > working
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> Hello,
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> I've been trying to get video working on a basic
聽聽聽聽SIP call
聽聽聽聽>> > between 2 jitsi (latest nightly) clients. One on
聽聽聽聽windows 7, the
聽聽聽聽>> > other on Mint 14. I'm using Freeswitch as the SIP
聽聽聽聽server and
聽聽聽聽>> have
聽聽聽聽>> > enabled the "proxy media" variable in the SIP profile. This
聽聽聽聽>> should
聽聽聽聽>> > theoretically let the 2 jitsi endpoints talk to each other
聽聽聽聽>> directly
聽聽聽聽>> > with little interference from the server.
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> My results aren't good. Basically the video box remains
聽聽聽聽>> greyed
聽聽聽聽>> > out on both sides during the call, and there seems to be no
聽聽聽聽>> video
聽聽聽聽>> > media in the call (although audio works). I've tried
聽聽聽聽playing
聽聽聽聽>> around
聽聽聽聽>> > with VP8 and H264, to no avail. Also, I often have to
聽聽聽聽hangup the
聽聽聽聽>> > first attempt and try again since jitsi seems to hang after
聽聽聽聽>> > "dialing" (and I see in the server that it never receives
聽聽聽聽>> anything
聽聽聽聽>> > from jitsi). On the second try Jitsi is able to reach the
聽聽聽聽>> server as
聽聽聽聽>> > it should, although video still doesn't work.
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> Frustrated with this SIP experiment and Freeswitch, I
聽聽聽聽>> set up an
聽聽聽聽>> > XMPP server (openfire) and tried the same experiment.
聽聽聽聽This time
聽聽聽聽>> > video worked as it should (most of the time, I still get
聽聽聽聽>> > inconsistent results). Even ZRTP worked well in both audio
聽聽聽聽>> and video.
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> Before I start sending logs, etc, I was wondering if
聽聽聽聽>> anyone has
聽聽聽聽>> > been able to use Jitsi's video with SIP, and with
聽聽聽聽Freeswitch in
聽聽聽聽>> > particular.
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> I've also setup the videobridge with openfire and that
聽聽聽聽>> seemed to
聽聽聽聽>> > work well, although I only tested a little bit.
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> Thanks
聽聽聽聽>> > >>> ________________________________
聽聽聽聽>> > >>> Dit bericht kan informatie bevatten die niet voor u is
聽聽聽聽>> bestemd.
聽聽聽聽>> > Indien u niet de geadresseerde bent of dit bericht
聽聽聽聽>> abusievelijk aan
聽聽聽聽>> > u is toegezonden, wordt u verzocht dat aan de afzender te
聽聽聽聽>> melden en
聽聽聽聽>> > het bericht te verwijderen. De Staat aanvaardt geen
聽聽聽聽>> > aansprakelijkheid voor schade, van welke aard ook, die
聽聽聽聽>> verband houdt
聽聽聽聽>> > met risico's verbonden aan het electronisch verzenden van
聽聽聽聽>> berichten.
聽聽聽聽>> > >>>
聽聽聽聽>> > >>> This message may contain information that is not
聽聽聽聽>> intended for
聽聽聽聽>> > you. If you are not the addressee or if this message was
聽聽聽聽>> sent to you
聽聽聽聽>> > by mistake, you are requested to inform the sender and
聽聽聽聽>> delete the
聽聽聽聽>> > message. The State accepts no liability for damage of
聽聽聽聽any kind
聽聽聽聽>> > resulting from the risks inherent in the electronic
聽聽聽聽>> transmission of
聽聽聽聽>> > messages.
聽聽聽聽>> > >>
聽聽聽聽>> > >>
聽聽聽聽>> > >
聽聽聽聽>> >
聽聽聽聽>> >
聽聽聽聽>>
聽聽聽聽>> --
聽聽聽聽>> https://jitsi.org
聽聽聽聽>>
聽聽聽聽>

聽聽聽聽--
聽聽聽聽https://jitsi.org

--
https://jitsi.org


#17

Hi,

I have some good news on this front. Indeed enabling "bypass media" option
in FS's SIP profile has video working rather well, at the same level as I
previously reported with XMPP (using openfire). It still sometimes fails on
first attempt but usually works well on the 2nd. I still have a buggy
experience with desktop sharing, though, with the call being dropped after
intially showing the remote desktop.
Still, this positive experience with "bypass media" clears things up
somewhat regarding FS and SIP. I hope this helps others too.
As per their wiki <http://wiki.freeswitch.org/wiki/Bypass_Media>,

"No media" mode is an SDP Passthrough feature that permits two endpoints
that can see each other (no funky NATs) to connect their media sessions
directly while FreeSWITCH maintains control of the SIP signaling. This is
useful if you have two end-points that need to use a codec that is
currently not supported in FreeSWITCH (video) or if you are using
FreeSWITCH in a high performance walled garden network and want to minimize
the RTP handling FreeSWITCH is doing to maximize call traffic.

When set, the media (RTP) from the originating endpoint is sent directly to
the destination endpoint and vice versa. The signaling (SIP) for both
endpoints still goes through FreeSWITCH, but the media is point-to-point."

路路路

+------------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> >
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽____| FreeSWITCH |___
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ | | \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽SIP / +------------+ \ SIP
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ 192.168.1.105 \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽+----------+ +----------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> > > >
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> endpoint | <---- RTP ----> | endpoint |
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> A | Audio | B |
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽+----------+ +----------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽192.168.1.100 192.168.1.110

Indeed in my testing environment I have both jitsi clients on a local LAN
and FS on a remote server on the internet, and video seems to work fairly
well. This leads me to believe that indeed there is a need for an ICE
implementation in jitsi for video to work across the internet, as in most
cases both clients will not be sitting behind the same LAN. The difference
between "proxy media" and "bypass media" modes in FS seems to be that RTP
is not touched by FS at all in bypass media mode which enables both jitsi
endpoints to directly exchange RTP streams.

Like I said, this is great for clients behind the same LAN but likely
unworkable in most other scenarios.
I really hope to see jitsi incorporate ICE sooner rather than later.

By the way, besides FS and Asterisk, has anyone had good experience with
Kamailio and video?

Cheers

On Fri, Apr 19, 2013 at 10:29 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey there,

On 19.04.13, 23:03, Privus 007 wrote:
> Hi,
>
> Well I just finished testing with 2 ippi accounts and today's nightly
> build on a windows 7 machine and a mint 14 laptop.
> Indeed the video worked rather well

OK, that's good to hear!

> (sometimes I had to hangup and try
> again but on the 2nd try it always worked). Now desktop sharing seems
> still a little buggy since when I tried remote control both times the
> call was dropped.

OK, sorry to come up with excuses all the time but this really is their
fault :). We send desktop control messages through signalling and
sometimes the server gets confused and starts sending back error
responses. (Which is why we are thinking of launching a proof-of-concept
SIP service on jit.si, similar to the XMPP one we already have there).

> Still, this test does seem to point the "blame" to FS (or, more likely,
> something I've misconfigured) since I can never get video working with
> FS (and audio doesn't work with the nightly, only with 2.0 stable and
> with my csipsimple and groundwire clients).

Maybe that has something to do with Opus. I know they had an issue with
it that was fixed in trunk at some point, but I am not sure if that
particular revision has already made it into a release.

> I'm not sure what the issue is with FS, but tomorrow I'll do some more
> testing and try, for example, to enable "bypass media" in the FS profile
> to see if that helps. I'm not sure where the problem lies, but I'll keep
> reporting on my progress since it is such a shame that FS seems to have
> issues with jitsi.

Thanks!

> P.S. I just realised that jitsi doesn't have any STUN or ICE options
> with the SIP transport (or am I blind?), only with XMPP.

You are not blind! :slight_smile: We do only have ICE for XMPP currently. SIP should
follow soon (we'd need that for WebRTC interop) but I can't give you an
ETA. Hopefully we'd have it this summer.

> Perhaps that's
> why I can get video working when using the openfire server located on
> the same machine as FS? Maybe it is a NAT issue with SIP after all? Just
> a thought.

Mmmm ... I didn't get what the relationship with Openfire. If you have
Openfire (and as long as you have jingle nodes enabled) then you should
be using ICE to pick a route.

With SIP we rely on Hosted NAT Traversal (and latching) which most SIP
services provide.

Again, we are also thinking of doing ICE with SIP but that's not there yet.

Cheers,
Emil

>
>
> On Fri, Apr 19, 2013 at 7:32 PM, Emil Ivov <emcho@jitsi.org > > <mailto:emcho@jitsi.org>> wrote:
>
>
>
> On 19.04.13, 19:15, tomp@tomp.co.uk <mailto:tomp@tomp.co.uk> wrote:
> > I find that if you disable the video and re-enable during a call it
> > seems to allow 2 parallel video streams to work.
>
> Interesting. Can you also give it a try on ippi.com
> <http://ippi.com> and let us know how
> it goes there?
>
> > The issue seems to be related to multiple video streams, any usage
> that
> > only requires a single video stream (for example the echo test, or
a
> > single party-speaking conference) works fine.
> >
> >
> >
> > But if you try and see the video from multiple parties at once it
> starts
> > to fail.
>
> Hmm this sounds like it might be FS's fault. We've never tested
multiple
> video recipients with FS but when you do this you have to make sure
> every new receiver gets a key frame or otherwise they won't be able
to
> decode the stream. Jitsi does send AVPF PLI requests over RTCP but FS
> has to relay those.
>
> Is your environment available for a test from the Internet?
>
> Emil
>
>
> >
> > On 2013-04-19 17:59, Privus 007 wrote:
> >
> >> Hi
> >>
> >> >By the way, in order to eliminate FreeSWITCH as a factor here and
> >> >confirm that your problems really are in Jitsi, could you please
> create
> >> >a SIP account at http://ippi.com and do your tests there?
> >>
> >> Will get around to it this weekend and I'll let you know the
results.
> >>
> >> Thanks
> >>
> >>
> >> On Fri, Apr 19, 2013 at 5:56 PM, Emil Ivov <emcho@jitsi.org > > <mailto:emcho@jitsi.org> > > >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
> >>
> >> Hey there,
> >>
> >> On 19.04.13, 18:46, Privus 007 wrote:
> >> > Correct, From their wiki here
> >> >
http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch
> >> >
> >> > "FreeSWITCH is a B2BUA (back-to-back user agent). This
> means that it
> >> > actually parses each of the SIP messages it receives.
> FreeSWITCH
> >> can not
> >> > act as a proxy, for instance by forwarding SIP
> registrations to a
> >> > registrar server."
> >>
> >> OK, thanks for the pointer.
> >> >
> >> > However, I have configured FS in proxy media mode in order
to
> >> allow 2
> >> > jitsi clients to establish a ZRTP audio call between them.
> >> > Again, per the wiki here
> http://wiki.freeswitch.org/wiki/Proxy_Media
> >> >
> >> > * Proxy: media flows through FS, no media processing
options
> >> >
> >> > - RTP proxied by FreeSWITCH (c= modified, that's it)
> >> > - FreeSWITCH has no control or even understanding of other
SDP
> >> parameters (pass through)
> >>
> >> Oh ... this is actually wrong from an RFC perspective but I
> don't
> >> think
> >> it is related to your problems.
> >>
> >> > - Endpoints *MUST* agree on same codec because FreeSWITCH
can't
> >> help them
> >> > - Virtually no features available
> >>
> >> By the way, in order to eliminate FreeSWITCH as a factor here
and
> >> confirm that your problems really are in Jitsi, could you
please
> >> create
> >> a SIP account at http://ippi.com and do your tests there?
> >>
> >> (From what we've tried this works so I am inclined to think
FS is
> >> messing up something here ... or at least both Jitsi and FS
> contribute
> >> to a global mess, so these tests would help narrow it down).
> >>
> >> Cheers,
> >> Emil
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov <emcho@jitsi.org > > <mailto:emcho@jitsi.org> > > >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>> > > >> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org> > > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>> wrote:
> >> >
> >> > Hey Marc,
> >> >
> >> > On Apr 11, 2013 8:21 PM, "Marc Abrams" > > <marca56@gmail.com <mailto:marca56@gmail.com> > > >> <mailto:marca56@gmail.com <mailto:marca56@gmail.com>> > > >> > <mailto:marca56@gmail.com <mailto:marca56@gmail.com> > > <mailto:marca56@gmail.com <mailto:marca56@gmail.com>>>> wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > Freeswitch is a proxy as opposed to a B2BUA so should
> have no
> >> > issues > routing audio or video. In fact, the the codecs
> >> chosen are
> >> > selected by
> >> > > negotiation between endpoints.
> >> >
> >> > Chiming in for a quick comment: I don't have a lot of
> experience
> >> > with FS but as far as I know, it is exactly the
opposite of
> >> a proxy
> >> > and the very definition of a B2BUA. This is one of the
> >> reasons why
> >> > Jitsi's Opus support wasn't working there until they
> >> recently fixed it.
> >> >
> >> > Emil
> >> >
> >> > --sent from my mobile
> >> > >
> >> >
> >> >
> >> > > In the case you describe, if you are doing a call from
> >> Jitsi to
> >> > another Jitsi client and it works sometimes but not
others,
> >> I don't
> >> > think the issue is related to Jitsi.
> >> > >
> >> > > Is all this on a private network or are the clients
going
> >> through
> >> > a firewall or NAT? This is the usual cause of SIP
issues.
> >> > >
> >> > > Thanks.
> >> > >
> >> > > marc.
> >> > > __________________
> >> > > +1-949-270-0935 <tel:%2B1-949-270-0935>
> <tel:%2B1-949-270-0935>
> >> <tel:%2B1-949-270-0935>
> >> > >
> >> > >
> >> > >
> >> > > On Apr 11, 2013, at 10:13 AM, Privus 007
> >> <privus007@gmail.com <mailto:privus007@gmail.com>
> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>
> >> > <mailto:privus007@gmail.com
> <mailto:privus007@gmail.com> <mailto:privus007@gmail.com
> <mailto:privus007@gmail.com>>>>
> >> wrote:
> >> > >
> >> > >> Thanks for your reply.
> >> > >>
> >> > >> Hmmm. So it seems it is not just some
> incompatibility with
> >> > Freeswitch but rather an incompatibility with SIP in
> general.
> >> > >>
> >> > >> That seems like a pretty serious limitation to
> jitsi's video
> >> > capability, no? I've also tried putting VP8 at the top
of
> >> the codec
> >> > list on both jitsi clients and I still have the same
> >> problems and
> >> > inconsistency described above.
> >> > >>
> >> > >> Has anyone else had any success (consistently) with
> jitsi
> >> video
> >> > through a SIP server?
> >> > >>
> >> > >> Thanks
> >> > >>
> >> > >>
> >> > >> On Wed, Apr 10, 2013 at 8:42 AM,
> <J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>
> >> <mailto:J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>>
> >> > <mailto:J.Witvliet@mindef.nl
> <mailto:J.Witvliet@mindef.nl> <mailto:J.Witvliet@mindef.nl
> <mailto:J.Witvliet@mindef.nl>>>>
> >> wrote:
> >> > >>>
> >> > >>> (Sorry 4 topposting, forced upon me by BB)
> >> > >>>
> >> > >>> Yes, i've experimenting with sip-video as well, but
> with
> >> asterisk.
> >> > >>> I've seen same behaviour* as you, but mostly (!) It
> >> boils down,
> >> > to. Video-codec mismatch between client1/pbx and
> client2/pbx, or
> >> > client1/client2.
> >> > >>>
> >> > >>> *even difference between client1 calling client2
> and client2
> >> > calling client1 :frowning:
> >> > >>>
> >> > >>>
> >> > >>> With xmpp nothing is inbetween, which can be an
> >> advantage, but
> >> > also a serious limitation.
> >> > >>>
> >> > >>>
> >> > >>> Van: Privus 007 [mailto:privus007@gmail.com
> <mailto:privus007@gmail.com>
> >> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>
> >> > <mailto:privus007@gmail.com
> <mailto:privus007@gmail.com> <mailto:privus007@gmail.com
> <mailto:privus007@gmail.com>>>]
> >> > >>> Verzonden: Tuesday, April 09, 2013 07:35 PM W.
Europe
> >> Standard Time
> >> > >>> Aan: dev@jitsi.java.net <mailto:dev@jitsi.java.net>
> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
> >> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>
> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>
> >> > <dev@jitsi.java.net <mailto:dev@jitsi.java.net>
> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
> >> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>
> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>>
> >> > >>> Onderwerp: [jitsi-dev] Video Call through SIP
> >> (Freeswitch) not
> >> > working
> >> > >>>
> >> > >>> Hello,
> >> > >>>
> >> > >>> I've been trying to get video working on a basic
> SIP call
> >> > between 2 jitsi (latest nightly) clients. One on
> windows 7, the
> >> > other on Mint 14. I'm using Freeswitch as the SIP
> server and
> >> have
> >> > enabled the "proxy media" variable in the SIP profile.
This
> >> should
> >> > theoretically let the 2 jitsi endpoints talk to each
other
> >> directly
> >> > with little interference from the server.
> >> > >>>
> >> > >>> My results aren't good. Basically the video box
remains
> >> greyed
> >> > out on both sides during the call, and there seems to
be no
> >> video
> >> > media in the call (although audio works). I've tried
> playing
> >> around
> >> > with VP8 and H264, to no avail. Also, I often have to
> hangup the
> >> > first attempt and try again since jitsi seems to hang
after
> >> > "dialing" (and I see in the server that it never
receives
> >> anything
> >> > from jitsi). On the second try Jitsi is able to reach
the
> >> server as
> >> > it should, although video still doesn't work.
> >> > >>>
> >> > >>> Frustrated with this SIP experiment and Freeswitch,
I
> >> set up an
> >> > XMPP server (openfire) and tried the same experiment.
> This time
> >> > video worked as it should (most of the time, I still get
> >> > inconsistent results). Even ZRTP worked well in both
audio
> >> and video.
> >> > >>>
> >> > >>> Before I start sending logs, etc, I was wondering if
> >> anyone has
> >> > been able to use Jitsi's video with SIP, and with
> Freeswitch in
> >> > particular.
> >> > >>>
> >> > >>> I've also setup the videobridge with openfire and
that
> >> seemed to
> >> > work well, although I only tested a little bit.
> >> > >>>
> >> > >>> Thanks
> >> > >>> ________________________________
> >> > >>> Dit bericht kan informatie bevatten die niet voor u
is
> >> bestemd.
> >> > Indien u niet de geadresseerde bent of dit bericht
> >> abusievelijk aan
> >> > u is toegezonden, wordt u verzocht dat aan de afzender
te
> >> melden en
> >> > het bericht te verwijderen. De Staat aanvaardt geen
> >> > aansprakelijkheid voor schade, van welke aard ook, die
> >> verband houdt
> >> > met risico's verbonden aan het electronisch verzenden
van
> >> berichten.
> >> > >>>
> >> > >>> This message may contain information that is not
> >> intended for
> >> > you. If you are not the addressee or if this message was
> >> sent to you
> >> > by mistake, you are requested to inform the sender and
> >> delete the
> >> > message. The State accepts no liability for damage of
> any kind
> >> > resulting from the risks inherent in the electronic
> >> transmission of
> >> > messages.
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >> --
> >> https://jitsi.org
> >>
> >
>
> --
> https://jitsi.org
>
>

--
https://jitsi.org


#18

Hi,

Thats interesting, thanks for doing the research.

Its strange though, as Freeswitch does support H264 codec in pass through mode:

http://wiki.freeswitch.org/wiki/Codecs#Pass-through_video_codecs

Meaning that it doesn't try and convert the media (like it can with audio streams).

And I can get it to work sometimes.

I might open up a ticket on the Freeswitch bug list and see if they can shed some light on this.

Thanks
Tom

路路路

On 20/04/13 15:22, Privus 007 wrote:

Hi,

I have some good news on this front. Indeed enabling "bypass media" option in FS's SIP profile has video working rather well, at the same level as I previously reported with XMPP (using openfire). It still sometimes fails on first attempt but usually works well on the 2nd. I still have a buggy experience with desktop sharing, though, with the call being dropped after intially showing the remote desktop.
Still, this positive experience with "bypass media" clears things up somewhat regarding FS and SIP. I hope this helps others too.
As per their wiki <http://wiki.freeswitch.org/wiki/Bypass_Media>,

"No media" mode is an SDP Passthrough feature that permits two endpoints that can see each other (no funky NATs) to connect their media sessions directly while FreeSWITCH maintains control of the SIP signaling. This is useful if you have two end-points that need to use a codec that is currently not supported in FreeSWITCH (video) or if you are using FreeSWITCH in a high performance walled garden network and want to minimize the RTP handling FreeSWITCH is doing to maximize call traffic.

When set, the media (RTP) from the originating endpoint is sent directly to the destination endpoint and vice versa. The signaling (SIP) for both endpoints still goes through FreeSWITCH, but the media is point-to-point."

聽聽+------------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> >
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽____| FreeSWITCH |___
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ | | \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽SIP / +------------+ \ SIP
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ 192.168.1.105 \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽+----------+ +----------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> > > >
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> endpoint | <---- RTP ----> | endpoint |
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> A | Audio | B |
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽+----------+ +----------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽192.168.1.100 192.168.1.110

Indeed in my testing environment I have both jitsi clients on a local LAN and FS on a remote server on the internet, and video seems to work fairly well. This leads me to believe that indeed there is a need for an ICE implementation in jitsi for video to work across the internet, as in most cases both clients will not be sitting behind the same LAN. The difference between "proxy media" and "bypass media" modes in FS seems to be that RTP is not touched by FS at all in bypass media mode which enables both jitsi endpoints to directly exchange RTP streams.

Like I said, this is great for clients behind the same LAN but likely unworkable in most other scenarios.
I really hope to see jitsi incorporate ICE sooner rather than later.

By the way, besides FS and Asterisk, has anyone had good experience with Kamailio and video?

Cheers

On Fri, Apr 19, 2013 at 10:29 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

聽聽聽聽Hey there,

聽聽聽聽On 19.04.13, 23:03, Privus 007 wrote:
聽聽聽聽> Hi,
聽聽聽聽>
聽聽聽聽> Well I just finished testing with 2 ippi accounts and today's
聽聽聽聽nightly
聽聽聽聽> build on a windows 7 machine and a mint 14 laptop.
聽聽聽聽> Indeed the video worked rather well

聽聽聽聽OK, that's good to hear!

聽聽聽聽> (sometimes I had to hangup and try
聽聽聽聽> again but on the 2nd try it always worked). Now desktop sharing
聽聽聽聽seems
聽聽聽聽> still a little buggy since when I tried remote control both
聽聽聽聽times the
聽聽聽聽> call was dropped.

聽聽聽聽OK, sorry to come up with excuses all the time but this really is
聽聽聽聽their
聽聽聽聽fault :). We send desktop control messages through signalling and
聽聽聽聽sometimes the server gets confused and starts sending back error
聽聽聽聽responses. (Which is why we are thinking of launching a
聽聽聽聽proof-of-concept
聽聽聽聽SIP service on jit.si <http://jit.si>, similar to the XMPP one we
聽聽聽聽already have there).

聽聽聽聽> Still, this test does seem to point the "blame" to FS (or, more
聽聽聽聽likely,
聽聽聽聽> something I've misconfigured) since I can never get video
聽聽聽聽working with
聽聽聽聽> FS (and audio doesn't work with the nightly, only with 2.0
聽聽聽聽stable and
聽聽聽聽> with my csipsimple and groundwire clients).

聽聽聽聽Maybe that has something to do with Opus. I know they had an issue
聽聽聽聽with
聽聽聽聽it that was fixed in trunk at some point, but I am not sure if that
聽聽聽聽particular revision has already made it into a release.

聽聽聽聽> I'm not sure what the issue is with FS, but tomorrow I'll do
聽聽聽聽some more
聽聽聽聽> testing and try, for example, to enable "bypass media" in the FS
聽聽聽聽profile
聽聽聽聽> to see if that helps. I'm not sure where the problem lies, but
聽聽聽聽I'll keep
聽聽聽聽> reporting on my progress since it is such a shame that FS seems
聽聽聽聽to have
聽聽聽聽> issues with jitsi.

聽聽聽聽Thanks!

聽聽聽聽> P.S. I just realised that jitsi doesn't have any STUN or ICE options
聽聽聽聽> with the SIP transport (or am I blind?), only with XMPP.

聽聽聽聽You are not blind! :slight_smile: We do only have ICE for XMPP currently. SIP
聽聽聽聽should
聽聽聽聽follow soon (we'd need that for WebRTC interop) but I can't give
聽聽聽聽you an
聽聽聽聽ETA. Hopefully we'd have it this summer.

聽聽聽聽> Perhaps that's
聽聽聽聽> why I can get video working when using the openfire server
聽聽聽聽located on
聽聽聽聽> the same machine as FS? Maybe it is a NAT issue with SIP after
聽聽聽聽all? Just
聽聽聽聽> a thought.

聽聽聽聽Mmmm ... I didn't get what the relationship with Openfire. If you have
聽聽聽聽Openfire (and as long as you have jingle nodes enabled) then you
聽聽聽聽should
聽聽聽聽be using ICE to pick a route.

聽聽聽聽With SIP we rely on Hosted NAT Traversal (and latching) which most SIP
聽聽聽聽services provide.

聽聽聽聽Again, we are also thinking of doing ICE with SIP but that's not
聽聽聽聽there yet.

聽聽聽聽Cheers,
聽聽聽聽Emil

聽聽聽聽>
聽聽聽聽> On Fri, Apr 19, 2013 at 7:32 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org> > > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
聽聽聽聽>
聽聽聽聽> On 19.04.13, 19:15, tomp@tomp.co.uk <mailto:tomp@tomp.co.uk> > <mailto:tomp@tomp.co.uk <mailto:tomp@tomp.co.uk>> wrote:
聽聽聽聽> > I find that if you disable the video and re-enable during
聽聽聽聽a call it
聽聽聽聽> > seems to allow 2 parallel video streams to work.
聽聽聽聽>
聽聽聽聽> Interesting. Can you also give it a try on ippi.com
聽聽聽聽<http://ippi.com>
聽聽聽聽> <http://ippi.com> and let us know how
聽聽聽聽> it goes there?
聽聽聽聽>
聽聽聽聽> > The issue seems to be related to multiple video streams,
聽聽聽聽any usage
聽聽聽聽> that
聽聽聽聽> > only requires a single video stream (for example the echo
聽聽聽聽test, or a
聽聽聽聽> > single party-speaking conference) works fine.
聽聽聽聽> >
聽聽聽聽> > But if you try and see the video from multiple parties at
聽聽聽聽once it
聽聽聽聽> starts
聽聽聽聽> > to fail.
聽聽聽聽>
聽聽聽聽> Hmm this sounds like it might be FS's fault. We've never
聽聽聽聽tested multiple
聽聽聽聽> video recipients with FS but when you do this you have to
聽聽聽聽make sure
聽聽聽聽> every new receiver gets a key frame or otherwise they won't
聽聽聽聽be able to
聽聽聽聽> decode the stream. Jitsi does send AVPF PLI requests over
聽聽聽聽RTCP but FS
聽聽聽聽> has to relay those.
聽聽聽聽>
聽聽聽聽> Is your environment available for a test from the Internet?
聽聽聽聽>
聽聽聽聽> Emil
聽聽聽聽>
聽聽聽聽> >
聽聽聽聽> > On 2013-04-19 17:59, Privus 007 wrote:
聽聽聽聽> >
聽聽聽聽> >> Hi
聽聽聽聽> >>
聽聽聽聽> >> >By the way, in order to eliminate FreeSWITCH as a factor
聽聽聽聽here and
聽聽聽聽> >> >confirm that your problems really are in Jitsi, could
聽聽聽聽you please
聽聽聽聽> create
聽聽聽聽> >> >a SIP account at http://ippi.com and do your tests there?
聽聽聽聽> >>
聽聽聽聽> >> Will get around to it this weekend and I'll let you know
聽聽聽聽the results.
聽聽聽聽> >>
聽聽聽聽> >> Thanks
聽聽聽聽> >>
聽聽聽聽> >> On Fri, Apr 19, 2013 at 5:56 PM, Emil Ivov > <emcho@jitsi.org <mailto:emcho@jitsi.org> > > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>> > > >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>> wrote:
聽聽聽聽> >>
聽聽聽聽> >> Hey there,
聽聽聽聽> >>
聽聽聽聽> >> On 19.04.13, 18:46, Privus 007 wrote:
聽聽聽聽> >> > Correct, From their wiki here
聽聽聽聽> >> >
聽聽聽聽http://wiki.freeswitch.org/wiki/The_Limitations_of_FreeSwitch
聽聽聽聽> >> >
聽聽聽聽> >> > "FreeSWITCH is a B2BUA (back-to-back user agent). This
聽聽聽聽> means that it
聽聽聽聽> >> > actually parses each of the SIP messages it receives.
聽聽聽聽> FreeSWITCH
聽聽聽聽> >> can not
聽聽聽聽> >> > act as a proxy, for instance by forwarding SIP
聽聽聽聽> registrations to a
聽聽聽聽> >> > registrar server."
聽聽聽聽> >>
聽聽聽聽> >> OK, thanks for the pointer.
聽聽聽聽> >> >
聽聽聽聽> >> > However, I have configured FS in proxy media mode
聽聽聽聽in order to
聽聽聽聽> >> allow 2
聽聽聽聽> >> > jitsi clients to establish a ZRTP audio call
聽聽聽聽between them.
聽聽聽聽> >> > Again, per the wiki here
聽聽聽聽> http://wiki.freeswitch.org/wiki/Proxy_Media
聽聽聽聽> >> >
聽聽聽聽> >> > * Proxy: media flows through FS, no media
聽聽聽聽processing options
聽聽聽聽> >> >
聽聽聽聽> >> > - RTP proxied by FreeSWITCH (c= modified, that's it)
聽聽聽聽> >> > - FreeSWITCH has no control or even understanding
聽聽聽聽of other SDP
聽聽聽聽> >> parameters (pass through)
聽聽聽聽> >>
聽聽聽聽> >> Oh ... this is actually wrong from an RFC
聽聽聽聽perspective but I
聽聽聽聽> don't
聽聽聽聽> >> think
聽聽聽聽> >> it is related to your problems.
聽聽聽聽> >>
聽聽聽聽> >> > - Endpoints *MUST* agree on same codec because
聽聽聽聽FreeSWITCH can't
聽聽聽聽> >> help them
聽聽聽聽> >> > - Virtually no features available
聽聽聽聽> >>
聽聽聽聽> >> By the way, in order to eliminate FreeSWITCH as a
聽聽聽聽factor here and
聽聽聽聽> >> confirm that your problems really are in Jitsi, could
聽聽聽聽you please
聽聽聽聽> >> create
聽聽聽聽> >> a SIP account at http://ippi.com and do your tests there?
聽聽聽聽> >>
聽聽聽聽> >> (From what we've tried this works so I am inclined to
聽聽聽聽think FS is
聽聽聽聽> >> messing up something here ... or at least both Jitsi
聽聽聽聽and FS
聽聽聽聽> contribute
聽聽聽聽> >> to a global mess, so these tests would help narrow it
聽聽聽聽down).
聽聽聽聽> >>
聽聽聽聽> >> Cheers,
聽聽聽聽> >> Emil
聽聽聽聽> >> >
聽聽聽聽> >> > On Thu, Apr 18, 2013 at 6:02 PM, Emil Ivov
聽聽聽聽<emcho@jitsi.org <mailto:emcho@jitsi.org>
聽聽聽聽> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>
聽聽聽聽> >> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>
聽聽聽聽<mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>
聽聽聽聽> >> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>
聽聽聽聽<mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>
聽聽聽聽> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>
聽聽聽聽<mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>>> wrote:
聽聽聽聽> >> >
聽聽聽聽> >> > Hey Marc,
聽聽聽聽> >> >
聽聽聽聽> >> > On Apr 11, 2013 8:21 PM, "Marc Abrams"
聽聽聽聽> <marca56@gmail.com <mailto:marca56@gmail.com>
聽聽聽聽<mailto:marca56@gmail.com <mailto:marca56@gmail.com>>
聽聽聽聽> >> <mailto:marca56@gmail.com <mailto:marca56@gmail.com>
聽聽聽聽<mailto:marca56@gmail.com <mailto:marca56@gmail.com>>>
聽聽聽聽> >> > <mailto:marca56@gmail.com
聽聽聽聽<mailto:marca56@gmail.com> <mailto:marca56@gmail.com
聽聽聽聽<mailto:marca56@gmail.com>>
聽聽聽聽> <mailto:marca56@gmail.com <mailto:marca56@gmail.com>
聽聽聽聽<mailto:marca56@gmail.com <mailto:marca56@gmail.com>>>>> wrote:
聽聽聽聽> >> > >
聽聽聽聽> >> > > Hi,
聽聽聽聽> >> > >
聽聽聽聽> >> > > Freeswitch is a proxy as opposed to a B2BUA
聽聽聽聽so should
聽聽聽聽> have no
聽聽聽聽> >> > issues > routing audio or video. In fact, the
聽聽聽聽the codecs
聽聽聽聽> >> chosen are
聽聽聽聽> >> > selected by
聽聽聽聽> >> > > negotiation between endpoints.
聽聽聽聽> >> >
聽聽聽聽> >> > Chiming in for a quick comment: I don't have a
聽聽聽聽lot of
聽聽聽聽> experience
聽聽聽聽> >> > with FS but as far as I know, it is exactly the
聽聽聽聽opposite of
聽聽聽聽> >> a proxy
聽聽聽聽> >> > and the very definition of a B2BUA. This is one
聽聽聽聽of the
聽聽聽聽> >> reasons why
聽聽聽聽> >> > Jitsi's Opus support wasn't working there until
聽聽聽聽they
聽聽聽聽> >> recently fixed it.
聽聽聽聽> >> >
聽聽聽聽> >> > Emil
聽聽聽聽> >> >
聽聽聽聽> >> > --sent from my mobile
聽聽聽聽> >> > >
聽聽聽聽> >> >
聽聽聽聽> >> > > In the case you describe, if you are doing a
聽聽聽聽call from
聽聽聽聽> >> Jitsi to
聽聽聽聽> >> > another Jitsi client and it works sometimes but
聽聽聽聽not others,
聽聽聽聽> >> I don't
聽聽聽聽> >> > think the issue is related to Jitsi.
聽聽聽聽> >> > >
聽聽聽聽> >> > > Is all this on a private network or are the
聽聽聽聽clients going
聽聽聽聽> >> through
聽聽聽聽> >> > a firewall or NAT? This is the usual cause of
聽聽聽聽SIP issues.
聽聽聽聽> >> > >
聽聽聽聽> >> > > Thanks.
聽聽聽聽> >> > >
聽聽聽聽> >> > > marc.
聽聽聽聽> >> > > __________________
聽聽聽聽> >> > > +1-949-270-0935 <tel:%2B1-949-270-0935>
聽聽聽聽<tel:%2B1-949-270-0935>
聽聽聽聽> <tel:%2B1-949-270-0935>
聽聽聽聽> >> <tel:%2B1-949-270-0935>
聽聽聽聽> >> > >
聽聽聽聽> >> > > On Apr 11, 2013, at 10:13 AM, Privus 007
聽聽聽聽> >> <privus007@gmail.com <mailto:privus007@gmail.com>
聽聽聽聽<mailto:privus007@gmail.com <mailto:privus007@gmail.com>>
聽聽聽聽> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>
聽聽聽聽<mailto:privus007@gmail.com <mailto:privus007@gmail.com>>>
聽聽聽聽> >> > <mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>
聽聽聽聽> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>
聽聽聽聽<mailto:privus007@gmail.com <mailto:privus007@gmail.com>
聽聽聽聽> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>>>>
聽聽聽聽> >> wrote:
聽聽聽聽> >> > >
聽聽聽聽> >> > >> Thanks for your reply.
聽聽聽聽> >> > >>
聽聽聽聽> >> > >> Hmmm. So it seems it is not just some
聽聽聽聽> incompatibility with
聽聽聽聽> >> > Freeswitch but rather an incompatibility with
聽聽聽聽SIP in
聽聽聽聽> general.
聽聽聽聽> >> > >>
聽聽聽聽> >> > >> That seems like a pretty serious limitation to
聽聽聽聽> jitsi's video
聽聽聽聽> >> > capability, no? I've also tried putting VP8 at
聽聽聽聽the top of
聽聽聽聽> >> the codec
聽聽聽聽> >> > list on both jitsi clients and I still have the
聽聽聽聽same
聽聽聽聽> >> problems and
聽聽聽聽> >> > inconsistency described above.
聽聽聽聽> >> > >>
聽聽聽聽> >> > >> Has anyone else had any success
聽聽聽聽(consistently) with
聽聽聽聽> jitsi
聽聽聽聽> >> video
聽聽聽聽> >> > through a SIP server?
聽聽聽聽> >> > >>
聽聽聽聽> >> > >> Thanks
聽聽聽聽> >> > >>
聽聽聽聽> >> > >> On Wed, Apr 10, 2013 at 8:42 AM,
聽聽聽聽> <J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>
聽聽聽聽<mailto:J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>>
聽聽聽聽> >> <mailto:J.Witvliet@mindef.nl
聽聽聽聽<mailto:J.Witvliet@mindef.nl> <mailto:J.Witvliet@mindef.nl
聽聽聽聽<mailto:J.Witvliet@mindef.nl>>>
聽聽聽聽> >> > <mailto:J.Witvliet@mindef.nl
聽聽聽聽<mailto:J.Witvliet@mindef.nl>
聽聽聽聽> <mailto:J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>>
聽聽聽聽<mailto:J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>
聽聽聽聽> <mailto:J.Witvliet@mindef.nl <mailto:J.Witvliet@mindef.nl>>>>>
聽聽聽聽> >> wrote:
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> (Sorry 4 topposting, forced upon me by BB)
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> Yes, i've experimenting with sip-video as
聽聽聽聽well, but
聽聽聽聽> with
聽聽聽聽> >> asterisk.
聽聽聽聽> >> > >>> I've seen same behaviour* as you, but
聽聽聽聽mostly (!) It
聽聽聽聽> >> boils down,
聽聽聽聽> >> > to. Video-codec mismatch between client1/pbx and
聽聽聽聽> client2/pbx, or
聽聽聽聽> >> > client1/client2.
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> *even difference between client1 calling
聽聽聽聽client2
聽聽聽聽> and client2
聽聽聽聽> >> > calling client1 :frowning:
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> With xmpp nothing is inbetween, which can be an
聽聽聽聽> >> advantage, but
聽聽聽聽> >> > also a serious limitation.
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> Van: Privus 007 [mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>
聽聽聽聽> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>
聽聽聽聽> >> <mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com> <mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>>>
聽聽聽聽> >> > <mailto:privus007@gmail.com
聽聽聽聽<mailto:privus007@gmail.com>
聽聽聽聽> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>
聽聽聽聽<mailto:privus007@gmail.com <mailto:privus007@gmail.com>
聽聽聽聽> <mailto:privus007@gmail.com <mailto:privus007@gmail.com>>>>]
聽聽聽聽> >> > >>> Verzonden: Tuesday, April 09, 2013 07:35 PM
聽聽聽聽W. Europe
聽聽聽聽> >> Standard Time
聽聽聽聽> >> > >>> Aan: dev@jitsi.java.net
聽聽聽聽<mailto:dev@jitsi.java.net> <mailto:dev@jitsi.java.net
聽聽聽聽<mailto:dev@jitsi.java.net>>
聽聽聽聽> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>
聽聽聽聽> >> <mailto:dev@jitsi.java.net
聽聽聽聽<mailto:dev@jitsi.java.net> <mailto:dev@jitsi.java.net
聽聽聽聽<mailto:dev@jitsi.java.net>>
聽聽聽聽> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>>
聽聽聽聽> >> > <dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
聽聽聽聽> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>
聽聽聽聽> >> <mailto:dev@jitsi.java.net
聽聽聽聽<mailto:dev@jitsi.java.net> <mailto:dev@jitsi.java.net
聽聽聽聽<mailto:dev@jitsi.java.net>>
聽聽聽聽> <mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>
聽聽聽聽<mailto:dev@jitsi.java.net <mailto:dev@jitsi.java.net>>>>>
聽聽聽聽> >> > >>> Onderwerp: [jitsi-dev] Video Call through SIP
聽聽聽聽> >> (Freeswitch) not
聽聽聽聽> >> > working
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> Hello,
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> I've been trying to get video working on a
聽聽聽聽basic
聽聽聽聽> SIP call
聽聽聽聽> >> > between 2 jitsi (latest nightly) clients. One on
聽聽聽聽> windows 7, the
聽聽聽聽> >> > other on Mint 14. I'm using Freeswitch as the SIP
聽聽聽聽> server and
聽聽聽聽> >> have
聽聽聽聽> >> > enabled the "proxy media" variable in the SIP
聽聽聽聽profile. This
聽聽聽聽> >> should
聽聽聽聽> >> > theoretically let the 2 jitsi endpoints talk to
聽聽聽聽each other
聽聽聽聽> >> directly
聽聽聽聽> >> > with little interference from the server.
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> My results aren't good. Basically the video
聽聽聽聽box remains
聽聽聽聽> >> greyed
聽聽聽聽> >> > out on both sides during the call, and there
聽聽聽聽seems to be no
聽聽聽聽> >> video
聽聽聽聽> >> > media in the call (although audio works). I've
聽聽聽聽tried
聽聽聽聽> playing
聽聽聽聽> >> around
聽聽聽聽> >> > with VP8 and H264, to no avail. Also, I often
聽聽聽聽have to
聽聽聽聽> hangup the
聽聽聽聽> >> > first attempt and try again since jitsi seems
聽聽聽聽to hang after
聽聽聽聽> >> > "dialing" (and I see in the server that it
聽聽聽聽never receives
聽聽聽聽> >> anything
聽聽聽聽> >> > from jitsi). On the second try Jitsi is able to
聽聽聽聽reach the
聽聽聽聽> >> server as
聽聽聽聽> >> > it should, although video still doesn't work.
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> Frustrated with this SIP experiment and
聽聽聽聽Freeswitch, I
聽聽聽聽> >> set up an
聽聽聽聽> >> > XMPP server (openfire) and tried the same
聽聽聽聽experiment.
聽聽聽聽> This time
聽聽聽聽> >> > video worked as it should (most of the time, I
聽聽聽聽still get
聽聽聽聽> >> > inconsistent results). Even ZRTP worked well in
聽聽聽聽both audio
聽聽聽聽> >> and video.
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> Before I start sending logs, etc, I was
聽聽聽聽wondering if
聽聽聽聽> >> anyone has
聽聽聽聽> >> > been able to use Jitsi's video with SIP, and with
聽聽聽聽> Freeswitch in
聽聽聽聽> >> > particular.
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> I've also setup the videobridge with
聽聽聽聽openfire and that
聽聽聽聽> >> seemed to
聽聽聽聽> >> > work well, although I only tested a little bit.
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> Thanks
聽聽聽聽> >> > >>> ________________________________
聽聽聽聽> >> > >>> Dit bericht kan informatie bevatten die
聽聽聽聽niet voor u is
聽聽聽聽> >> bestemd.
聽聽聽聽> >> > Indien u niet de geadresseerde bent of dit bericht
聽聽聽聽> >> abusievelijk aan
聽聽聽聽> >> > u is toegezonden, wordt u verzocht dat aan de
聽聽聽聽afzender te
聽聽聽聽> >> melden en
聽聽聽聽> >> > het bericht te verwijderen. De Staat aanvaardt geen
聽聽聽聽> >> > aansprakelijkheid voor schade, van welke aard
聽聽聽聽ook, die
聽聽聽聽> >> verband houdt
聽聽聽聽> >> > met risico's verbonden aan het electronisch
聽聽聽聽verzenden van
聽聽聽聽> >> berichten.
聽聽聽聽> >> > >>>
聽聽聽聽> >> > >>> This message may contain information that
聽聽聽聽is not
聽聽聽聽> >> intended for
聽聽聽聽> >> > you. If you are not the addressee or if this
聽聽聽聽message was
聽聽聽聽> >> sent to you
聽聽聽聽> >> > by mistake, you are requested to inform the
聽聽聽聽sender and
聽聽聽聽> >> delete the
聽聽聽聽> >> > message. The State accepts no liability for
聽聽聽聽damage of
聽聽聽聽> any kind
聽聽聽聽> >> > resulting from the risks inherent in the electronic
聽聽聽聽> >> transmission of
聽聽聽聽> >> > messages.
聽聽聽聽> >> > >>
聽聽聽聽> >> > >
聽聽聽聽> >> >
聽聽聽聽> >>
聽聽聽聽> >> --
聽聽聽聽> >> https://jitsi.org
聽聽聽聽> >>
聽聽聽聽> >
聽聽聽聽>
聽聽聽聽> --
聽聽聽聽> https://jitsi.org
聽聽聽聽>

聽聽聽聽--
聽聽聽聽https://jitsi.org


#19

Hi,

while this e-mail is not directly connected to the video problems you see with Jtsi it may
help to complete the understanding of FreeSwitch (FS) behaviour.

A few weeks ago I gave some feedback about the way FS handles ZRTP in case of a non-transparent setup.
There were some problems in ZRTP and RTP/SRTP connections between two Linphone clients connected
to FS.

Here the modified quote:

聽聽FS terminates the RTP session from the SIP client and opens a new RTP session to the other client, thus
聽聽FS it's not "transparent" with regard to RTP. Obviously both RTP sessions have different SSRCs which is
聽聽correct according to the RTP spec (RFC 3550). -> this leads to problems with ZRTP/SRTP

聽聽I'm not sure about the current implementation of FS (you may ask on the FS mailing list), however since some
聽聽time FS permits transparent RTP/SRTP handling if both clients add the "zrtp-hash" attribute to the SIP/SDP
聽聽data. If FS detects this attribute it knows that both clients support ZRTP and that it shall just passthru
聽聽the RTP packets without touching/modifiy them. Groundwire adds this SIP/SDP attribute. You may have a look
聽聽at the SIP data that Groundwire sends and compare it with Linphone's data.

Setting up FS to work that way supports some use cases where the media data must go via FS, for example
in case of a company firewall in a DMZ.

Actually Jitsi adds the "zrtp-hash" SDP parameter at least to the audio SDP data (I've not checked the
video SDP parameters). Thus, in that way Jitsi is a good citizen :slight_smile: . BTW, the problem with Linphone
still exists AFAIK - Linphone does not add the zrtp-hash parameter to the SIP/SDP data.

Werner

Hi,

Thats interesting, thanks for doing the research.

Its strange though, as Freeswitch does support H264 codec in pass through mode:

http://wiki.freeswitch.org/wiki/Codecs#Pass-through_video_codecs

Meaning that it doesn't try and convert the media (like it can with audio streams).

And I can get it to work sometimes.

I might open up a ticket on the Freeswitch bug list and see if they can shed some light on this.

Thanks
Tom

Hi,

I have some good news on this front. Indeed enabling "bypass media" option in FS's SIP profile has video working rather well, at the same level as I
previously reported with XMPP (using openfire). It still sometimes fails on first attempt but usually works well on the 2nd. I still have a buggy experience
with desktop sharing, though, with the call being dropped after intially showing the remote desktop.
Still, this positive experience with "bypass media" clears things up somewhat regarding FS and SIP. I hope this helps others too.
As per their wiki <http://wiki.freeswitch.org/wiki/Bypass_Media>,

"No media" mode is an SDP Passthrough feature that permits two endpoints that can see each other (no funky NATs) to connect their media sessions directly
while FreeSWITCH maintains control of the SIP signaling. This is useful if you have two end-points that need to use a codec that is currently not supported in
FreeSWITCH (video) or if you are using FreeSWITCH in a high performance walled garden network and want to minimize the RTP handling FreeSWITCH is doing to
maximize call traffic.

When set, the media (RTP) from the originating endpoint is sent directly to the destination endpoint and vice versa. The signaling (SIP) for both endpoints
still goes through FreeSWITCH, but the media is point-to-point."

+------------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> >
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽____| FreeSWITCH |___
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ | | \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽SIP / +------------+ \ SIP
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ 192.168.1.105 \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽/ \
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽+----------+ +----------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> > > >
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> endpoint | <---- RTP ----> | endpoint |
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽> A | Audio | B |
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽+----------+ +----------+
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽192.168.1.100 192.168.1.110

Indeed in my testing environment I have both jitsi clients on a local LAN and FS on a remote server on the internet, and video seems to work fairly well. This
leads me to believe that indeed there is a need for an ICE implementation in jitsi for video to work across the internet, as in most cases both clients will
not be sitting behind the same LAN. The difference between "proxy media" and "bypass media" modes in FS seems to be that RTP is not touched by FS at all in
bypass media mode which enables both jitsi endpoints to directly exchange RTP streams.

Like I said, this is great for clients behind the same LAN but likely unworkable in most other scenarios.
I really hope to see jitsi incorporate ICE sooner rather than later.

By the way, besides FS and Asterisk, has anyone had good experience with Kamailio and video?

Cheers

<SNIP --- SNAP>

路路路

Am 20.04.2013 16:28, schrieb Tom Parrott:

On 20/04/13 15:22, Privus 007 wrote: