Changed SIP Providers, no audio for EC500 phones 1

[murpr]

We recently changed phone SIP providers and an odd issue has presented itself with EC500 configured phones (whether EC500 is enabled or not).

When calling into our PBX from the configured phone, in my case my cellphone, I hear the ring back but no other audio. I don't hear announcements, DTMF from my cell is not processed (or heard). Watching a trace of my station, my cellphone is recognized as my station with the inbound call and the trace shows that an announcement should be playing, but nothing is heard.

If EC500 is enabled and a call comes to my cellphone via EC500, it works fine. Audio works.

If I remove the EC500 config for my cellphone, the same call works fine as well.

I've tried modifying a few items in the config set, but I'm mostly grasping at straws there since the trace appears that it should be working. Any thoughts?

 

[kyle555]

trace it on the SBC 2 times. Once calling in without EC500 and it working and again without. the SDP inside the sip messages will tell the story. Posting a screenshot of a SIP ladder won't help

 

[murpr]

So the difference I can see is when there is no audio, I am seeing a line indicating something different. I'll do some googling to see what I can turn up. (SIP: 200 OK (INVITE) (SDP: [IP and PORT] RTP/AVP 0 101 13 sendrecv) where as the call with audio, the 13 code is missing from that line.

Thanks for giving me some direction!

 

[kyle555]

You'd want to expand on those messages and see exactly what they say.

0 = g711u
101 is RFC2833 DTMF
13 = comfort noise

https://en.wikipedia.org/wiki/RTP_payload_formats

the 200OK is from CM answering your cell, so the SDP in there is how the SBC wants to catch audio from the carrier.
The invite from the carrier to the SBC probably contains the SDP the way the carrier wants to catch it.

Next thing you want to look at is the SIP headers in the 200OK when it works and when it doesn't. Look for "from" and "p-asserted-identity" and "contact"

CM might be putting in something like your extension in there when it sees it's a EC500 station vs when it's not. Something about sending valid CLID required on the carrier - or intercarrier side - might be getting grumpy about some headers you're sending back.

If you see a difference, check your sigma script on the SBC facing the carrier. Maybe there's a devconnect note for that provider that has some details or otherwise paste your script here along with the headers from the 200OK of the good and bad call and I might be able to figure it out.

 

[murpr]

The sigma script we are using is for outbound calls to remove the extension names from appearing. I've pasted it below. When there is no audio (ec500 is configured), there is a line "Av-Call-Appearance:..." with my extension which is not present in the call without ec500 configured.


within session "ALL"
{
act on request where %DIRECTION="OUTBOUND" and %ENTRY_POINT="POST_ROUTING"
{
remove(%HEADERS["From"][1].DISPLAY_NAME);
remove(%HEADERS["Contact"][1].DISPLAY_NAME);
remove(%HEADERS["P-Asserted-Identity"][1].DISPLAY_NAME);
}
}

 

[kyle555]

Yeah, that header is telling you the call is on line 1 of your phone.
If P-Asserted-Identity and FROM and SDP look the same, then try removing that header outward to the PSTN. It "shouldn't" cause problems and your carrier "should" ignore it, but at least you can try making it as close as possible.

 

[murpr]

I'm going to be working with my BP tomorrow morning (low volume on the SBC) to do some PPM traces to see what comes back. I'll update once I have something back.

 

[murpr]

I was incorrect about the trace my BP ran. It was a wireshark, but I am unclear on where it was run from. Either way, it didn't provide anything useful. I found that I do have an inbound TN still active on my old SIP circuit. Calling that number still works as it used to and the traceSBC is definitely different when comparing the new circuit to the old. The "Ringing" line for the working call is "SIP: 180 Ringing (SDP: 192.168.xxx.xxx:xxxx RTP/AVP 0 101 sendrecv)" where as the non-working is the same up until "...RTP/AVP 0 101 recvonly)" Going to run that info up to my BP to see what they come back with while I do a bit of research.

 

[jimbojimbo]

When you get a recvonly it typically means you are going on hold. We primarily see this with IVR vendors with early media and an IP Address and Port. If the wireshark was taken at the external interface of the SBC and the recvonly is coming from your carrier then you need to talk to them. If you look at the response you may find you are sending SDP with 0.0.0.0 and no port. If this is the case a sigma script to add a port (just put in 10000) may fix your issue.

 

[murpr]

My BP has been sending traceSBC captures to Avaya for review. They've had us try a couple sigma scripts with no success as of yet. I'm trying to better understand the traceSBC to understand what I'm looking at. As soon as I have more news, I'll continue to update this thread.

 

[murpr]

I realized last night that I never updated this. I don't have anything useful to add. While the SIP provider was troubleshooting a separate issue, they made a change and, while they didn't fix the issue they were trying to, the change somehow fixed my EC500 issue. I wish I could add anything useful here, but the SIP provider is not good with change control and doesn't know what they did.