[Home]

Summary:ASTERISK-08300: T.38 negotiation fails when h263 is enabled
Reporter:ivoc (ivoc)Labels:
Date Opened:2006-12-07 02:59:55.000-0600Date Closed:2007-01-24 12:06:34.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) h263_no_path_to_translate_r48326.txt
( 1) h263_no_path_to_translate_r51360.txt
Description:If h263 video codec is enabled in sip.conf, when re-INVITE is sent to do T.38 switch-over, asterisk tries to do codec translation from h263 to slin and afterwards a BYE message is sent out and T.38 call is not set up successfully.

Appropriate debug is attached as h263_no_path_to_translate_r48326.txt



****** ADDITIONAL INFORMATION ******

channel.c:2702 set_format: Unable to find a codec translation path from h263 to slin
.....
channel.c:3033 ast_channel_make_compatible: No path to translate from SIP/mydomain.tld-093ba1c8(256) to SIP/ser-093cfc38(524288)
Comments:By: Serge Vecher (serge-v) 2006-12-07 10:49:32.000-0600

I think this is related to 7593 --> we do not have a compatible audio codec, but the call should proceed nevertheless in t.38 mode.

By: ivoc (ivoc) 2006-12-11 03:26:49.000-0600

Not quite, because issue 7593 is related to INITIAL T.38 INVITE, and here we are talking about re-INVITE, the call has been already connected.
Also when h263 is disabled in sip.conf the call proceed just fine, there are NO audio codec capabilities present:

chan_sip.c:5059 process_sdp: ... Capabilities: us - 0x108 (alaw|g729), peer - audio=0x0 (nothing)/video=0x0 (nothing), combined - 0x0 (nothing)
chan_sip.c:5101 process_sdp: Have T.38 but no audio codecs, accepting offer anyway

By: Joshua C. Colp (jcolp) 2007-01-22 21:02:27.000-0600

Fixed in 1.4 as of revision 51558 and trunk as of revision 51559.

By: ivoc (ivoc) 2007-01-24 03:31:00.000-0600

Still the same behaviour, tested w/ revision 51360.

Will upload h263_no_path_to_translate_r51360.txt

By: Joshua C. Colp (jcolp) 2007-01-24 12:06:34.000-0600

Really fixed in 1.4 as of revision 52016 and trunk as of revision 52025. We are having SVN issues right now though so you might not get the latest revision. We're working on it.