[asterisk-bugs] [Asterisk 0013976]: Invalid SDP attributes for boolean T.38 parameters (T38FaxFillBitRemoval, etc.)

Asterisk Bug Tracker noreply at bugs.digium.com
Mon Jan 5 11:10:05 CST 2009


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13976 
====================================================================== 
Reported By:                linulin
Assigned To:                svnbot
====================================================================== 
Project:                    Asterisk
Issue ID:                   13976
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 158959 
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-11-26 10:39 CST
Last Modified:              2009-01-05 11:10 CST
====================================================================== 
Summary:                    Invalid SDP attributes for boolean T.38 parameters
(T38FaxFillBitRemoval, etc.)
Description: 
SDP part with enabled T38FaxFillBitRemoval, T38FaxTranscodingMMR, and
T38FaxTranscodingJBIG parameters must look like:

  a=T38FaxFillBitRemoval
  a=T38FaxTranscodingMMR
  a=T38FaxTranscodingJBIG

instead of:

  a=T38FaxFillBitRemoval:1
  a=T38FaxTranscodingMMR:1
  a=T38FaxTranscodingJBIG:1

SDP part with disabled T38FaxFillBitRemoval, T38FaxTranscodingMMR, and
T38FaxTranscodingJBIG parameters must be empty instead of:

  a=T38FaxFillBitRemoval:0
  a=T38FaxTranscodingMMR:0
  a=T38FaxTranscodingJBIG:0

Otherwise interoperability issues with other T.38 implementations are
likely to arise.

Quoting ITU-T Recommendation T.38:

Section “D.2.3.1 UDPTL and TCP negotiation”:

“Note that options without values are boolean – their presence
indicates that they are valid for the session.”

Section “D.2.3.2 RTP negotiation”:

Those parameters are supplied in a semi-colon separated list of
“parameter” or “parameter=value” pairs using the “a=fmtp”
parameter defined in SDP; the “parameter” form is used for boolean
values, where presence equals “true” and absence “false”.

====================================================================== 

---------------------------------------------------------------------- 
 (0097046) svnbot (reporter) - 2009-01-05 11:10
 http://bugs.digium.com/view.php?id=13976#c97046 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 167182

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r167182 | mmichelson | 2009-01-05 11:10:04 -0600 (Mon, 05 Jan 2009) | 57
lines

Merged revisions 167180 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
r167180 | mmichelson | 2009-01-05 10:59:36 -0600 (Mon, 05 Jan 2009) | 49
lines

Merged revisions 167179 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r167179 | mmichelson | 2009-01-05 10:51:59 -0600 (Mon, 05 Jan 2009) | 41
lines

A couple of changes to T.38 SDP attribute handling

There are some boolean attributes for T.38 such
as T38FaxFillBitRemoval, T38FaxTranscodingMMR, and
T38FaxTranscodingJBIG. By simply being present, we
should treat these as a "true" value. The current
code, however, was requiring a 1 or 0 as the value
of the attribute in order to parse it. This is due
to the fact that there are some T.38 endpoints and
gateways that also transmit this information
incorrectly. This patch follows the "be liberal in
what you accept and strict in what you send"
philosophy by accepting both the correctly- and 
incorrectly-formatted attributes, but only sending
information as it is supposed to be sent.

It was also discovered that a particular type of 
T.38 gateway sends some non-standard T.38 SDP
attributes. Instead of using T38FaxMaxDatagram
and T38MaxBitRate, it used T38MaxDatagram and
T38FaxMaxRate respectively. We now will properly
accept these attributes as well.

Note that there are a lot of patches cited in
the below commit message template. This is
because the person who submitted these patches is
an awesome person and wrote 1.4, 1.6.0, and 1.6.1
variants.

(closes issue http://bugs.digium.com/view.php?id=13976)
Reported by: linulin
Patches:
     chan_sip.c.1.4-update1.diff uploaded by arcivanov (license 648)
	 chan_sip.c.1.6.0-update1.diff uploaded by arcivanov (license 648)
	 chan_sip.c.1.6.1-update1.diff uploaded by arcivanov (license 648)
	 chan_sip.c.1.4-relaxedT38_update1.diff uploaded by arcivanov (license
648)
	 chan_sip.c.1.6.0-relaxedT38_update1.diff uploaded by arcivanov (license
648)
	 chan_sip.c.1.6.1-relaxedT38_update1.diff uploaded by arcivanov (license
648)
Tested by: arcivanov


........

................

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-05 11:10 svnbot         Note Added: 0097046                          
======================================================================




More information about the asterisk-bugs mailing list