I'm having a problem, I'm not sure if it has todo with the fact that my phone is behind a NAT or not, but here it is.. My problem is when I call out, my asterisk system routes the call to my SIP provider, whoever, as soon as the other party answers, asterisk tries to make a native bridge for the call, and then the call drops instantly. However, if I keep asterisk in the middle (by anyable transfers), no bridge is made and the call stays just fine. My setup is so: Sipura-2000 -> NAT (Netgear router) -> cable/internet -> colocated asterisk server -> SIP provider The native bride I assume is asterisk trying to connect the RTP stream directly from the Sipura to my SIP provider (thus asterisk keeping it's self out of the media stream), and this is exactly what I would like to have. But I can't for the life of be figure ot why it's just hanging up once the bridge is made. Does anyone have any ideas how I could fix this, this is sort of important, if it's just me because of my NAT causing it, would doing so part forwarding and disable NAT support on asterisk and the Sipura fix this problem? I'll welcome any input, Nathan Goodwin Diamonleaf Communications LLC
Nathan Goodwin wrote:> Does anyone have any ideas how I could fix this, this is sort of > important, if it's just me because of my NAT causing it, would doing so > part forwarding and disable NAT support on asterisk and the Sipura fix > this problem?It's almost impossible to fix this problem. Here's the scenario: Your SPA-2000 initiates a call to the * server, and then * initiates a call to your provider. When the provider answers, * tells the SPA-2000, and it starts sending RTP to *. By doing so, your NAT/firewall expects to receive packets back from the _same IP address and port they were sent to_. While * is still in the media path, this is how it works, and things are fine. However, when * tries to re-invite the SIP provider to send audio directly to your SPA-2000, the packets now arrive from a different IP (and probably a different port number). Any decent NAT/firewall will drop them on the floor. Thus, no audio from the provider. It is _possible_ for this to work if * happens to reinvite your SPA-2000 _first_, and it starts sending audio directly to the SIP provider, thus opening a different IP/port combination through the firewall. However, this is not reliable, and there is no way to force the reinvites to happen in a particular order (or to complete in a particular amount of time). You can disallow reinvite for your SPA-2000 but leave it turned on for your provider, in which case one direction of the media stream can bypass *. Otherwise, you need a NAT/firewall that understands SIP so it can be aware of the changes as they occur (or you need to use a SIP proxy on the NAT/firewall, like siproxd).
> I'm having a problem, I'm not sure if it has todo with the fact that my > phone is behind a NAT or not, but here it is.. > > My problem is when I call out, my asterisk system routes the call to my > SIP provider, whoever, as soon as the other party answers, asterisk > tries to make a native bridge for the call, and then the call drops > instantly. > > However, if I keep asterisk in the middle (by anyable transfers), no > bridge is made and the call stays just fine. > > My setup is so: Sipura-2000 -> NAT (Netgear router) -> cable/internet -> > colocated asterisk server -> SIP provider > > The native bride I assume is asterisk trying to connect the RTP stream > directly from the Sipura to my SIP provider (thus asterisk keeping it's > self out of the media stream), and this is exactly what I would like to > have. > > But I can't for the life of be figure ot why it's just hanging up once > the bridge is made. > > Does anyone have any ideas how I could fix this, this is sort of > important, if it's just me because of my NAT causing it, would doing so > part forwarding and disable NAT support on asterisk and the Sipura fix > this problem?To add to what others have already said... you can try: - canreinvite=no on the asterisk def for the Sipura - setting udp port forwards on your nat box will be difficult and somewhat unpredictable as each Internet sip device that trys to reinvite to you _may_ use different udp port number ranges. * uses udp 10k-20k, Cisco phones a different range, xlite yet a different range, etc. Each sip device vendor can choose whatever range they want. But, if the reinvite is always coming from the same device, you might find out what the range is for _that_ device and port forward those ports. (There could also be an issue of exactly which IP address that device might be trying to contact, your internal IP or the nat'ed external IP.) - get another registered IP address and assign it to your sip phone. - replace your nat box with a sip-aware box. For the most part, a sip device behind a nat box limits you to converseing with the * box.