[Home]

Summary:ASTERISK-16553: T.38 Re-Invite - Asterisk Sends Call to Incoming Context of Extensions.conf
Reporter:James Kockler (jkockler)Labels:
Date Opened:2010-08-11 12:51:12Date Closed:2015-03-14 09:12:52
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) debug_console_output_1.txt
( 1) debug_messages_1_for_dig
( 2) extensions_4_dig.conf
( 3) IP_Address_Key
( 4) sip_4_dig.conf
( 5) t38_pcap_1_for_dig.pcap
( 6) verbose_console_output_at_failure_4_dig.txt
( 7) verbose_messages_1_for_dig
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.  
Comments:By: Leif Madsen (lmadsen) 2010-08-12 09:05:39

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

By: James Kockler (jkockler) 2010-08-12 09:09:46

Where in the reinvite are you seeing a forward request?  I see a reinvite to T.38 from the provider, and then asterisk goes to it's incoming call context.
By: James Kockler (jkockler) 2010-08-12 09:12:16

This also only happens when asterisk gets a T.38 reinvite from a sip cluster.  It works fine when getting a T.38 reinvite from an ATA, in the same exact dialplan, in the same exact context.


By: Leif Madsen (lmadsen) 2010-08-12 09:20:10

Oh ouch, there is no 302 Redirect going on here. This does seem mighty strange :)

Acknowledging issue.
By: James Kockler (jkockler) 2010-08-12 10:02:39

Thank you!!
By: Joshua C. Colp (jcolp) 2015-03-14 09:12:52.847-0500

This is a bug in the remote SIP stack. It is not permitted to start a new INVITE transaction while one is in progress. According to the provided log the initial INVITE was never answered, and thus that transaction never completed.