[asterisk-bugs] [Asterisk 0011228]: While working on T38 terminal support for asterisk

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11228 
====================================================================== 
Reported By:                Cache
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   11228
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 89214 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-13-2007 03:48 CST
Last Modified:              11-15-2007 08:23 CST
====================================================================== 
Summary:                    While working on T38 terminal support for asterisk
Description: 
While working on T38 terminal support for asterisk I discovered I can not
properly talk to Calweaver via UDPTL. It was strange because it seem like
their UDPTL implementation have common roots. I found that for some reason
two lines of udptl.c are commented out causing the problem. Attached patch
fixes the issue
====================================================================== 

---------------------------------------------------------------------- 
 dimas - 11-15-07 08:23  
---------------------------------------------------------------------- 
Sorry, more fixes :)
1. udptl_rx_packet could return success even if it did not retrieved any
IFP (because it already seen that seqno)
2. udptl_read did not check return value of udptl_rx_packet so even if
there were parse error, udptl_read considers everything is ok

Due to these issues, udptl_read was generating strange frames with
frametype=0, subclass=0. Patch makes it generate null_frame in these
cases.

(udptl-4.patch also includes all previous patches) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-15-07 08:23  dimas          Note Added: 0073709                          
======================================================================