If I understand what "hairpinned" calls are, no.

I called from the PTSN via ITSP to my AA on SipX.  I dialed an
internal # via ITSP.  SipX should transfer me to a call inside, not to
an external number back through the ITSP (if that is what you mean?).
Then call is dropped.  The extension dialed is associated with a user,
associated with a Polycom phone on site with the SIpX instance.

AJ

On Fri, Oct 28, 2011 at 11:41 AM, Tony Graziano
<[email protected]> wrote:
> 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 <[email protected]>
> 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
>> <[email protected]> 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 <[email protected]>
>> > 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 <[email protected]>
>> >> 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
>> >> > <[email protected]> wrote:
>> >> >> what kind of firewall is this?
>> >> >>
>> >> >> On Oct 26, 2011 6:50 PM, "Tony Graziano"
>> >> >> <[email protected]>
>> >> >> wrote:
>> >> >>>
>> >> >>> On Oct 26, 2011 6:21 PM, "Adrien Guillon" <[email protected]>
>> >> >>> 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
>> >> >>> > <[email protected]> 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
>> >> >>> > > <[email protected]>
>> >> >>> > > 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
>> >> >>> > >> <[email protected]> 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)"
>> >> >>> > >> > <[email protected]>
>> >> >>> > >> > 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
>> >> >>> > >> >> > [email protected]
>> >> >>> > >> >> > List Archive:
>> >> >>> > >> >> > http://list.sipfoundry.org/archive/sipx-users/
>> >> >>> > >> >> >
>> >> >>> > >> >>
>> >> >>> > >> >> _______________________________________________
>> >> >>> > >> >> sipx-users mailing list
>> >> >>> > >> >> [email protected]
>> >> >>> > >> >> List Archive:
>> >> >>> > >> >> http://list.sipfoundry.org/archive/sipx-users/
>> >> >>> > >> >
>> >> >>> > >> > _______________________________________________
>> >> >>> > >> > sipx-users mailing list
>> >> >>> > >> > [email protected]
>> >> >>> > >> > List Archive: http://list.sipfoundry.org/archive/sipx-users/
>> >> >>> > >> >
>> >> >>> > >> _______________________________________________
>> >> >>> > >> sipx-users mailing list
>> >> >>> > >> [email protected]
>> >> >>> > >> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>> >> >>> > >
>> >> >>> > >
>> >> >>> > >
>> >> >>> > > --
>> >> >>> > > ======================
>> >> >>> > > Tony Graziano, Manager
>> >> >>> > > Telephone: 434.984.8430
>> >> >>> > > sip: [email protected]
>> >> >>> > > Fax: 434.465.6833
>> >> >>> > >
>> >> >>> > > Email: [email protected]
>> >> >>> > >
>> >> >>> > > LAN/Telephony/Security and Control Systems Helpdesk:
>> >> >>> > > Telephone: 434.984.8426
>> >> >>> > > sip: [email protected]
>> >> >>> > >
>> >> >>> > > 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
>> >> >>> > > [email protected]
>> >> >>> > > List Archive: http://list.sipfoundry.org/archive/sipx-users/
>> >> >>> > >
>> >> >>> >
>> >> >>> > _______________________________________________
>> >> >>> > sipx-users mailing list
>> >> >>> > [email protected]
>> >> >>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/
>> >> >>
>> >> >> _______________________________________________
>> >> >> sipx-users mailing list
>> >> >> [email protected]
>> >> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>> >> >>
>> >> >
>> >> _______________________________________________
>> >> sipx-users mailing list
>> >> [email protected]
>> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>> >
>> >
>> >
>> > --
>> > ======================
>> > Tony Graziano, Manager
>> > Telephone: 434.984.8430
>> > sip: [email protected]
>> > Fax: 434.465.6833
>> >
>> > Email: [email protected]
>> >
>> > LAN/Telephony/Security and Control Systems Helpdesk:
>> > Telephone: 434.984.8426
>> > sip: [email protected]
>> >
>> > 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
>> > [email protected]
>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/
>> >
>> _______________________________________________
>> sipx-users mailing list
>> [email protected]
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> --
> ======================
> Tony Graziano, Manager
> Telephone: 434.984.8430
> sip: [email protected]
> Fax: 434.465.6833
>
> Email: [email protected]
>
> LAN/Telephony/Security and Control Systems Helpdesk:
> Telephone: 434.984.8426
> sip: [email protected]
>
> 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
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to