On Tue, 19 Oct 2004 09:44:12 -0400, Gene Willingham <[EMAIL PROTECTED]> wrote: > What I think is happening is: If I receive an inbound call on IAX during an > IAX registration, the call does not get setup. I appear to be unavailable > to the other server. When a call fails I noticed using tcpdump that the > inbound packets are destined for port 13081. When the call succeeds the > inbound packets are destined for port 4569. Port 13081 seems to make sense > when looking at iax2 show registry. But it does not match the output from > tcpdump when compared to calls that succeed. > > gw1*CLI> iax2 show registry > Host Username Perceived Refresh State > 66.234.228.170:4569 QSa55JPy58 x.x.x.50:13081 60 Registered > > [IAX2 debug enabled] > Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: > REGREQ > > Timestamp: 00017ms SCall: 00002 DCall: 00000 [66.234.228.170:4569] > USERNAME : QSa55JPy58 > REFRESH : 60 > > gw1*CLI> > Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: > REGACK > Timestamp: 00015ms SCall: 00186 DCall: 00002 [66.234.228.170:4569] > USERNAME : QSa55JPy58 > DATE TIME : 156437288 > REFRESH : 60 > APPARENT ADDRES : IPV4 x.x.x.50:13081 > > gw1*CLI> > Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: ACK > > Timestamp: 00015ms SCall: 00002 DCall: 00186 [66.234.228.170:4569] > Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 000 Type: IAX Subclass: > HANGUP > Timestamp: 09779ms SCall: 00518 DCall: 00000 [66.234.228.170:4569] > > Output from tcpdump: > 22:02:48.246092 x.x.com.4569 > 170-228-234-66.cosmoweb.net.4569: udp 12 (DF) > [tos 0x10] > 22:03:18.597719 170-228-234-66.cosmoweb.net.4569 > x.x.com.13081: udp 84 > (DF) > 22:03:20.601668 170-228-234-66.cosmoweb.net.4569 > x.x.com.13081: udp 84 > (DF) > 22:03:28.406522 170-228-234-66.cosmoweb.net.4569 > x.X.com.13081: udp 12 > (DF) > 22:03:30.406566 170-228-234-66.cosmoweb.net.4569 > x.x.com.13081: udp 12 > (DF) > 22:03:30.601889 170-228-234-66.cosmoweb.net.4569 > X.X.com.13081: udp 84 > (DF) > 22:03:38.236056 X.x.com.4569 > 170-228-234-66.cosmoweb.net.4569: udp 28 (DF) > [tos 0x10] > 22:03:38.246584 170-228-234-66.cosmoweb.net.4569 > x.x.com.4569: udp 52 (DF)
The last two look like an outgoing call which you initiated. You have to distinguish between incoming and outgoing calls, they are two entirely different scenarios, especially when you traverse NAT. An incoming call is -- from the viewpoint of your NAT router -- a response to your earlier registration. So, as far as the NAT router is concerned, you are the one who originated the incoming call by calling out first making the registration request. NAT uses different ports in order to map different streams going to the same target port. In your example, the registration request is mapped to 13081 but it will nevertheless reach Voicepulse's server on port 4569. When you get an incoming call from Voicepulse, then as a result of that registration having arrived from 13081, Voicepulse will come in at your NAT router on 13081 even though it will have used 4569 on its own outbound interface. This is what allows your NAT router to figure out that this is a response to your earlier registration and that the stream is to be sent to your Asterisk server. There could still be another IAX device on your network also having registered with Voicepulse. Your NAT router would have mapped that to another port, for example 19999. Then Voicepulse would send a call for that device to port 19999 and your NAT router would then know that the call is meant for the other IAX device and not your Asterisk server whose registration was mapped to 13081. This is how NAT works. Now when you make an outgoing calls, then that call may well use port 4569 on the WAN side of your NAT router and response traffic would then come in on port 4569. What I believe may be the problem you are facing is that your NAT router may perceive the NAT mapping and the fact that your Asterisk server is in a DMZ as a conflict. When you get the incoming call on port 13081, the NAT router may not properly map it according to the NAT mapping table but it may give the DMZ rule priority and simply pass the traffic on to your Asterisk server in the DMZ that is to say it will not be mapped back to 4569 but it will come in on port 13081 which your Asterisk server isn't configured to recognise as an IAX port. It doesn't know anything about the mapping table of your NAT router, so it won't map it back to 4569. After all, this is the job of your NAT router, but it seems that for some reason it didn't do that job. I have seen this with quite a few software DMZs. In most cases this can be solved by taking the Asterisk server out of the DMZ and use individual port forwarding for those ports that you want to be exposed, like 5038 for remote management for example, and not forward 4569. This will allow the NAT router and the IAX register mechanism to work the way they are intended to work. When a call comes in on 13081 the NAT router will not be confused about the DMZ and it will map the traffic back to port 4569 on your Asterisk server. If you need to offer IAX service to IAX clients who register with your server, you may want to do that on a different port, ie 14569, like so: [someIAXclient] type=user secret=blah host=dynamic port=14569 then port forward 14569 on your NAT router to port 14569 on your Asterisk server. hope this helps regards benjk -- Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya, Tokyo, Japan. NB: Spam filters in place. Messages unrelated to the * mailing lists may get trashed. _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users