Douglas Garstang
2006-Mar-28 08:29 UTC
[Asterisk-Users] NATted phones transferring calls - BUG0003710
I made a call from 3254102 to 2944093. I then tried to do a transfer to 3254107. IP addresses have been changed to protect the innocent. It appears this related to bug 3710. It's unclear from the bug if the problem has been fixed or not. If it hasn't, then this seems pretty serious and would I guess affect any NAT-ted phones ability to transfer calls. Here's the REFER that the phone at 2944093 sends directly to Asterisk: U 216.186.128.68:5060 -> 216.186.142.203:5060 REFER sip:3254102@216.186.142.203 SIP/2.0. Via: SIP/2.0/UDP 216.186.128.68;branch=z9hG4bKba3b074892377BD1. From: <sip:2944093@216.186.128.68>;tag=C06397B-C3C1D97A. To: "Test User" <sip:3254102@216.186.142.203>;tag=as33e7dd7c. CSeq: 2 REFER. Call-ID: 4053b9972e7851f455d9d16e7706d3f4@216.186.142.203. Contact: <sip:2944093@216.186.128.68>. User-Agent: PolycomSoundPointIP-SPIP_601-UA/1.6.3.0067. Refer-To: <sip:3254107@ipt.oneeighty.com;user=phone?Replaces=a13c692-349c9c70-7bd27d33%40172.31.99.4%3Bto-tag%3Das2a8d818b%3Bfrom-tag%3D3DE1A6BE-7262B959>. Referred-By: <sip:2944093@216.186.128.68>. Max-Forwards: 70. Content-Length: 0. Asterisk then goes and complains: Mar 27 16:25:57 NOTICE[20511]: chan_sip.c:6734 get_refer_info: Supervised transfer requested, but unable to find callid 'a13c692-349c9c70-7bd27d33@172.31.99.4'. Both legs must reside on Asterisk box to transfer at this time. The phone's real IP address is 172.31.99.4. I'm not really sure what the problem is except that it works fine when there's no NAT involved. I can see the real IP address in the dialog. I wonder if that's what is confusing Asterisk? Doug.
Alexander Lopez
2006-Mar-28 09:03 UTC
[Asterisk-Users] NATted phones transferring calls - BUG0003710
I wont go into the details of NATs and how they work, they are beyond the scope of this fourum,even though it is important that we understand NATs and their function as it pertains to Asterisk. If Asterisk is not in the media path and it CANNOT transfer the call if it is NATed. If you have canreinvite=yes, then the phone will set up the media path between them. If you are not using NAT then asterisk can redirect the call, but if you are using NAT in cannot. NAT + (canreinvite=yes) = Media path direct to the phones, transfers will not work. !NAT + (canreinvite=yes) = Media path direct to both phones, but since phones are on routable networks phones can transfer. NAT + (canreinvite=no) = Asterisk stays in the media path so transfers and all functions will work. !NAT + (canreinvite=no) = Asterisk stays in the media path so transfers and all functions will work, but will NOT allow use of NATed Devices. Hope this helps.> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com > [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of > Douglas Garstang > Sent: Tuesday, March 28, 2006 10:30 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: [Asterisk-Users] NATted phones transferring calls - > BUG0003710 > > I made a call from 3254102 to 2944093. I then tried to do a > transfer to 3254107. > IP addresses have been changed to protect the innocent. > > It appears this related to bug 3710. It's unclear from the > bug if the problem has been fixed or not. If it hasn't, then > this seems pretty serious and would I guess affect any > NAT-ted phones ability to transfer calls. > > Here's the REFER that the phone at 2944093 sends directly to Asterisk: > > U 216.186.128.68:5060 -> 216.186.142.203:5060 REFER > sip:3254102@216.186.142.203 SIP/2.0. > Via: SIP/2.0/UDP 216.186.128.68;branch=z9hG4bKba3b074892377BD1. > From: <sip:2944093@216.186.128.68>;tag=C06397B-C3C1D97A. > To: "Test User" <sip:3254102@216.186.142.203>;tag=as33e7dd7c. > CSeq: 2 REFER. > Call-ID: 4053b9972e7851f455d9d16e7706d3f4@216.186.142.203. > Contact: <sip:2944093@216.186.128.68>. > User-Agent: PolycomSoundPointIP-SPIP_601-UA/1.6.3.0067. > Refer-To: > <sip:3254107@ipt.oneeighty.com;user=phone?Replaces=a13c692-349 > c9c70-7bd27d33%40172.31.99.4%3Bto-tag%3Das2a8d818b%3Bfrom-tag% > 3D3DE1A6BE-7262B959>. > Referred-By: <sip:2944093@216.186.128.68>. > Max-Forwards: 70. > Content-Length: 0. > > Asterisk then goes and complains: > > Mar 27 16:25:57 NOTICE[20511]: chan_sip.c:6734 > get_refer_info: Supervised transfer requested, but unable to > find callid 'a13c692-349c9c70-7bd27d33@172.31.99.4'. Both > legs must reside on Asterisk box to transfer at this time. > > The phone's real IP address is 172.31.99.4. > I'm not really sure what the problem is except that it works > fine when there's no NAT involved. I can see the real IP > address in the dialog. I wonder if that's what is confusing Asterisk? > > Doug. > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
Douglas Garstang
2006-Mar-28 09:17 UTC
[Asterisk-Users] NATted phones transferring calls - BUG0003710
> -----Original Message----- > From: Alexander Lopez [mailto:Alex.Lopez@OpSys.com] > Sent: Tuesday, March 28, 2006 9:04 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: RE: [Asterisk-Users] NATted phones transferring calls - > BUG0003710 > > > I wont go into the details of NATs and how they work, they are beyond > the scope of this fourum,even though it is important that we > understand > NATs and their function as it pertains to Asterisk. > > If Asterisk is not in the media path and it CANNOT transfer > the call if > it is NATed. If you have canreinvite=yes, then the phone will > set up the > media path between them. If you are not using NAT then asterisk can > redirect the call, but if you are using NAT in cannot.Asterisk IS in the media path.> > NAT + (canreinvite=yes) = Media path direct to the phones, transfers > will not work. > !NAT + (canreinvite=yes) = Media path direct to both phones, but since > phones are on routable networks phones can transfer.Not doing that.> > NAT + (canreinvite=no) = Asterisk stays in the media path so transfers > and all functions will work. > !NAT + (canreinvite=no) = Asterisk stays in the media path so > transfers > and all functions will work, but will NOT allow use of NATed Devices.We have nat=rfc3581 against the user and canreinvite=no. Asterisk is in the call path, so by your definition this should work. It does not. If we remove NAT, it does work. It is therefore somehow related to NAT. I've seen at least one other person report this problem.