Trial Update & SIP Registration expiration

[cfabe]

I've made good progress toward launching my VOIP service to customers of my ISP. I currently have my ATAs on internal IPs with the gateway router doing 1:1 NAT to static public IPs for each ATA. This is working well and I think should eliminate NAT traversal problems.

I did encounter one thing I wanted advice on. During my testing I was having problems with incoming calls ringing but no audio coming through. Packet sniffing I could see the inbound UDP audio stream but the ATA was sending icmp pings rather than audio which were not being returned by the voipo server. After a long time (1 hour +), the condition would correct and calls would work fine. I noticed that this happened only after the ATA was reset. Also noticed that in the voipo cpanel under connections, two connections from the same ATA would show up with different times when this problem occurred. After some time, it seemed like the earlier connection would go away and then the calls would work normally.

I found a setting in the ATA for "Unregister on Reboot" which I set to yes and it seems to have fixed this. The duplicate connections do not appear and calls are working fine immeadiately after rebooting the ATA. I am concerned however that if the ATA loses power or net connectivity rather than being rebooted through the web UI, could the unregistration not go through and cause this condition to appear?

Also, is this timeout window I was seeing related to the "Registration Expiration" setting in the ATA? Right now it's set to the default of 1 hour. Should I make this shorter, like 1 minute?

[GreenLantern]

Unplug one and see what happens.

Good info, thanks!

[VOIPoBrandon]

Hello,

The audio issue you are running into is not directly related to the multiple registration factor, however it can introduce similar issues as you are experiencing -- depending on your network setup.

The user locations, or "registrations" you are seeing are solely informative as to where to send the SIP signaling and how to setup the audio path and essentially simply makes the phone "ring".

However the audio path is negotiated in this SIP signaling and transmitted in the initial INVITE and following 180/183 and 200 OK in an attached SDP body.

So my assumption without actually looking at any specific account would be that one of two things are happening:

1) Your registrations are not consistent and thus mis-informing of the proper required audio setup, i.e. one registration appears to be behind NAT, while the other does not, while as the public IP is still routing down to the device but effectively breaking the SDP signaling due to the incorrect NAT handling.

2) The audio ports being negotiated are simply just not passing traffic down to the device (each time a call is initiated a random port is selected in a range, i.e. 5004 - 65000 UDP).

The user location expiration is based off of the next registration interval. This way as a new registration is made, the previous registration expires.

Let me know if this helps clear the air a bit and if you have any further questions.

If you wish to PM me an example username I would be happy to further look into this and possibly narrow it down for you even further.