Generic SIP phones used with vMCD - No audio from when being transferred

[Martin]

Were currently experiencing an issue with some generic SIP phones (Incom ICW-1000) to be exact, where on certain occasions, an external call is transferred from one phone to another, the receiving handset picks up, then there is no audio. However the call seems to be active on the screen.

The setup is these phones are at an external site and point to an external MBG which then passes through to the vMCD we have setup.

From looking into the SIP transactions there is no clear indication as to why this is happening, it is an intermittent issue, which confuses things more.

Does anyone have an recommendations of possible SIP settings on the vMCD either in the "SIP device capabilities" or "SIP peer profile" settings that would have an effect on this?

Thanks in advance
Martin

[Dogbreath]

Is it possible the RTP port range configured on access rules...somewhere...don't quite match, meaning that only occasionally the issue will be seen?
Do you see events in MSL about one-way audio from IS or SS [I believe that abbreviation is ICP-side and set-side]?
MBG generates copious logs so you might find something interesting in there so long as you can get an accurate report of when the issue is occurring.

[Martin]

Hi Dogbreath,

Thanks for your response, I have had a check through the logs on the MBG,

I do actually have example times of a call where this happened, so I do have times and dates to go back to. Unfortunately there is no indication of any IS or SS one-way audio issues or any other issues at all.

Its almost like the call is becoming stuck between the transfer and its still on hold. Its like there is a missing signal from SIP to finish transfer the calls.

I'm almost positive this issue wouldnt be there if they were Mitel phones, 3rd party SIP devices can be a pain.

Thanks

[Dogbreath]

Is the external leg of the call on SIP as well?

Best place to start looking would be in SIP Device Capabilities form - copy the existing one to a new one and look at SDP Options tab. Obviously if this isn't easily reproducible then it's going to be a slow process iterating through them.

If you can get your head around it, sngrep is a great tool for SIP troubleshooting. If your users can report the issue to you promptly enough you can leave sngrep running in a screen session and look at the ladder diagram for the call.

[Martin]

Yes the external leg of the call is on SIP

As you've mentioned, I had a look at the SIP device capability form initially. Group 1 is currently configured for these SIP devices, I am currently monitoring the issue after making a change to the following setting "Prevent SDP Renegotiation If Peer Initiated Hold" from no to yes.

Not sure if this will resolve the issue however, i'm just working through the SDP options at the moment.

[Dogbreath]

If the external leg is on SIP then "Avoid Signalling Hold to Peer" may be useful.

[Martin]

I did notice that setting, however that's one of Mitel's recommended settings to keep set to "Yes" which it currently is

Source: http://edocs.mitel.com/UG/Apps-Solutions/MiCollab%207.1/MiCollab/MiCW%20Help/programming/recommended_sip_peer_device_cap_settings.html

[acejavelin]

I did notice that setting, however that's one of Mitel's recommended settings to keep set to "Yes" which it currently is

Source: http://edocs.mitel.com/UG/Apps-Solutions/MiCollab%207.1/MiCollab/MiCW%20Help/programming/recommended_sip_peer_device_cap_settings.html

Yeah, it might be recommended but that doesn't mean it fits any scenario... I would try it and if it doesn't change anything you can always change it back.

[Martin]

Very true acejavelin, I will keep it in mind if the current setting change doesn't sort the issue.