[Home]

Summary:ASTERISK-13715: "SIP/2.0 404 Not found" when attended transferring a private number
Reporter:Sverre G (sverre)Labels:
Date Opened:2009-03-09 02:11:02Date Closed:2009-03-11 12:32:28
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 14628.diff
( 1) console-broken.txt
( 2) console-working.txt
Description:When a private incoming call arrives on Extension A as a private number, the SIP Invite comes with "From: anonymous <sip:None@203.176.185.10>;tag=7c2dc3edeb530f73cd3bd6ae102a3d6b".

That call is placed on hold, and a new channel is opened between A->B. When the attended transfer REFER command comes through, the following error shows up in sip debug: "Failed SIP Transfer to non-existing extension None in context phones", followed by Asterisk sending a SIP/2.0 404 Not found to channel A.

The strange thing is that when the call ISN'T a private number, causing the call to SIP invite to come with "From: <sip:97891942@203.176.185.10>;tag=3c51826fb722e9d8fa4ee14f0e8d2bf4", the SIP transfer is fine, "SIP transfer to extension 97891942@phones by 100001102@192.168.0.21"

I tried adding an i extension to the phones context in the hope of catching the None entry, but no luck.

While this was discovered in 1.4.22, it's present in SVN revision 180682, and still applies after applying the patch found in bug http://bugs.digium.com/view.php?id=14611

I've attached two console outputs with sip debug on, one version that doesn't work with a private number, and one working with a normal CLID.
Comments:By: Joshua C. Colp (jcolp) 2009-03-09 12:14:15

Please try the attached patch. It is against the latest 1.4 from SVN.
By: Sverre G (sverre) 2009-03-10 21:58:24

Patch worked perfectly on latest SVN as well as 1.4.22. I imagine it works on most reasonably recent versions.

Two things:

1. I'm in awe that I reported a bug and it got fixed THE NEXT DAY, you guys are amazing!

2. How is it that I'm the first person to discover it? Attended transfer from a private number must happen all the time. Or is the line of code you just patched a very recent addition?
By: Digium Subversion (svnbot) 2009-03-11 12:22:53

Repository: asterisk
Revision: 181328

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r181328 | file | 2009-03-11 12:22:53 -0500 (Wed, 11 Mar 2009) | 14 lines

Fix issue where an attended transfer could not be completed under a rare scenario.

When completing an attended transfer chan_sip does a check to make sure the extension
in the URI portion of the Refer-To header is a local valid extension. We don't actually
need to check this since we know for sure the other channel is already up and talking to
the extension. Some devices do not put the extension in the Refer-To header either, which
can cause the extension check to fail. We now no longer do this check if it is an attended
transfer.

(closes issue ASTERISK-13715)
Reported by: sverre
Patches:
     14628.diff uploaded by file (license 11)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=181328
By: Digium Subversion (svnbot) 2009-03-11 12:26:41

Repository: asterisk
Revision: 181345

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r181345 | file | 2009-03-11 12:26:41 -0500 (Wed, 11 Mar 2009) | 21 lines

Merged revisions 181328 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r181328 | file | 2009-03-11 14:22:52 -0300 (Wed, 11 Mar 2009) | 14 lines
 
 Fix issue where an attended transfer could not be completed under a rare scenario.
 
 When completing an attended transfer chan_sip does a check to make sure the extension
 in the URI portion of the Refer-To header is a local valid extension. We don't actually
 need to check this since we know for sure the other channel is already up and talking to
 the extension. Some devices do not put the extension in the Refer-To header either, which
 can cause the extension check to fail. We now no longer do this check if it is an attended
 transfer.
 
 (closes issue ASTERISK-13715)
 Reported by: sverre
 Patches:
       14628.diff uploaded by file (license 11)
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=181345
By: Digium Subversion (svnbot) 2009-03-11 12:28:13

Repository: asterisk
Revision: 181352

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r181352 | file | 2009-03-11 12:28:13 -0500 (Wed, 11 Mar 2009) | 28 lines

Merged revisions 181345 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r181345 | file | 2009-03-11 14:26:40 -0300 (Wed, 11 Mar 2009) | 21 lines
 
 Merged revisions 181328 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r181328 | file | 2009-03-11 14:22:52 -0300 (Wed, 11 Mar 2009) | 14 lines
   
   Fix issue where an attended transfer could not be completed under a rare scenario.
   
   When completing an attended transfer chan_sip does a check to make sure the extension
   in the URI portion of the Refer-To header is a local valid extension. We don't actually
   need to check this since we know for sure the other channel is already up and talking to
   the extension. Some devices do not put the extension in the Refer-To header either, which
   can cause the extension check to fail. We now no longer do this check if it is an attended
   transfer.
   
   (closes issue ASTERISK-13715)
   Reported by: sverre
   Patches:
         14628.diff uploaded by file (license 11)
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=181352
By: Digium Subversion (svnbot) 2009-03-11 12:29:46

Repository: asterisk
Revision: 181359

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r181359 | file | 2009-03-11 12:29:45 -0500 (Wed, 11 Mar 2009) | 28 lines

Merged revisions 181345 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r181345 | file | 2009-03-11 14:26:40 -0300 (Wed, 11 Mar 2009) | 21 lines
 
 Merged revisions 181328 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r181328 | file | 2009-03-11 14:22:52 -0300 (Wed, 11 Mar 2009) | 14 lines
   
   Fix issue where an attended transfer could not be completed under a rare scenario.
   
   When completing an attended transfer chan_sip does a check to make sure the extension
   in the URI portion of the Refer-To header is a local valid extension. We don't actually
   need to check this since we know for sure the other channel is already up and talking to
   the extension. Some devices do not put the extension in the Refer-To header either, which
   can cause the extension check to fail. We now no longer do this check if it is an attended
   transfer.
   
   (closes issue ASTERISK-13715)
   Reported by: sverre
   Patches:
         14628.diff uploaded by file (license 11)
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=181359
By: Joshua C. Colp (jcolp) 2009-03-11 12:32:28

To answer your question your device is actually sending the wrong thing in the Refer-To header. It should be sending the extension it is being transferred to. It just doesn't make sense in our instance to not accept it anyway, so that is what I changed.