[asterisk-users] Asterisk 1.6.1.13 and T.38 faxing

[Kevin P. Fleming]

Steve Underwood wrote:
> Hi Kevin,
> 
> On 02/02/2010 09:12 PM, Kevin P. Fleming wrote:
>> Vinícius Fontes wrote:
>>
>>    
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP v=0... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP o=PVG 1265107000170 1265107000170 IN IP4 10.152.0.164... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP s=-... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP p=+1 6135555555... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP c=IN IP4 10.152.0.164... OK.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP t=0 0... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP a=sqn: 0... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP a=cdsc: 1 image udptl t38... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP a=cpar: a=T38FaxVersion:0... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: Processing session-level SDP a=cpar: a=T38FaxUdpEC:t38UDPRedundancy... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7753 process_sdp: Processing media-level (audio) SDP a=rtpmap:101 telephone-event/8000... OK.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7753 process_sdp: Processing media-level (audio) SDP a=fmtp:101 0-15... UNSUPPORTED.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7753 process_sdp: Processing media-level (audio) SDP a=ptime:20... OK.
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:4653 change_t38_state: T38 state changed to 0 on channel SIP/voxip-00000000
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7932 process_sdp: We're settling with these formats: 0x8 (alaw)
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:7937 process_sdp: We have an owner, now see if we need to change this call
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:5231 update_call_counter: Updating call counter for incoming call
>>> [Feb  2 08:38:06] DEBUG[21032]: chan_sip.c:3172 __sip_xmit: Trying to put 'ACK sip:10.' onto UDP socket destined for 10.150.65.16:5060
>>> [Feb  2 08:38:06] DEBUG[21064]: app_fax.c:699 transmit_t38: Shut down T.38 on SIP/voxip-00000000
>>>
>>>
>>> Note how items like T38FaxUdpEC are listed as OK on one call and unsupported on another one. Could that be a bug? I can show the entire SIP conversations if that's necessary for debugging this.
>>>      
>> That's not quite correct; in the second example, the T38 parameters are
>> being sent as 'capabilities' (a=cdsc and a=cpar) which Asterisk does not
>> support. The second example does not provide backwards compatibility for
>> SIP endpoints that do not support capability-based negotiation, whereas
>> the first one does.
>>    
> What do you mean by that? Surely if you don't understand the cdsc and 
> cpar lines you are supposed to simply ignore them, and carry on.
> 
> If it were harmless, that capability information seems enormously 
> useful, especially in the context of the current discussions on sorting 
> out the mess that T.38 has become. Sadly, it does cause some systems to 
> choke, which is probably why it is rarely included.

In this case, the re-INVITE did *not* include a non-capabilities-based
offer for T.38. The SDP parser listed the cdsc and cpar lines as
unsupported, but it did not see any media stream offer for T.38 (unlike
the OP's first example), so it set the internal T.38 state on the
channel to 'not in use'.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org