asterisk users - Mar 2006 - 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.

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
>

> -----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.