[asterisk-bugs] [Asterisk 0013976]: Invalid SDP attributes for boolean T.38 parameters (T38FaxFillBitRemoval, etc.)
Asterisk Bug Tracker
noreply at bugs.digium.com
Sat Dec 20 21:14:03 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13976
======================================================================
Reported By: linulin
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 13976
Category: Channels/chan_sip/T.38
Reproducibility: always
Severity: minor
Priority: normal
Status: new
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:
======================================================================
Date Submitted: 2008-11-26 10:39 CST
Last Modified: 2008-12-20 21:14 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”.
======================================================================
----------------------------------------------------------------------
(0096755) arcivanov (reporter) - 2008-12-20 21:14
http://bugs.digium.com/view.php?id=13976#c96755
----------------------------------------------------------------------
Since we're on the subject of standards compliance. Below please find the
excerpt from T.38 negotiation between Gafachi <=> NAT <=> Asterisk <=>
Grandstream 286v3:
=====================================================
INVITE sip:fax1 SIP/2.0
User-Agent: Grandstream HT287 1.1.0.30
v=0
o=fax1 8000 8001 IN IP4 iphidden
s=SIP Call
c=IN IP4 iphidden
t=0 0
m=image 60200 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:280
a=T38FaxUdpEC:t38UDPRedundancy
INVITE sip:asterisk-proxy SIP/2.0
User-Agent: Asterisk PBX
v=0
o=root 16579 16580 IN IP4 iphidden
s=session
c=IN IP4 iphidden
t=0 0
m=image 60198 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:280
a=T38FaxMaxDatagram:280
a=T38FaxUdpEC:t38UDPRedundancy
SIP/2.0 200 OK
Server: Gafachi UAS v110.08
v=0
o=root 278153574 278153575 IN IP4 iphidden
s=session
c=IN IP4 iphidden
t=0 0
m=image 46570 udptl t38
a=T38FaxVersion:0
a=T38FaxRateManagement:transferredTCFlocalTCF
a=T38FaxUdpEC:t38UDPFEC
a=T38FaxMaxBufferSize:2000
a=T38MaxDatagram:512
a=T38FaxMaxRate:14400
=====================================================
Notice that when Grandstream and Asterisk use T38FaxMaxDatagram and
T38MaxBitRate, Gafachi UAS uses T38MaxDatagram and T38FaxMaxRate
respectively.
Gafachi UAS is in violation of T.38 04/2004. In Gafachi's defense T.38
Rec. contains INCORRECT parameters, but only in examples (no where in
actual BNF).
I'm going to add patches to make sure we understand and answer with both
compliant and non-compliant parameters. Stay tuned.
Issue History
Date Modified Username Field Change
======================================================================
2008-12-20 21:14 arcivanov Note Added: 0096755
======================================================================
More information about the asterisk-bugs
mailing list