CS1000E rel 7.6 sending INVITE without SDP

[routetehpacketz]

I'm dealing with an issue where inbound calls that are first answered on our CS1000 and subsequently transferred to voicemail experience no audio when the call hits voicemail. To summarize, this is being caused by the CS1000 sending an INVITE back to the ITSP as it's transferring the call to voicemail. This is causing the ITSP to default to G.729 since no codec negotiation is being done at that time, and we only have support for G.711.

I found this Technet post regarding the same issue but between a CS1000 and Lync server.

Does anyone know of a way to always have SDP messages present in SIP packets sent by the CS1000?

 

[bignose21]

So we have the same sort of issue between Sonus UX2000 (Gateway for Lync) and 7.6 CS1K, same happens to a Contact centre and also to conference bridge. We had a case open with Sonus and they have informed us that they will fix it in the next release due this month (issue in their firmware). Difference was that the UX did not like the UPDATE message sent from the CS1K to give the UX the DSP details.

Think when we looked for the SDP it was in the progress message from the CS1K prior to the 200 OK.

 

[routetehpacketz]

Thanks, bignose. I see you replying on here regularly and I appreciate you taking the time to try helping people out.

Do you know if there is any way to disable SIP INVITEs w/o SDP from being sent by the CS1K? This would be the easiest solution if it's possible.

Edit: Also, do you happen to know under what circumstances the CS1K will send such an INVITE? I'm trying to simulate what's happening with our voicemail issue against a Cisco router running CME and I'm seeing an empty INVITE going internally to the CME router instead of back out to the carrier like we see with the actual issue. The CME router doesn't seem to care about this lack of SDP and just continues the call normally.

The reason I'm trying this simulation is one solution we've considered is just licensing our voicemail application for G729, but we want to be a little more comfortable that it will fix the problem before we throw money at it. The CME router supports G711 and G729, but I can't get the CS1K to behave the same way when testing.

 

[bignose21]

So for us it is when the update is sent. Call is ringing against a set if it's answered no problem. If not it forwards to callpilot. An update message is sent with no SDP and call is silent. We could find no way to stop this, there is a pluggin that is supposed to disable the Update when unsupported that didn't work. Also make sure your patched to date as we had silent call issues over sip when redirected that was fixed by MGC CSP firmware. Also VTRK Sig server patches fix these sort of issues.

We are now waiting on Sonus to fix this in their latest release out this month.

Needless to say most problems I have seen are with call redirects.

Also remembering an issue we used to have between Cisco and CS1k where we used to switch off the SIP Options in the Sig Server if you give me you release I will dig out the commands and you could try them.

 

[routetehpacketz]

thanks again. our CS1K is on rel 7.6, is there a more specific number than that?

 

[bignose21]

Issue the following command on SS to turn off OPTIONS on CS1K:
$ vxShell vtrk sipNpmAppDebugSet tSSG optionSupport 0

optionSupport changed from 1 to 0

value = 0x0 (0)

To turn it on the following commands is used:

$ vxShell vtrk sipNpmAppDebugSet tSSG optionSupport 1

optionSupport changed from 0 to 1

value = 0x0 (0)

If SS is SYSLOADED or even if VTRK application is restarted the setting will be reset, i.e. OPTIONS support will be turned on for CS1K

 

[PDTuser]

what rel and vintage of machines? REL 7.6 SP9 is latest, must also have matrix match in ASM. Many known issues in SIP SDP causing 1 way speech. Can also be solved by running SIP thru SBC and SBC can manipulate/ignore SDP. However cs1k does comply with IEEE SIP standards
Session Manager is indeed required for SIP interop from CS1K 7.5 and up as mentioned in the excerpt you shared earlier.

We do require compatibility testing via 'Avaya DevConnect' for support for any '3rd party SIP interop product'. Avaya support teams refer 'DevConnect' library to check for relevant application note in case of any such interop issues. This is especially important in case of SIP, where open standards does not imply plug and play and compatibility testing ensures any interworking issues are resolved before customer deployment.

Both Oracle ECB & AVST are not listed in the CS1K interop - DevConnect list.

Also, please note that before connecting to a public network via "SIP trunk", a Global SIP Service Provider Compliance Program (GSSCP) testing is mandated to ensure feature are working as expected and nothing is breaking.