Calls Cut Off After 15min

[phonealchemist]

All,

Got an interesting situation; We've got a NetVanta 7100 installed with 7 IP 712 phones running off of it. When a call runs longer than 15min, the 7100 terminates the call. We've talked with the SIP provider, and their records show that the BYE message originates from the 7100. I've gone through all the CoS profiles, and I don't see a field there that specifies that calls can only last a certain amount of time.

Is there somewhere I should be looking to investigate this?

[Anonymous · Accepted solution]

This may be a firewall issue.  You may need to set some ip policy-timeout statements to allow the calls to go longer than 15 minutes.  This may be for the IP phone, or it may be for the provider if you are using a SIP trunk.  I would try maintaining a call from one extension to another on the same LAN to see if the call goes longer than 15 minutes. 

[phonealchemist]

We did verify that we could sustain a call longer than 15min for local calls, but not for long distance. We've verified with the SIP provider that the BYE is originating from the 7100. We also did extend ip policy-timeout to eight hours to try and resolve it.

[Anonymous]

I concur with that at the surface this sounds like a firewall issue.  Are their any other network elements in this topology or just the phones connected directly to the 7100?  Does the Internet connection terminate in the 7100?  Can you gather the output from a debug voice verbose and a debug sip stack messages both enabled at the same time and submit it along with the current configuration to the FTP server with the instructions below?  If there is a lot of traffic a 15 minute debug is going to be huge, so if possible I would recommend doing this test after hours when there is minimal traffic.

Open Internet Explorer web browser on their PC
Type the following URL:  ftp://ftp.adtran.com

Press the Alt key, click View, and then click Open FTP Site in Windows Explorer

Double-click the "Incoming" folder
Drag and drop files from PC into the Internet Explorer window

Reply to this post with the exact filenames used so we can retrieve the files

Thanks,

Matt

[jayh]

If local firewall tweaks don't fix it, in your trunk facing the SIP provider, try either:

sip-keep-alive info 300

or

sip keep-alive options 300

This will cause a SIP message every five minutes (300 seconds) on active calls which will refresh session data on any intermediate firewalls or SBC devices that the call is still up. 

Alternatively, if you have such a statement now, especially with a value of 900 seconds, remove it. A downstream long-distance provider might not be responding properly.

[integra]

Hi guys,

I'm having exact same problem after changing a defective unit, reloaded configs and updated firmware but can't resolve the 15 minute call issue.

Tried tweaking firewall and sip keep alive but no results.

Did you find the cause and solution to problem?

[phonealchemist]

I originally didn't have keepalives on the trunks, but I do now, but the problem still persists. I'm starting to think that this MIGHT be a long-distance calling issue, but I can't say for certain yet. We were trying to recreate this issue last week with no success, then yesterday it did it again when I wasn't in a position to watch the call.

There will be another call tomorrow where we suspect that it'll happen again, and I'll be watching then; I'll post debug and config then. To compare with Integra, the 7100 is running on 10.7.1 because of an issue with 10.8 and mail servers using START-TLS.

[Anonymous]

Once I can see the debug output and the the configuration we should hopefully be able to find the issue.  Make sure to let me know the answer to these questions too:

Are their any other network elements in this topology or just the phones connected directly to the 7100?  Does the Internet connection terminate in the 7100?

Thanks,

Matt

[phonealchemist]

There are other elements in the network topology, but the phones connect to the 7100 directly. The ports are configured as trunks because we have end-user equipment hooked up to the phones. The internet connection terminates on the 7100. If it will be helpful, I can produce a visio of the network layout.

[phonealchemist]

I got a debug of the issue happening; the station that was doing the calling was extension 2003. They were calling xxx-241-7203, starting at around 3:01pm MST, finishing about 3:45pm MST. The calls cut off roughly around 3:16 and 3:31pm.

Message was edited by: matt - removed debug and sensitive information from post

[integra]

Hi Matt

Attached are debug files and logging error reports from the cut off after 15 minutes. Let me know if you can determine cause You can see call being terminated at 20h07 In logging events it shows as 2014.01.22 20:07:33 VQM.EVENTS Monitoring session ended for 221 to xxxyyy8488, RTP=xx.xx.32.18:35104->192.168.2.110:3002, MOS (LQ/PQ)=4.20/4.45, loss=0 pkts, out-of-order=0 pkts, jitter=0 ms

Best regards

Pierre

Message was edited by: matt - removed personal contact info

[Anonymous]

phonealchemist,

Looking at the debug that you provided, the SIP provider is using an INVITE at the 15 minute mark as a keep-alive for the call. When this happens, the 7100 is changing the audio port from the original port of 50460 to 50480. Most likely, the provider is sending the audio to the old port, 50460 instead of the new port and that is causing the one-way audio. Once the user loses the audio after the re-INVITE, they are most likely hanging up and ending the call. A packet capture of the WAN interface would provide evidence that the 7100 isn't receiving audio on the correct port.

[phonealchemist]

The logic follows there Ryan, but they don't lose audio; the call ends at the station, and the user has to redial. I'm sending the provider OPTION keep-alives to keep the call open, and they keep sending me more OPTION keep-alives to ensure that the trunks are open.

