Calls drop after 30 minutes

[vgitechnology]

We have a customer with a Netvanta 7100 and a SIP trunk to Neturally. Calls drop after 30 minutes exactly. I have enabled the ip rtp firewall-traversal reuse-nat-ports but the calls still drop. The SIP provider ran a wireshark trap and could see the re-negotiate and the media ports change. Any suggestions?

[Anonymous]

vgitechnology,

Were you ever able to resolve this issue?  If so please come back to this post to update it with any information that may be helpful to others.  The problem you described sounds very similar to this post: Re: Calls Cut Off After 15min

If the provider ran a trace and saw the ports change in the SIP SDP, they should also be able to confirm that the RTP ports changed appropriately in the same packet capture file by looking at the ports used for RTP.  If the audio is being sent to the old port, the end users on the phone will likely notice the problem and end the call so it would look normal from a debug. 

Thanks,

Matt

[vgitechnology]

No, the issue isn't resolved. I am still running tests. I use the ip rtp firewall-traversal reuse-nat-ports command but the 7100 changes the RDP port. The SIP provider cannot change the ports on their end.

[Anonymous]

vgitechnology,

    Have you tried the following:

ip rtp symmetric-filter

John Wable

[Anonymous · Accepted solution]

I just wanted to update this post in case it helps someone else.  This issue turned out to be the provider's Sansay softswitch sending audio back to the incorrect port number after it had been changed by the NetVanta 7100's 200 OK response to a re-INVITE.  At the 30 minute mark the Sansay would send a re-INVITE as a keep-alive method. When a re-INVITE is sent to the NetVanta 7100 it must pass this to the phone involved in the call. Once the phone receives the re-INVITE it will change the session ID in the SDP on the resulting 200 OK.  When the NetVanta 7100 receives the 200 OK from the phone with a different session ID it must create a new firewall association for the new session ID and this results in a port change.  The NetVanta 7100 would send the new requested audio port in the SDP portion of the 200 OK response to the Sansay's keep-alive re-INVITE.  At that point the audio should have been sent on the new audio port from the Sansay to the NetVanta 7100, but it was sending audio to the old port number instead, which caused the audio issue. The solution was to disable keep-alives on the Sansay softswitch or configure it to use SIP INFO messages as a keep-alive method instead of re-INVITEs. 

Thanks,

Matt