[asterisk-bugs] [Asterisk 0017842]: T.38 Re-Invite - Asterisk Sends Call to Incoming Context of Extensions.conf

[Asterisk Bug Tracker]

The following issue requires your FEEDBACK. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17842 
====================================================================== 
Reported By:                jkockler
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17842
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.2.10 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-08-11 12:51 CDT
Last Modified:              2010-08-12 09:05 CDT
====================================================================== 
Summary:                    T.38 Re-Invite - Asterisk Sends Call to Incoming
Context of Extensions.conf
Description: 
Asterisk Version 1.6.2.10
Centos V.5.3 x86

When Asterisk receives T.38 Re-Invite from provider, it attempts to route
the call into the incoming context of extensions.conf, looking for the
caller id of the registered SIP UA involved in the call.  There is nothing
in the dialplan which would indicate it should do this.  
====================================================================== 

---------------------------------------------------------------------- 
 (0125885) lmadsen (administrator) - 2010-08-12 09:05
 https://issues.asterisk.org/view.php?id=17842#c125885 
---------------------------------------------------------------------- 
I think this is doing what it should.

The incoming_calls context is the default context defined in sip.conf, and
it's likely using that because there is a forward request which can't be
matched to a particular peer, and thus it's defaulting to finding the
location via the default context (as defined in sip.conf in [general]).

I think you could possibly modify the dialplan to use these variables to
control how the forwarding is handled:

${TRANSFER_CONTEXT}      Context for transferred calls
${FORWARD_CONTEXT}       Context for forwarded calls
 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-12 09:05 lmadsen        Note Added: 0125885                          
2010-08-12 09:05 lmadsen        Status                   new => feedback     
======================================================================