atcomsystems.ca/forum Forums TDM Business Telephone Systems Samsung Telephones & Systems Randomly drops IP phone calls on Answer out SIP trunk

NoiseMarine. I'm not seeing ITSP Internet traffic hit my ACL on the remote router so I'm assuming all the SIP\RTP traffic with ITSP is originating & terminating on the 7030 at the main site.

I pulled a packet capture off the router for a "working" and "non-working" session. I'm going to have to adjust some buffer settings because parts of the SIP packets are being truncated in the capture. Nevertheless, comparing them side-by-side you see the SIP setup on both, then you see a stream of UDP packets which I assume is the (RTP) traffic on the "working" session, then more SIP commands to hangup. The "non-working" session does not have the UDP (RTP) packet stream after the initial SIP setup.

It might just be an issue with the packet capture, but I did see 2 SIP Invites at the beginning of the "non-working" Session. Also, I see a SIP registration packet at the end of the "non-working" session. Not sure if the SIP trunk just re-registers itself periodically or if something else trigged the event.

I can have up to 3 concurrent call sessions over the 1 SIP trunk with ITSP. I have check to see if maybe a 2nd call in progress directly on the 7030 is affected at the same time I have a audio-issue on a ITP call. I don't think the trunk is dropping because the call will stay connected, it's just not passing 2-way audio.

It was late when I started remote testing last night so just got the 2 truncated captures. I'll need to tweak my packet capture and hopefully get a lot more samples tonight.

I hate the customer has to go through another day of losing half their ITP calls but it's difficult to isolate the details during the day.

It would be nice to have a remote webserver with some VoIP API's that you could remote control to generate some call traffic for testing. If I'm onsite I've just been calling my offsite VM to test 2-way audio. My system emails me the VM so I can verify audio was working both ways.

Last night from my office, I just remotely disabled their ATA to free up the 3rd Party SIP license, then re-programmed a 2nd ATA in my office to be an Ext. on their system so I could test making an outbound call to my office without having to go onsite. It worked good for all the testing for the SIP packet captures.

Why is it that jobs that generate 2% of your revenue end up taking up 98% of your time???

I took detailed packet captures to the ITSP on to\from the ITP phone. There is no logical reason why it sends the (RTP) payload on 1 call and not on the next. The problem has to be related to the ITP\SIP phones on v4.60b. Last night I hooked them to local LAN with 7030 and same problem. So, the VPN isn't a variable. I reviewed the v4.65 tech note and it seems to address some erratic ITP behavior. My next step is to upgrade software to v4.65. Anybody having any problems with v4.65? Probably going to wait a while on v4.70.

Upgrade to v4.65 solved ITP/SIP problem.

Who is your SIP trunk provider? Have you talked with them to make sure all of the IP's they have are on your ACL. That has happened to me before. Also have you tried putting in the subnet in 838.

Ironhedz- All those settings were correct. The problem was only with ITP\SIP phones\ATA on 4.60. I don't have the problem with 4.65 after upgrade.