So are you saying the call type is "hairpinned"? In via ITSP and then out via ITSP via transfer?
On Fri, Oct 28, 2011 at 10:43 AM, Adrien Guillon <aj.guil...@gmail.com>wrote: > 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/ > -- ====================== 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 <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/
