[jitsi-dev] Video call between Jitsi and Polycom VVX 500


#1

Hi,

I have been tested video calls using latest Jitsi nightly build and Polycom
VVX 500

If the INVITE is initiated by Polycom, video si seen on both ends, so
everything is fine
But if INVITE is initiated by Jitsi, video is seen only on Polycom. No
video is seen on jitsi.

I have taken pcaps and when INVITE is initiated by Jitsi, the H264 code
entry is seen two times

v=0
o=207 0 0 IN IP4 192.168.0.80
s=-
c=IN IP4 192.168.0.80
t=0 0
m=audio 5000 RTP/AVP 96 97 98 9 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 usedtx=1
a=rtpmap:97 SILK/24000
a=rtpmap:98 SILK/16000
a=rtpmap:9 G722/8000
a=rtpmap:100 speex/32000
a=rtpmap:102 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 speex/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
m=video 5002 RTP/AVP 105 99
a=rtpmap:105 H264/90000
a=fmtp:105 profile-level-id=4DE01f;packetization-mode=1
a=imageattr:105 send * recv [x=[0-1920],y=[0-1080]]
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4DE01f
a=imageattr:99 send * recv [x=[0-1920],y=[0-1080]]

Here:
m=video 5002 RTP/AVP 105 99
a=rtpmap:105 H264/90000
a=rtpmap:99 H264/90000

Is this OK, shouldn't this be shown only for payload id 105?

If the INVITE is initiated by polycom, I see this:

v=0
o=- 1381228829 1381228829 IN IP4 192.168.7.103
s=Polycom IP Phone
c=IN IP4 192.168.7.103
b=AS:512
t=0 0
a=sendrecv
m=audio 2266 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
m=video 2268 RTP/AVP 109 34
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42800d
a=rtpmap:34 H263/90000
a=fmtp:34 CIF=1;QCIF=1;SQCIF=1

Here I see two different codecs:

m=video 2268 RTP/AVP 109 34
a=rtpmap:109 H264/90000
a=rtpmap:34 H263/90000

I cannot figure out what the problem might be, but I suspect that jitsi
should send only one H264...

Please let me know if anyone is able to reproduce this. I will try to debug
some more.

Thanks,
Mircea


#2

Hey Mircea,

Hi,

I have been tested video calls using latest Jitsi nightly build and Polycom
VVX 500

If the INVITE is initiated by Polycom, video si seen on both ends, so
everything is fine
But if INVITE is initiated by Jitsi, video is seen only on Polycom. No video
is seen on jitsi.

I have taken pcaps and when INVITE is initiated by Jitsi, the H264 code
entry is seen two times

v=0
o=207 0 0 IN IP4 192.168.0.80
s=-
c=IN IP4 192.168.0.80
t=0 0
m=audio 5000 RTP/AVP 96 97 98 9 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 usedtx=1
a=rtpmap:97 SILK/24000
a=rtpmap:98 SILK/16000
a=rtpmap:9 G722/8000
a=rtpmap:100 speex/32000
a=rtpmap:102 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 speex/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
m=video 5002 RTP/AVP 105 99
a=rtpmap:105 H264/90000
a=fmtp:105 profile-level-id=4DE01f;packetization-mode=1
a=imageattr:105 send * recv [x=[0-1920],y=[0-1080]]
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4DE01f
a=imageattr:99 send * recv [x=[0-1920],y=[0-1080]]

Here:
m=video 5002 RTP/AVP 105 99
a=rtpmap:105 H264/90000
a=rtpmap:99 H264/90000

Is this OK, shouldn't this be shown only for payload id 105?

No. The packetization-mode is a differentiator for H.264 payload types
[RFC3984] , so support of different packetization modes requires
presence of several payload types in an offer or an answer (kind of
the same way as you would see SILK or Speex present more than once for
8KHz, 16KHz, 24KHz, etc.).

In your example the polycom seems to only offer packetization mode 0.
Jitsi offers packetization modes 0 and 1.

I don't know if the extra packetization mode is causing the Polycom to
freak out for some reason but if you want to give it a try you could
disable PM1 with the following property:

net.java.sip.communicator.impl.neomedia.codec.video.h264.packetization-mode-1.enabled=false

Hope this helps,
Emil

···

On Tue, Oct 8, 2013 at 1:43 PM, Mircea Carasel <mirceac@ezuce.com> wrote:

