SIP Signalling regression>1.8.4

I am seeing what appears to be a SIP channel signalling regression from version to 1.8.4. I’m currently running Asterisk on a VM in VMWare, and using snapshots to pop back and forth between versions.

The “Clients” in my case are two Cisco 7960 phones, currently running version 8.9.0 of the SIP software, although the problem manifests with 7.5.0, also.

The operating system is FreeBSD, having built Asterisk using the ports collection in both cases. The only changes from the “stock” config files installed to the ports have been to the sip.conf file to add the two devices in to their own context, and to extensions.conf to define the context, and provide a pair of extensions, one for each phone.

With, a call from one handset to the other “works as expected” - the extension is dialed, the receiver rings, and when picked up, bidirectional audio is provided until one side or the other hangs up, at which time the other end also drops.

With 1.8.4, however, the behavior is distinctly different. When a call is placed on one of the 7960s to the other, the destination starts to ring (good). However, there is no ring back on the originating device. If the destination answers, an audio channel is established from the destination to the originator (E.g. the originator can hear the destination), but no audio channel is established from the originator to the destination (e.g. the destination can not hear the originator). In fact the originator doesn’t even realize the call has been answered. After a few seconds, the destination will detect the call has been dropped, and will hang up.

At this point, the destination will begin ringing again, and the process will repeat. Hanging up the destination prematurely doesn’t make any difference.

After several passes (averages ~3), the initiator provides a slow busy signal, and the phone display states “Reorder”.

I could post a bunch of log messages at this point… In general, the pattern is that there is a SIP retransmission timeout, then both phones go ‘unreachable’, and about 30 seconds later, they become reachable again. The reason I’m not posting the logs verbatim is that the phones never go offline - pinging them from another machine shows they’re online and response time is 1-2ms, although Asterisk will show them, even when they’re online, in the 180ms range. Similarly, the SIP debug logs seem to be sending the right messages to and from the phones, but Asterisk doesn’t seem to act on some of the replies.

I will happily send along whatever logs are considered useful, but didn’t want to spam the forum with pages of useless “looks ok” data.

Thats what I get for waiting to post the issue until the next day…

It fixes the call problem, so apparently the “Cisco Phone Fix” is good.

However, the qualify times are still much higher than the ping time… around 100x.

Thank you very much for the detailed report. Apologies for the mistake. :frowning: