SV9100 external calls to IRG's keep ringing after caller hangs up

[bigdave1980]

Hello everyone,

We've got a customer using an SV9100 and SIP trunks. In the DDI routing table they've got some DDI's pointed at IRG's containing extensions. The extensions in question are associated with NEC IP handsets.

If a call comes in on one of these DDI's it hits the relevant IRG correctly and rings on the extensions within that group. They all ring simultaneously, as intended.

If nobody answers the call for whatever reason and the caller hangs up, the phones in the group keep ringing. If somebody subsequently answers that ringing call, the line is dead because the caller is already gone.

I've got a feeling I've seen this somewhere before but I couldn't find any reference to it in my notes. Does anybody have any ideas please?

Thanks!

 

[bigdave1980]

Hello,

Sorry to ask again but did anybody have any suggestions on this one please? The end user has done some testing and it seems that the problem only happens when a call comes in on a DDI and goes to a ring group, and it doesn't matter if the call originated from a mobile or a landline. If the caller hangs up before anybody answers, the call continues ringing on the group phones (I'm not sure how long it continues to ring for).

Thanks

 

[bigdave1980]

I've still got problems here unfortunately and the customer has understandably asked me for an update, so if anybody out there has any idea why phones in a ring group keep ringing after an external call to a DDI pointed at that group has hung up, it would be much appreciated please. I've got a feeling I've seen this before, I just can't find any reference to it now.

Thanks,

Dave

 

[IpgPaul649]

What kind of trunks are you using?

 

[bigdave1980]

@IpgPaul649 It's SIP trunks on this one.

 

[IpgPaul649]

Have you ran a Wireshark capture to make sure the disconnect is received and okayed by PBX and carrier with a 200 OK?

 

[bigdave1980]

I've made some changes to the call routing and have done some further testing:

I created a new virtual extension and I pointed the DDI at that. I placed a corresponding virtual extension key on both of the real extensions I wanted to ring on that DDI, and I set the keys to ring. I enabled answering a ringing virtual extension key in COS.

I called the DDI and the end users have confirmed that the phones are ringing as expected, however if the caller hangs up before the call is answered the phones still continue to ring so the problem is not resolved.

This initially seemed to be a problem where DDI's were pointed at ring groups but with my new programming in place there are no ring groups involved.

I'm now wondering if there's maybe some timer within the system that's been adjusted and has effected how long it takes for an incoming call to clear down if the caller hangs up before it's answered, perhaps?

 

[bigdave1980]

I've now pointed the DDI at another extension altogether and asked the end user to test it. They called the DDI, the test phone started to ring, they hung up the call but the test phone kept ringing. The only thing which I can therefore attribute this to is that particular DDI, which seems really strange to me as it's on the same SIP service as all their other DDI's which do not exhibit the same problem and the calls are presumably not going to be coming in over the same trunk every time?

 

[bigdave1980]

After further testing carried out by the end user it transpires that this is affecting all of their DDI's in the same way, not just one particular DDI. I did think all along that it was very unlikely to be just one SIP DDI out of their whole DDI range that was having the issue. The problem continues, so I'll update with any further findings shortly.

 

[bigdave1980]

I have taken a packet trace directly from the NEC SV9100 system whilst making a call to a DDI and hanging up my end before anybody answered. I then opened the trace file in Wireshark, filtered it to show just that particular SIP call, and it produced the output which I have attached to this post as a Word doc. I have had to redact phone numbers and IP addresses out of it, replacing them with XX's, but hopefully people will still be able to follow the call flow and see if there's anything wrong with it. It looks ok to me in as much as I can see the SIP telecom provider has sent a "CANCEL" at the end, but it doesn't seem to have been acknowledged - I am by no means an expert on this though, and I've probably missed something. Please let me know if anything stands out to you in the trace.

Thanks!

 

[bigdave1980]

If anyone's still interested in this one or encounters the same problem in future, I believe it is now fixed. The URI in the INVITE and the BYE were different, and setting 84-39-14 from 0 to 1 seems to be the workaround for that issue.

Many thanks everyone!