cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3515
Views
15
Helpful
15
Replies

No audio on 8845/8865 phones calling Verizon cell phones only

wmelick
Level 1
Level 1

Just wondering if anyone else has seen this issue:

 

1) We just upgraded 8841/8845/8865 phone firmware from sip8845_65.11-5-1-18 to sip8845_65.12-1-1SR1-4 on our cluster

2) After the upgrade, outbound calls from 8845's and 8865's to Verizon cell phones have no audio in or out.   Calls to other carriers like Sprint and T-Mobile work just fine.   Calls to landline phones work just fine.

3) Calls are going through a SIP cube.   We have run some SIP traces and see no codec problems or dead streams comparing successful audio calls to no audio calls.

4) Calls from 8841 phones running the newer sip8845_65.12-1-1SR1-4 work just fine --- to the same Verizon phones and others

5) If I downgrade the 8845/8865's to the previous firmware sip8845_65.11-5-1-18 then calls to the Verizon cell phones work fine again with two way audio

1 Accepted Solution

Accepted Solutions

This is a shot in the dark but you may want to try adding “voice-class sip audio forced“ to the PSTN-facing dial-peer(s). I added this to my default config template after having similar issues with Level3 and Jabber a few years back.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-audio-forced.html

View solution in original post

15 Replies 15

Check the sip message for old and new firmware. It seems that new firmware
is either adding or missing audio attributes which Verizon don't like and
hence not able to establish audio path. I think you will need to use sip
normalization to match the required attributes.

Thank you --- I will look into that and post an update if I find a resolution.

wmelick
Level 1
Level 1

After testing, we discovered that if the 8845/8865 camera shutter is closed when a call is initiated, no audio will pass to Verizon cell phones (only affecting Verizon).   Calls to Sprint and T-Mobile cell phones work normally with no issues.

 

However if the shutter is open when the call is initially placed, or if the shutter is opened mid-call, then audio will start flowing normally to Verizon cell phones.

 

If the shutter is then closed mid-call, audio will continue to flow normally through the call. 

 

Given the circumstances, I suspect there must be some video capability message (no video available when the shutter is closed) being sent in the SIP packets which Verizon interprets as no audio capability (or to mute audio).   Other carriers are not affected by this video capability message or ignore it or something.

 

Again this happens only with firmware sip8845_65.12-1-1SR1-4 but not with the older firmware sip8845_65.11-5-1-18.

 

8841 phones do not have video and are not affected.

 

 

Ok. Share the debug for a none working call to see whats happening.

We are hitting the same issue.  We are running the same firmware and upgrading to the latest 12.5.1 this weekend will report back results.  We found not all Verizon client calls were failing but was only Verizon clients that do fail.  Who is your ITSP? Verizon is ours.  One thing Verizon did tell us since we do not subscribe to video on those trunks that they saw requesting video codec from the 8865 in the invite but would ignore it.  So we did test this to remove video requests in the invite at the CUBE and the calls do work when that is applied.  So if not subscribing to video on the SIP trunks obviously Verizon is policing this based on the test with the cube.

This is a shot in the dark but you may want to try adding “voice-class sip audio forced“ to the PSTN-facing dial-peer(s). I added this to my default config template after having similar issues with Level3 and Jabber a few years back.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-audio-forced.html

Adding "voice-class sip audio forced" on the CUBE dial peer seems to have resolved all our issues with 8845/8865 phones and Jabber clients (11.9 and 12.5) dialing Verizon cell phones.

 

The Jabber issue was not initially noticed because Jabber's default settings (options->calls ->Always start calls with video) are compatible with Verizon cell phone audio.   It's only if that setting is modified to "Never start calls with video" that the audio issue is noticed.  (basically mimicking the 8845/65 camera shutter open/closed condition...open = audio, closed = no audio).

 

 


@Mohammed al Baqari wrote:
Ok. Share the debug for a none working call to see whats happening.

Both bad and good calls are identical.
Negotiating g711 both times. Only difference is that that with the camera closed we send  revonly on the video side as expected.
TAC has looked through all the logs from CUCM and Router, they didn't come up with anything.
Still investigating.

 

Please remember to rate useful posts, click on the stars below.

wmelick
Level 1
Level 1

Thanks for all the replies.   We have discovered that Jabber phones (tested on versions 11.9 and 12.5) also have the same issue calling Verizon cell phones....but we have not been able to find a workaround in any of the Jabber client settings.   Jabber calls just do not complete to Verizon cell phones.

 

And yes, our ITSP is Verizon.   One of my co-workers has a TAC case open....I will update if they provide any recommendations which fixes the issue.

We tested 12.5.1 firmware on the 8865 and still the issue.  We also confirmed in Wireshark the only difference is the REVONLY with the shutter closed. 

 

This is what we tested successfully for the workaround.

 

In the cube assign a SIP profile  to the outbound dial-peer to Verizon with the following parameters and the calls should no longer fail.

 

request INVITE sdp-header Video-Attribute remove
request INVITE sdp-header Video-Media modify "m=video(.*)" ""
request INVITE sdp-header Video-Bandwidth-Info remove

 

 

You should use the "voice-class sip audio forced" command on the PSTN-facing dial-peers instead of the SIP Profile. It's more efficient and intended to solve exactly this use case.

Jonathan, I see your point and makes sense.  Thank you for the information!

Looks like the command worked on the 8845 but Jabber is still failing.

Please remember to rate useful posts, click on the stars below.

Interesting, our Jabber calls never failed. Is Jabber registered on-prem, expressway, or both? We used both command recommendations and worked fine.