Thanks to Poly, I am able to video-chat on my VVX 601 (UC 188.8.131.5227 camera 9.0.21). I am using it in an OpenSIP environment. SIP-Video worked right out of the box. With a powerful remote party, the camera delivers H.264 up to a blazing Level 5.1 with 1080p and 30 frames per second. It looks like Poly was very clever and the camera itself is doing all the encoding stuff; the phone just passes the H.264 from the camera through. Great!
However, I face three issues:
1. H.264 SPS: Constrained Baseline Profile
In the protocol analyzer Wireshark, I am looking at the raw data. If your video stream is not detected as RTP, right-click on it and decode it as RTP. If your RTP stream is not detected as H.264, go to the Menu Bar → Preferences → Protocols → H264, and enter the negotiated payload type from the SIP INVITE/SDP. Now, when I look at the H.264 Sequence-Parameter Set (SPS), my VVX sends not the Constrained Baseline Profile (CBP) but the normal one (BP). This was not negotiated in SDP. That is a software bug for sure because my VVX claims to support just CBP for receiving. Can somebody confirm my finding and report it internally?
2. Transmitting (Tx; video encoder)
The Administrator Guide 6.3 confused me when it comes to the supported Tx frame-sizes. On one page, the guide states: “VVX 5xx and 6xx with a USB camera support sending 720p resolution for Tx Frame size”. On another page, the guide states 1080p as maximum. Furthermore, I was able to trick the camera into much more Tx frame-sizes like “625 SD”, and “625 HHR”. However, I was not able to send 540p, 360p, or 270p. Can somebody update that guide and include all Tx frame-sizes for both alternative cameras?
3. Receiving (Rx; video decoder)
In the SDP of the SIP INVITE, the phone claims to be able to receive H.264 Level 1.3 (see RFC 3984 a=fmtp:99 profile-level-id=42800D). The Web and provisioning interfaces allow me to increase that to Level 2. Both levels support 352×288 (CIF) as maximum. That works great with a VVX 501 and its 4:3 display. However, on my VVX 601, with its 16:9 display, I get black bars (left and right). Furthermore, CIF is lower than the display resolution itself. I was able to feed 640×360 (360p = nHD = HVGAW) by sending the remote party a different a=fmtp in SDP. Looks really great! 720p (HD) did not work. I did not test 540p (qHD). Long story short, two questions:
3.1 Can somebody update the Administration Guide and include all Rx frame-sizes with their maximum frames-per-second for each model: VVX 50x, VVX 600, and VVX 601?
3.2 Surprisingly, the Administration Guide mentions one larger Rx format: SVGA (800×600). However, the guide does not explain how to trick a remote party into that. Again, the phone states not to be able to receive more than CIF. Besides that SVGA curiosity, the current a=fmtp does not leverage the 16:9 display on a VVX 60x. Can somebody double-check the a=fmtp in SDP?
I have no support channel to report this except writing postal letters to the CEO. Therefore, I am asking here in the community first. Perhaps, I have a complete misunderstanding.
Those sound like luxury problems because I went for the mighty VVX 601, right? However, those issues are about more, wrong usage of RFC 3984, particularly its SDP offer/answer model.
When a phone states, it supports just H.264 Level 2, the largest format is CIF – in both directions. RFC 3984 does not know a concept of upgrading the level or doing asymmetry in Rx and Tx. Because the phone states its level is 2, the maximum frame-size is going to match CIF. Consequently, the Administration Guide is wrong because it claims 720p and 1080p for Tx. Same for Rx, the SVGA statement in the Administration Guide is not possible because CIF is the maximum according to its SDP. If Poly wants asymmetry, the correct way would be to upgrade the (in the year 2011 obsoleted) RFC 3984 and go for RFC 6184. Then, the following SDP/fmtp would be possible for a VVX 60x:
a=fmtp:99 profile-level-id=42800D;level-asymmetry-allowed=1;max-fs=510;max-mbps=15300 ... which gave 270p@30fps.
And for a VVX 50x:
a=fmtp:99 profile-level-id=42800D;level-asymmetry-allowed=1 ... which gave CIF@30fps.
Those would be the "a=fmtp" for the SDP offer.
VVX phones send the largest format for the offered level (see ITU-T H.264 Table A-6)†. This behavior is not OK. This is allowed only when also the received SDP contained level-asymmetry-allowed=1.
† Side note: Any max-... (RFC 3984) or imageattr (RFC 6236) got ignored in my tests. Therefore, I could not trick my VVX 601 into sending a 16:9 like 270p, which would be the best when two VVX 60x video-chat together.
Hello @ishiCEnT ,
Welcome to the Poly Community.
I am not sure what the reason for this post is as we are having many spammers recently copying random existing text but for your issue can you please answer the following:
If yes then get this into support as instructed below:
In order to raise a support ticket, you need to work with your Poly reseller as they may need to do this for you.
End Customers are usually unable to open a ticket directly with Poly support. Available End User Poly services offerings are detailed here
If this is some sort of an Internet discounter providing your MAC address or your Poly devices serial will enable us to look up who would be able to support you. This may not be who you purchased the Poly device from.
If not and the unit is no longer within the warranty please be prepared to Pay Per Incident / PPI. This is all outlined in detail here
No need to send a postal letter to our CEO as our support organisation and our documentation can take care of everything once this is in support.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Not sure, I understand. I do not need support. I fixed this already for me. This is just a bug report. Furthermore, I made it public so others who stumble over the same issue can overwrite the a=fmtp if they are using a SIP-B2BUA. Anyway, the S/N on the phone is 64167f0a5691 and on the camera 18491610.
Hello @ishiCEnT ,
The VVX 601 was sold by Ingram Micro HQ Germany back in 12/5/2017 so it is well out of warranty.
As I am not aware of any other customer reporting this as an issue, and this being a single phone, there is unfortunately not an awful lot we can do.