My apologies, I wasn't clear on what information was required. Yes, 26483 was the destination for transfer. I called from my cell, 6472424441. The provider is at the IP 74.X, and phones are at 10.8.X.X The log was taken after logs were cleared, and I performed a reboot of the entire system. There were two incoming calls, one I messed up the extension and hung up on purpose. The second call should show the nasty behaviour.
Any other details required? AJ On Fri, Oct 28, 2011 at 5:13 AM, Tony Graziano <tgrazi...@myitdepartment.net> wrote: > I looked at the trace. I tried to look at it, but you didn't explain the > call, so I followed it (takes time without an explanation). > Was the call going to "26483", meaning is that the target of the transfer? > > On Thu, Oct 27, 2011 at 11:06 PM, Adrien Guillon <aj.guil...@gmail.com> > wrote: >> >> Any further ideas? I'm not sure if the snapshot I had attached showed >> up or not.... >> >> AJ >> >> On Wed, Oct 26, 2011 at 8:57 PM, Adrien Guillon <aj.guil...@gmail.com> >> wrote: >> > Yes, my trunk is using the public address. >> > >> > Earlier in this thread, I pasted the relevant iptables rules. This is >> > a linux firewall, and the relevant NAT rules are: >> > >> > # Enable masquerading >> > iptables -t nat -A POSTROUTING -o $WAN_IFACE -j SNAT --to-source >> > 123.123.123.123 # this is my external IP >> > >> > # Port forward SIP to voipserver >> > iptables -t nat -A PREROUTING --dest 123.123.123.123 -p udp --dport >> > 5060 -j DNAT --to-destination 10.0.0.6 >> > iptables -t nat -A PREROUTING --dest 123.123.123.123 -p udp --dport >> > 5080 -j DNAT --to-destination 10.0.0.6 >> > iptables -t nat -A PREROUTING --dest 123.123.123.123 -p tcp --dport >> > 5060 -j DNAT --to-destination 10.0.0.6 >> > iptables -t nat -A PREROUTING --dest 123.123.123.123 -p tcp --dport >> > 5080 -j DNAT --to-destination 10.0.0.6 >> > iptables -t nat -A PREROUTING --dest 123.123.123.123 -p udp --dport >> > 30000:31000 -j DNAT --to-destination 10.0.0.6 >> > >> > On Wed, Oct 26, 2011 at 7:03 PM, Tony Graziano >> > <tgrazi...@myitdepartment.net> wrote: >> >> what kind of firewall is this? >> >> >> >> On Oct 26, 2011 6:50 PM, "Tony Graziano" <tgrazi...@myitdepartment.net> >> >> wrote: >> >>> >> >>> On Oct 26, 2011 6:21 PM, "Adrien Guillon" <aj.guil...@gmail.com> >> >>> wrote: >> >>> > >> >>> > To address your points: >> >>> > >> >>> > > sipx server should be behind NAT. It's IP address should be >> >>> > > using >> >>> > > stun or have the public address manually input. >> >>> > >> >>> > The public address has been input into Devices -> Gateway -> xxx -> >> >>> > NAT -> Public IP address >> >>> > >> >>> > > the itsp should NOT be doing nat traversal for you. >> >>> > >> >>> > I have configured their web interface to indicate I am not behind a >> >>> > NAT. >> >>> > >> >>> > > stop using the iptables sip conntrack modules, they will not be >> >>> > > of >> >>> > > any help. just setup iptables to do symmetric nat. >> >>> > >> >>> > Done, I have removed them. >> >>> > >> >>> > > make sure your trunk say to use the public address for call >> >>> > > setup. >> >>> > >> >>> > Not sure how to do this. >> >>> >> >>> system>server>nat >> >>> > >> >>> > Please see the attached sip log, and thanks for all of your help :-) >> >>> > A call was dropped around 18:18:53, the first call I made I tried >> >>> > the >> >>> > wrong extension so I disconnected myself. >> >>> > >> >>> > AJ >> >>> > >> >>> > On Wed, Oct 26, 2011 at 2:04 PM, Tony Graziano >> >>> > <tgrazi...@myitdepartment.net> wrote: >> >>> > > They have not so far, because there is a public IP showing in the >> >>> > > FS >> >>> > > negotiation. I don't think it should be there when you are behind >> >>> > > NAT. >> >>> > > I >> >>> > > checked mine and it did not do that. >> >>> > > >> >>> > > On Wed, Oct 26, 2011 at 1:59 PM, Adrien Guillon >> >>> > > <aj.guil...@gmail.com> >> >>> > > wrote: >> >>> > >> >> >>> > >> Before we get too far into the analysis, can someone confirm that >> >>> > >> my >> >>> > >> NAT looks about right, to eliminate that issue first? >> >>> > >> >> >>> > >> AJ >> >>> > >> >> >>> > >> On Wed, Oct 26, 2011 at 11:54 AM, Tony Graziano >> >>> > >> <tgrazi...@myitdepartment.net> wrote: >> >>> > >> > it is probably more so of an issue with the way the carrier >> >>> > >> > treats >> >>> > >> > reinvite. >> >>> > >> > I don't recall seeing a not allowed here in the trace files so >> >>> > >> > I >> >>> > >> > don't >> >>> > >> > know >> >>> > >> > why codec is being brought up. there are multiple things wrong >> >>> > >> > with >> >>> > >> > his >> >>> > >> > firewall config so maybe once that is fixed this will be easier >> >>> > >> > to >> >>> > >> > work >> >>> > >> > on. >> >>> > >> > >> >>> > >> > On Oct 26, 2011 11:46 AM, "winson (Elabram)" >> >>> > >> > <winson.k...@elabram.com> >> >>> > >> > wrote: >> >>> > >> >> >> >>> > >> >> .... is it codec issue? >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> On 26/10/2011 04:07, Adrien Guillon wrote: >> >>> > >> >> > Hi everyone, >> >>> > >> >> > >> >>> > >> >> > I have been working on incoming calls from a sip trunk, and >> >>> > >> >> > debugging >> >>> > >> >> > potential issues. Right now, calls are disconnected >> >>> > >> >> > immediately >> >>> > >> >> > after >> >>> > >> >> > I dial an extension from the AA (when I call externally). >> >>> > >> >> > I'm >> >>> > >> >> > pretty >> >>> > >> >> > sure the NAT is configured properly, and I'm starting to >> >>> > >> >> > narrow >> >>> > >> >> > down >> >>> > >> >> > the problem. The NAT uses nf_conntrack_sip rather than >> >>> > >> >> > explicitly >> >>> > >> >> > opening RTP ports. I used tcpdump to monitor incoming >> >>> > >> >> > calls, >> >>> > >> >> > and I >> >>> > >> >> > find events such as (right before disconnection): >> >>> > >> >> > >> >>> > >> >> > 19:40:25.689135 IP bm-srv-01.voicenetwork.ca> 123.456.1.12: >> >>> > >> >> > ICMP >> >>> > >> >> > bm-srv-01.voicenetwork.ca udp port 19222 unreachable, length >> >>> > >> >> > 208 >> >>> > >> >> > >> >>> > >> >> > I have discussed this with a friend, and one potential issue >> >>> > >> >> > could be >> >>> > >> >> > how the phone network is configured. My phones are >> >>> > >> >> > firewalled >> >>> > >> >> > so >> >>> > >> >> > that >> >>> > >> >> > they can only communicate with the SipX server. I am not >> >>> > >> >> > sure >> >>> > >> >> > if the >> >>> > >> >> > transfer negotiation is attempting to pass the connection >> >>> > >> >> > directly to >> >>> > >> >> > the phone, which then has no path back (and is not really >> >>> > >> >> > reachable >> >>> > >> >> > from the NAT system). >> >>> > >> >> > >> >>> > >> >> > Any suggestions? >> >>> > >> >> > >> >>> > >> >> > AJ >> >>> > >> >> > _______________________________________________ >> >>> > >> >> > sipx-users mailing list >> >>> > >> >> > sipx-users@list.sipfoundry.org >> >>> > >> >> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >>> > >> >> > >> >>> > >> >> >> >>> > >> >> _______________________________________________ >> >>> > >> >> sipx-users mailing list >> >>> > >> >> sipx-users@list.sipfoundry.org >> >>> > >> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >>> > >> > >> >>> > >> > _______________________________________________ >> >>> > >> > sipx-users mailing list >> >>> > >> > sipx-users@list.sipfoundry.org >> >>> > >> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >>> > >> > >> >>> > >> _______________________________________________ >> >>> > >> sipx-users mailing list >> >>> > >> sipx-users@list.sipfoundry.org >> >>> > >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >>> > > >> >>> > > >> >>> > > >> >>> > > -- >> >>> > > ====================== >> >>> > > Tony Graziano, Manager >> >>> > > Telephone: 434.984.8430 >> >>> > > sip: tgrazi...@voice.myitdepartment.net >> >>> > > Fax: 434.465.6833 >> >>> > > >> >>> > > Email: tgrazi...@myitdepartment.net >> >>> > > >> >>> > > LAN/Telephony/Security and Control Systems Helpdesk: >> >>> > > Telephone: 434.984.8426 >> >>> > > sip: helpd...@voice.myitdepartment.net >> >>> > > >> >>> > > Helpdesk Contract Customers: >> >>> > > http://support.myitdepartment.net >> >>> > > Blog: >> >>> > > http://blog.myitdepartment.net >> >>> > > >> >>> > > Linked-In >> >>> > > Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >> >>> > > Ask about our Internet Fax services! >> >>> > > >> >>> > > _______________________________________________ >> >>> > > sipx-users mailing list >> >>> > > sipx-users@list.sipfoundry.org >> >>> > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >>> > > >> >>> > >> >>> > _______________________________________________ >> >>> > sipx-users mailing list >> >>> > sipx-users@list.sipfoundry.org >> >>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> >> _______________________________________________ >> >> sipx-users mailing list >> >> sipx-users@list.sipfoundry.org >> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> > >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: tgrazi...@voice.myitdepartment.net > Fax: 434.465.6833 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: helpd...@voice.myitdepartment.net > > Helpdesk Contract Customers: > http://support.myitdepartment.net > Blog: > http://blog.myitdepartment.net > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > Ask about our Internet Fax services! > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