[Anonymous]

Pierre - The attachments did not come through.  Can you please resubmit the debug output and the configuration to the FTP server with the instructions listed earlier in this thread?

[Anonymous]

Phonealchemist,

Thanks for the clarification. Looking back over the debug, the call is ended by the SIP provider in both instances. At time stamps 15:15:28.714 and 15:31:07.598 the 7100 receives a BYE to tear down the call. The provider may be able to shed some more light on why the call is being torn down.

[phonealchemist]

Thanks for examining this Ryan. I've gone back to the carrier, and from their perspective, they're seeing the calls disconnect from the dialed-party's end, even then we know this is not the case. They're opening a ticket with their tech-support and will get back to me. I'll advise when I get something new from them.

[phonealchemist]

Ok, directly from an email that the SIP provider, this is what they're seeing:

From what I found on the call that originated at 15:00 on the 22nd, @ 15:00:07,569  XXX-452-1315 originated a call to XXX-241-7203, and at this time the Adtran set up the source RTP port of 50460, this call went along and 15 minutes into the call the Metaswitch call feature server sends out a “keep-alive”  re-invite to the adtran 7100,  the adtran 7100 responded back with a 200 OK to this re-invite   (the keep alive re-invite is set to the highest parameter in the CFS and this is something we cannot remove)  with this response 200 OK back from the adtran 7100 at 15:15:21.061 the adtran changed the source RTP port to 50480, this is what started the chain of events in dropping the call,  once the CFS saw the source RTP port change to 50480 we were waiting to accept packets from this port, yet it appears that the adtran was still sending the traffic on the RTP port 50460,   I am not totally sure this is the case, that is why you would need to perform a packet capture on the adtran to see if this is actually the case.

I have attached some of the trace I was able to capture on the first call placed that dropped showing a little bit of what I described above, and some of the engineering data captured by Metaswitch on this call (see below), showing that at 15:15:28,880 packets being dropped.

Checking my configs under Voice -> System Setup -> VoIP Settings -> RTP Settings, I see that 'Re-use NAT ports' is checked and therefore the 7100 shouldn't be trying to change the port unless something else is happening here. Ideas?

[Anonymous · Accepted solution]

That option in the GUI corresponds to the ip rtp firewall-traversal reuse-nat-ports command. If the reuse option is set, then the 7100 should stay with the same ports for a given call ID/SDP session ID.

Just for the sake of clarity, I was looking at the first call to xxx-241-7203 in the debug file you originally supplied.  In that debug the call comes up with the following details:

x.x.132.230 (7100) sends audio to x.x.240.66 (Metaswitch) on port 28394

x.x.240.66 (Metaswitch) sends audio to x.x.132.230 (7100) on port 50460

Then after 15 minutes, the Metaswitch sends a re-INVITE with the same SDP to serve as a keep-alive. The 7100 responds back with a 200 OK with SDP asking to receive audio on a new port (50480).  So the new call should be up with these details:

x.x.132.230 (7100) sends audio to x.x.240.66 (Metaswitch) on port 28394

x.x.240.66 (Metaswitch) SHOULD BE sending audio to x.x.132.230 (7100) on port 50480

The response you posted above indicated they were expecting the 7100 to send audio to the Metaswitch on port 50480, but it should have been the other way around. The Metaswitch should be sending audio to the 7100 on that port (50480).

Here are our suggestions to move forward with this issue:

• Upgrade the IP 700 firmware to at least R2.3.0.  The current version running is not supported and may be contributing to the problem. 
• Upgrade the 7100 to R10.9.2.
  • This may not resolve this specific issue, but you mentioned downgrading because of the TLS issue.  The TLS fix is included in R10.9.2. If we are going to look at a new debug, especially to investigate any potential issues, it would be best if you were running this later version.
• Ensure the Metaswitch and the 7100 are configured according to this guide:

If after performing the steps above the issue is still occurs, a packet capture on the WAN of the 7100 would be the next step as the SIP provider suggested.  This would be the best bet to confirm what is truly happening.  It is imperative this be done in conjunction with the same debugs running on the 7100 again. I would suggest doing it when there is minimal traffic to help minimize the file size of the PCAP. If you can gather the packet capture, new debugs, and the current configuration I would be happy to review them.  You will need to submit them all in a .zip to the FTP server with the instructions in my earlier response on this thread.  When the issue is recreated it would also help to document if a party gets one way audio, and if so which side.

Thanks,

Matt

[Anonymous]

I am having the same issue on one of our 7100's, Metaswitch and 15 minutes and only long distance.  It is not clear to me _which_ of these things fixed the issue.  Is it unchecking the 'Re-use NAT ports', or the firmware update.  I'm seeing it on R10.8.1.E.

/rh

[integra]

Veuillez notez que je suis en vacance et serai de retour au bureau le 8 Janvier

Pour toute demande de service veuillez communiquer avec Dragan Jerbic au (514) 835-2065

Joyeuses Fêtes

***************************************************************************************************

Please note that I am on vacation and will return to the office on jan 8th

For any service call please communicate with Dragan Jerbic (514) 835-2065