If the INVITE is initiated by polycom, I see this:

v=0
o=- 1381228829 1381228829 IN IP4 192.168.7.103
s=Polycom IP Phone
c=IN IP4 192.168.7.103
b=AS:512
t=0 0
a=sendrecv
m=audio 2266 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
m=video 2268 RTP/AVP 109 34
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42800d
a=rtpmap:34 H263/90000
a=fmtp:34 CIF=1;QCIF=1;SQCIF=1

Here I see two different codecs:

m=video 2268 RTP/AVP 109 34
a=rtpmap:109 H264/90000
a=rtpmap:34 H263/90000

I cannot figure out what the problem might be, but I suspect that jitsi
should send only one H264...

Please let me know if anyone is able to reproduce this. I will try to debug
some more.

Thanks,
Mircea

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

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


#3

It would be interesting to see how the polycom answers to this. As Emil
said, the two PTs are different, but some
implementations (e.g. linphone, IIRC) ignore the
packetization-mode parameter and return an answer with
two identical PTs.

Regards,
Boris

···

On 10/8/13 1:43 PM, Mircea Carasel wrote:

Hi,

I have been tested video calls using latest Jitsi nightly build and
Polycom VVX 500

If the INVITE is initiated by Polycom, video si seen on both ends, so
everything is fine
But if INVITE is initiated by Jitsi, video is seen only on Polycom. No
video is seen on jitsi.

I have taken pcaps and when INVITE is initiated by Jitsi, the H264 code
entry is seen two times

v=0
o=207 0 0 IN IP4 192.168.0.80
s=-
c=IN IP4 192.168.0.80
t=0 0
m=audio 5000 RTP/AVP 96 97 98 9 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 usedtx=1
a=rtpmap:97 SILK/24000
a=rtpmap:98 SILK/16000
a=rtpmap:9 G722/8000
a=rtpmap:100 speex/32000
a=rtpmap:102 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 speex/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
m=video 5002 RTP/AVP 105 99
a=rtpmap:105 H264/90000
a=fmtp:105 profile-level-id=4DE01f;packetization-mode=1
a=imageattr:105 send * recv [x=[0-1920],y=[0-1080]]
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4DE01f
a=imageattr:99 send * recv [x=[0-1920],y=[0-1080]]


#4

Hey Emil,

No. The packetization-mode is a differentiator for H.264 payload types
[RFC3984] , so support of different packetization modes requires
presence of several payload types in an offer or an answer (kind of
the same way as you would see SILK or Speex present more than once for
8KHz, 16KHz, 24KHz, etc.).

In your example the polycom seems to only offer packetization mode 0.
Jitsi offers packetization modes 0 and 1.

I don't know if the extra packetization mode is causing the Polycom to
freak out for some reason but if you want to give it a try you could
disable PM1 with the following property:

net.java.sip.communicator.impl.neomedia.codec.video.h264.packetization-mode-1.enabled=false

Thanks for your quick answer
I am still facing the problem. I added the property and now SDP looks like
this:

v=0
o=207 0 0 IN IP4 192.168.0.80
s=-
c=IN IP4 192.168.0.80
t=0 0
m=audio 5004 RTP/AVP 96 97 98 9 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 usedtx=1
a=rtpmap:97 SILK/24000
a=rtpmap:98 SILK/16000
a=rtpmap:9 G722/8000
a=rtpmap:100 speex/32000
a=rtpmap:102 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 speex/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
m=video 5006 RTP/AVP 99 105 106
a=recvonly
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42E01f
a=imageattr:99 send * recv [x=[0-1920],y=[0-1080]]
a=rtpmap:105 H263-1998/90000
a=fmtp:105 CIF=1;QCIF=1;CUSTOM=1920,1080,2;VGA=2
a=rtpmap:106 VP8/90000

Also, If I try with Bria phone, it looks fine. I see video from bria on
Polycom
The bria INVITE SDP looks like this

v=0
o=- 3590217082 3590217082 IN IP4 192.168.0.40
s=cpc_med
c=IN IP4 192.168.0.40
b=AS:554
t=0 0
m=audio 4000 RTP/AVP 0 107 8 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:107 SILK/8000
a=fmtp:107 useinbandfec=1;usedtx=0
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 4002 RTP/AVP 102 97
c=IN IP4 192.168.0.40
b=TIAS:512000
a=sendrecv
a=rtpmap:102 VP8/90000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800c
a=orient:portrait
a=rtcp-fb:* nack pli

