[Home]

Summary:ASTERISK-15597: 1.4 does not send any SIP messages after the "100 Trying" to the T.38 INVITE requesting side
Reporter:Kristijan Vrban (vrban)Labels:
Date Opened:2010-02-09 11:07:37.000-0600Date Closed:2010-06-01 09:54:07
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip_trace.txt
Description:
Asterisk 1.4 does not send any SIP messages after the "100 Trying" to the T.38 INVITE requesting side. chan_sip talk to the B-side, where itself send out the T.38 re-INVITE, but does not send anything to the originating A-side.

"sip show channels" show this dead A side channels which never get closed:

111.222.111.222  0123456789  69570b5c142b447  0x0 (nothing)    No       Tx: INVITE
111.222.111.222  0123456789  03f0bc4832e47e8  0x0 (nothing)    No       Tx: INVITE
111.222.111.222  0123456789  10a623dc4650f90  0x0 (nothing)    No       Tx: INVITE
111.222.111.222  0123456789  5636aa6171efef3  0x0 (nothing)    No       Tx: INVITE
111.222.111.222  0123456789  5877536469f446e  0x0 (nothing)    No       Tx: INVITE
111.222.111.222  0123456789  3a83a6480cf7eed  0x0 (nothing)    No       Tx: INVITE
111.222.111.222  0123456789  664d8ac26547274  0x0 (nothing)    No       Tx: INVITE
111.222.111.222  0123456789  38bb8ada68b44ae  0x0 (nothing)    No       Tx: INVITE

With 1.6 and trunk chan_sip is talking to A-side.

In the attached sip trace, you see the only answer to C.C.C.C is only the 100 Trying, then nothing.
Comments:By: Kristijan Vrban (vrban) 2010-02-10 06:22:26.000-0600

ok, this was done with changeset 183108

Can someone backport this small one liner patch to 1.4 ;-)

And based on changeset 103799...


By: Leif Madsen (lmadsen) 2010-02-10 15:00:41.000-0600

Marking as Confirmed until a developer can look at this an determine if this should go into 1.4 (I have no reason why it shouldn't, just saying :))
By: Kristijan Vrban (vrban) 2010-02-11 05:33:59.000-0600

I think it's much easier to extend the sip_handle_t38_reinvite in 1.4 chan_sip
that it handel also 488 for outgoing T.38 re-INVITE, and forward the 488 to the originating T.38 re-INVITE party.

To test this, i just harcoded a:
transmit_response_reliable(p, "488 Not acceptable here", &p->initreq);
into sip_handle_t38_reinvite and a bit more also in handle_response_invite, where the 488 case is. then chan_sip can handle also the T.38 to audio fallback.

Is this the correct way to handel this? Then i try to make a clean patch of it.


By: Leif Madsen (lmadsen) 2010-02-22 16:01:03.000-0600

I'd think about asking this question on the asterisk-dev mailing list so you can get more exposure to your question.
By: Digium Subversion (svnbot) 2010-06-01 09:54:05

Repository: asterisk
Revision: 266579

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r266579 | pabelanger | 2010-06-01 09:54:05 -0500 (Tue, 01 Jun 2010) | 18 lines

Missing fallback to audio fax feature when T.38 re-INVITE failed

When a T.38 re-INVITE failed with an 488 or 606 answer, we should
fallback to audio fax by send a re-re-INVITE without T.38. The
function is backported from 1.6 asterisk.

(closes issue ASTERISK-15597)
Reported by: vrban

(closes issue ASTERISK-15508)
Reported by: vrban
Patches:
     t38_fallback_to_audio_v3.patch uploaded by vrban (license 756)
Tested by: lmadsen, vrban, haggard

https://reviewboard.asterisk.org/r/514/


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

http://svn.digium.com/view/asterisk?view=rev&revision=266579