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

[Vinícius Fontes]

----- "Steve Underwood" <steveu at coppice.org> escreveu:

> On 02/02/2010 10:11 PM, Kevin P. Fleming wrote:
> > 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'.
> >    
> That's how T.38 calls normally start. They mostly start as audio, and
> 
> switch into T.38 mode later. We have only seen an initial fragment in
> 
> the log. We haven't seen anything that's actually wrong. We see an
> offer 
> to do telephony events, and from there things might progress to T.38
> or 
> something else. I can't see anything invalid in that, even if the 
> cdsc/cpar stuff is not understood.
> 
> Steve

I couldn't agree more Steve.

Is there any other info I could provide in order to help you find out what's wrong? I could even open an issue on Mantis if the Digium staff think it's worth it.