What is strange to me is why jitsi specifies a=recvonly, but actually it
sending video to polycom fine. It does not receive video, so behavior is
like "sendonly"
Bria specifies a=sendrecv.
Please let me know if there is anything else I should try.

Thanks!
Mircea

···

Hope this helps,
Emil


#5

Hi,

It might be also related to H264 profile. You can try adjusting it in
advanced->H264 settings tab.

Hope this helps !
Pawel

···

On Tue, Oct 8, 2013 at 3:42 PM, Mircea Carasel <mirceac@ezuce.com> wrote:

Hey Emil,

No. The packetization-mode is a differentiator for H.264 payload types
[RFC3984] , so support of different packetization modes requires
presence of several payload types in an offer or an answer (kind of
the same way as you would see SILK or Speex present more than once for
8KHz, 16KHz, 24KHz, etc.).

In your example the polycom seems to only offer packetization mode 0.
Jitsi offers packetization modes 0 and 1.

I don't know if the extra packetization mode is causing the Polycom to
freak out for some reason but if you want to give it a try you could
disable PM1 with the following property:

net.java.sip.communicator.impl.neomedia.codec.video.h264.packetization-mode-1.enabled=false

Thanks for your quick answer
I am still facing the problem. I added the property and now SDP looks like
this:

v=0
o=207 0 0 IN IP4 192.168.0.80
s=-
c=IN IP4 192.168.0.80
t=0 0
m=audio 5004 RTP/AVP 96 97 98 9 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 usedtx=1
a=rtpmap:97 SILK/24000
a=rtpmap:98 SILK/16000
a=rtpmap:9 G722/8000
a=rtpmap:100 speex/32000
a=rtpmap:102 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 speex/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
m=video 5006 RTP/AVP 99 105 106
a=recvonly
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42E01f
a=imageattr:99 send * recv [x=[0-1920],y=[0-1080]]
a=rtpmap:105 H263-1998/90000
a=fmtp:105 CIF=1;QCIF=1;CUSTOM=1920,1080,2;VGA=2
a=rtpmap:106 VP8/90000

Also, If I try with Bria phone, it looks fine. I see video from bria on
Polycom
The bria INVITE SDP looks like this

v=0
o=- 3590217082 3590217082 IN IP4 192.168.0.40
s=cpc_med
c=IN IP4 192.168.0.40
b=AS:554
t=0 0
m=audio 4000 RTP/AVP 0 107 8 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:107 SILK/8000
a=fmtp:107 useinbandfec=1;usedtx=0
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 4002 RTP/AVP 102 97
c=IN IP4 192.168.0.40
b=TIAS:512000
a=sendrecv
a=rtpmap:102 VP8/90000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800c
a=orient:portrait
a=rtcp-fb:* nack pli

What is strange to me is why jitsi specifies a=recvonly, but actually it
sending video to polycom fine. It does not receive video, so behavior is
like "sendonly"
Bria specifies a=sendrecv.
Please let me know if there is anything else I should try.

Thanks!
Mircea

Hope this helps,
Emil

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


#6

Hey Pawel,

Hi,

It might be also related to H264 profile. You can try adjusting it in
advanced->H264 settings tab.

Hope this helps !

Thank you so much for the tip! Yes, this indeed helped
I just
put net.java.sip.communicator.impl.neomedia.codec.video.h264.preferredKeyFrameRequester=signaling
(The default value is rtcp)
and now it works!

Thanks again!
Mircea

···

On Tue, Oct 8, 2013 at 4:49 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Pawel


#7

Hi Mircea,

Hey Pawel,

Hi,

It might be also related to H264 profile. You can try adjusting it in
advanced->H264 settings tab.

Hope this helps !

Thank you so much for the tip! Yes, this indeed helped
I just put
net.java.sip.communicator.impl.neomedia.codec.video.h264.preferredKeyFrameRequester=signaling
(The default value is rtcp)
and now it works!

Thanks again!
Mircea

Great ! I'm glad I could help.

Regards
Pawel

···

On Tue, Oct 15, 2013 at 1:04 PM, Mircea Carasel <mirceac@ezuce.com> wrote:

On Tue, Oct 8, 2013 at 4:49 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

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