• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended

Hello!

I'm experiencing an issue with Polycom VVX 411 (UC version 6.3.1.11465 )

 

Schema of the call using OPUS codec
Some other endpoint -> Asterisk (TLS/SRTP) -> Polycom VVX

Call establishes correctly, but when pressing HOLD on Polycom, on unHOLD I'm getting one-way audio on the phone. This means what I'm saying on some other endpoint can't be heard on Polycom, but everything I'm saying on Polycom is heard by Asterisk/another endpoint. Recording made on Asterisk is shown both streams are reaching Asterisk and (S)RTP is sent towards Polycom.

 

But this scheme is working another way round.

Polycom VVX -> (TLS/SRTP) Asterisk -> Some other endpoint. If Polycom phone is call originator, hold/unhold works as expected.

 

On investigating this scenario, I've found, that in the first case, Polycom phone on unhold change RTP payload of Opus from initial 107 sent by Asterisk originally (and accepted in 200 OK by Polycom with same 107 payload) to 121, and Asterisk also changes payload to 121 and seems Polycom is not accepting it anymore.

 

This problem is not replicated with using PCMA/PCMU codecs.
I've attached 2 pcap's with this case. owa stands for one-way-audio, 2wa - for two-way-audio.

 

1 ACCEPTED SOLUTION

Accepted Solutions
HP Recommended

Good catch. Did you get any reply to your support ticket already?

 

I am able to reproduce your issue with my Digium Asterisk 13.38.2 and a Poly VVX 601 with 6.4.0. RTP or sRTP does not matter here. Other audio codecs like G.711, G.722, Siren7, and Siren14 work.

 

That possible culprit about the change in the dynamic payload type seems correct. Great analysis! By default, Digium Asterisk sends 107 for the Opus-Codec. You can change that in the file main/rtp_engine.c to the 121, which Poly uses on default. Alternatively, you can change the default RTP payload type in your phone. This is not possible via the Phone interface or the Web interface. However, the Provisioning interface (accessible via Web → Utilities → Import Configuration as well) allows <PHONE_CONFIG><ALL voice.audioProfile.Opus.payloadType="107" /></PHONE_CONFIG>. Not sure why that is not documented in the Administrator Guide. Anyway, both approaches worked in my tests.

 

So, until this is resolved, either disallow the Opus-Codec or go for the same RTP payload type.

View solution in original post

5 REPLIES 5
HP Recommended

Hello @Igor Olhovskiy ,

Welcome back to the Poly community.

Some or a couple of your old post(s) or reply(s) to them => here <= are still open/pending as you have not marked these as "Accept as a solution" or at least provide some form of feedback or answer.

If they are in this state nobody finding them via a community search will know if an answer or advice provided was useful and has maybe helped you.

Could you therefore kindly go over them and mark or answer as appropriate?

If they are marked as "Accept as a solution" other users can find these easier and it helps them to utilise the community more efficiently. Please do not simply mark them without any type of feedback.

 

For your new issue, we would need to know if this ever worked and/or if this is a new issue. We would also need to see your backup/ configuration.

 

This sounds like a support issue and therefore cannot really be dealt with by the volunteers in this community.

 

Other volunteers are welcome to comment but if this all fails we would need to see this in support.


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 the unit is no longer within the warranty please be prepared to Pay Per Incident / PPI. This is all outlined in detail here


Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

------------------------------------------------
Notice: I am an HP Poly employee but all replies within the community are done as a volunteer outside of my day role. This community forum is not an official HP Poly support resource, thus responses from HP Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
If you need immediate and/or official assistance for former Poly\Plantronics\Polycom please open a service ticket through your support channels
For HP products please check HP Support.

Please also ensure you always check the General VoIP , Video Endpoint , UC Platform (Microsoft) , PSTN
HP Recommended

Steffen,

It's a new issue and this setup is also totally new.

For config - sure, nothing secret here (unless passwords)

 

I'm suspecting, that this is a limitation of the phone itself, having only 1 OPUS stream. Means when the phone on unhold changing payload dynamically, it counts re-negotiation as adding a second stream or so. But it's guessing.

 

HP Recommended

Hello @Igor Olhovskiy ,

 

without looking at this in our support organisation I am unable to comment.

 

Feel free to follow as advised if no other volunteers have any ideas.

 

Best regards

 

Steffen Baier

------------------------------------------------
Notice: I am an HP Poly employee but all replies within the community are done as a volunteer outside of my day role. This community forum is not an official HP Poly support resource, thus responses from HP Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
If you need immediate and/or official assistance for former Poly\Plantronics\Polycom please open a service ticket through your support channels
For HP products please check HP Support.

Please also ensure you always check the General VoIP , Video Endpoint , UC Platform (Microsoft) , PSTN
HP Recommended

Good catch. Did you get any reply to your support ticket already?

 

I am able to reproduce your issue with my Digium Asterisk 13.38.2 and a Poly VVX 601 with 6.4.0. RTP or sRTP does not matter here. Other audio codecs like G.711, G.722, Siren7, and Siren14 work.

 

That possible culprit about the change in the dynamic payload type seems correct. Great analysis! By default, Digium Asterisk sends 107 for the Opus-Codec. You can change that in the file main/rtp_engine.c to the 121, which Poly uses on default. Alternatively, you can change the default RTP payload type in your phone. This is not possible via the Phone interface or the Web interface. However, the Provisioning interface (accessible via Web → Utilities → Import Configuration as well) allows <PHONE_CONFIG><ALL voice.audioProfile.Opus.payloadType="107" /></PHONE_CONFIG>. Not sure why that is not documented in the Administrator Guide. Anyway, both approaches worked in my tests.

 

So, until this is resolved, either disallow the Opus-Codec or go for the same RTP payload type.

HP Recommended

Igor, your trace contained SIP and SDP but not RTP. You are using as channel driver not chan_sip but chan_pjsip. Anyway, I stand corrected. Because of the same issue with three other VoIP/SIP phone platforms, I investigated this further: Asterisk 13 LTS and its SDP negotiation on a re-INVITE turned out to be the cause at the end. Two alternative solutions are documented in the issue tracker, see ASTERISK-27056 …

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.