No Audio on SIP softphone (one-X Communicator) when it uses TN2602AP medpro

[cgogan13]

Hi,

I'm in the process of implementing SIP and have come across an interesting issue. Would love to know if anyone else is having this problem and found a solution (other than busying out the TN2602).

We are running CM6.3, We are on a custom patch (21655) which I'm told is most equivalent to 6.3.6. We also have the Bash remediation fix applied (21904).
SM 6.3
SMGR 6.3
SBC 7.1

I'm using one-X Communicator as my SIP softphone.

When I receive an incoming call and answer it, I get two-way audio if the call uses the TN2302 but no audio when it uses the TN2602. On outbound calls made from one-X, I get two way audio regardless of which board the system chooses.

The Medpros are in the same NR.

Any help would be gratefully received!

Ciara

 

[cgogan13]

I should specify that this only happens when one-X is in shared control mode. When it's in My Computer Mode it works just fine.

The specific application here is VDI. one-X Communicator is in Shared Control mode with VDI Communicator.

 

[kyle555]

pcap? i get they're the same NR, are they the same subnet?
Are you running HA SBC or critical reliability 2602?

 

[cgogan13]

They are on the same subnet. issue is happening when we are on internal network too (so on SM). We do not have HA SBC or SM. We do not have critical reliability on TN2602. I've attached a trace from an example an unsuccessful call (meaning no audio).

 

[kyle555]

OK. So, 10.29.8.22 is CM? Why the 2 proxies 10.3.8.51 and 52? Is that a traceSM including security module and websphere? To say, both internal SIP and SM100 traffic?

What's 10.34.179.122? The inside SBC interface?

Problem 1 - no msg with SDP is ever sent to 10.34.179.122. Remote worker calls must have the remote worker send RTP first before the inside of the enterprise sends to the remote worker. If you pcap the remote worker you'll see RTP start with 1 packet on 1 port and then that port+1 is where the remote worker starts sending it's audio. It's so the SBC knows the UDP socket to send media to the remote worker on.

At the end of the day, you never sent a SDP offer to that remote worker. What's a PCAP with 2302's look like? It had to get something out to the remote worker to tell it where to set up audio on.

I'm also curious about the SDP having a RTP/SAVP profile and not just RTP/AVP. I think media rules as they apply to endpoint policy groups might be causing that. Maybe you're confusing CM and if the ip-codec-set doesn't allow encryption then CM ignores RTP SAVP media, even if offered unencrypted. Just a guess. Either way, short answer is your remote worker didn't send audio because you didn't tell it to!

 

[cgogan13]

Thanks Kyle. I've attached a successful call example for comparison. Literally the only thing that changes from call to call is the MedPro board. I understand that it looks like the endpoint isn't telling it where to set up the audio but when the call is "live", before it fails there are messages in the trace that disappear when the call completes/fails, I'll attach that image to another reply

.51 is the SM management IP
.52 is the SM100
179.122 is my one-X C
19.4 is my VDI Communicator

Any idea why remote work would not send the RTP when it's using TN2602 but does send them when it's using TN2302?

Can you explain what you mean by the SDP having an RTP/SAVP but not an RTP/AVP? I don't believe we are allowing encryption on any of our ip-codec sets. Where does the RTP/SAVP initiate from?

 

[cgogan13]

Here is the image of the messages that disappear from the unsuccessful calls after the call is complete:

 

[kyle555]

So what's 10.29.8.22? I presume your CM.
Does the SBC have any role in this call?

Turn off 723 on VDI communicator. 2602s don't support it, 2302's do. If the difference between a good and bad call is strictly having a 2602 busied out and CM sends that first invite to SM in a good call with SDP including 723 and its blank afterwards, maybe that's the crux of it.

 

[cgogan13]

10.29.8.22 is the CM
SBC has no role in this call.
How do I turn off 723 on VDI Communicator? It was the codec that all of the successful calls were using so I added it to all my code sets.

 

[kyle555]

I dunno... haven't worked with VDI.
But, few things - 711A and U and 729 are supported on your One-X C and VDI why's it picking 723 first? Why exclusively?
What I'm reading about VDI is that it seems to be a SIP client and that it autoconfigures somewhere.

Either way, 723 is the problem I think. Even in the good call, you end up negotiating later to 711.

 

[cgogan13]

So, it looks like this is an encryption issue, as you had suspected. one of our ip-codec sets has encryption turned on (no-one knows why). When I tested using other codec sets, calls on the TN2602 were fine. I don't know yet why encryption causes this board to not handle the call properly. It doesn't reject the call, just no audio. I've reached out to my business partner on this too, hopefully they can help figure it out.

Thanks for all your help!

Ciara

 

[kyle555]

I didn't think encryption was the problem. I thought it was G723!
I'd have expected CM to reject a call between 2 endpoints not supporting mutually agreeable codecs/encryption. Or at least a crypto line in the SDP of the SIP offers.
Either way, glad you figured it out!

 

[cgogan13]

You tipped me in the direction of encryption with this comment "I'm also curious about the SDP having a RTP/SAVP profile and not just RTP/AVP. I think media rules as they apply to endpoint policy groups might be causing that. Maybe you're confusing CM and if the ip-codec-set doesn't allow encryption then CM ignores RTP SAVP media, even if offered unencrypted. Just a guess"

I think this was the key. I did also removed the G723 coded because you said it wasn't supported on TN2602 but that alone didn't resolve the issue

Thanks again for all the help!