cisco CME - xferred calls sometimes dropping, sometimes bad quality

[zittastanislav]

Good evening,

I have serious issues to get CME with SPA502g phones to work correctly. Incoming calls from outside are always routed to internal extension 204, then, they're xferred to some else internal phone (desired behavior). Sometimes, this call drops, but in debug voice ccapi inout log I don't see any reason. Only this line seems suspicious to me:

Sep 11 10:18:36.034: //1559/577A59248A27/CCAPI/ccCallDisconnect:

   Cause Value=0, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

Cause value 0? Come on! Even google can't find explanation for that...

But this isn't the only problem i have .

When call is transferred internally, sound has terrible quality. When sound is transferred from outside world to any inside extension, no bad quality sound at all.

Also, transferred calls from outside world cannot be transfered again. Imagine situation like this: somebody calls from outside and has number xyzyyyxxx -> connected to 204 -> xfer to (i.e.) 211 -> wan't xfer to (i.e.) 205 but can't, phone doesn't offer that option. I am not sure if this is feature or failure, because that phone has only one line.

I collected this output from debug voice ccapi inout command whole afternoon and you can  find this file as an attachment (it's quite large).

I am also attaching anonymized configuration. If you could see anything odd, please let me know.

[zittastanislav]

Mr. Giordano, thank you very much.

Your advices solved 95% of our problems, users are reporting after one-week testing, that intra-country-calls are okay - except calls coming from foreign countries. Users are reporintg calls from foreign countries are still being dropped. I have PCAP log of one such dropped call and I don't see anything suspicious, except "unrecognized sip-header (remote-party-id)" warning in some SIP messages. Remote-party-id command regards this warning. If you would, I could upload that PCAP log somewhere. Do you think it could be the reason? I am not onsite, therefore I cannot test it and eventually revert it back. Therefore I am asking here first.

Have a nice day.

[Daniele Giordano]

Can you upload pcap file here?

Regards.

[zittastanislav]

PCAP attached. Thanks for your effort.

[Daniele Giordano]

Your PCAP trace sounds good. There is only a little anomaly. The cisco sends two CONNECTION INFORMATION in the SDP header:

This could generate interoperability issues with some ITSP. The common issue is sporadic one way audio. The problem is described here:

Duplicate c= Lines in SDP Cause Intermittent One-way Audio with Various ITSP(s)

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_tech_note09186a0080bfa510.shtml

To fix it you must remove the first C instance.

It's explained in the above link.

Regards.

[zittastanislav]

Thanks for useful link and info. I guess I should remove 1st occurence of c=.... line (RFC 1918 address).

Before posting that document here, I thought problem lies in repeatedly sent INVITES from 90.182.178.... and these invites aren't acknowledged by 88.103.241...., therefore call is dropped after some timeout. But if you say that's okay, then I'll trust it.

At least your post gave me at least few clues what to focus at. I'll let you know if your suggestions helped.

Have a nice day.

[zittastanislav]

Hello again after long time,

Since last hint of Daniele Giordano I didn't hear any complains about call dropping and call quality.

Hint that helped me most was the one with "I don't see CME acting as B2BUA". Therefore, I'd consider this issue as solved,

Thank you all who helped me solving this issue and sacrificed their time to help me.