[asterisk-bugs] [JIRA] (ASTERISK-20897) case sensitive match against T.38 params causes T38MaxBitRate to be negotiated at 2400 baud instead of 14400

[Digium Subversion (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-20897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Digium Subversion closed ASTERISK-20897.
----------------------------------------

    Resolution: Fixed
    
> case sensitive match against T.38 params causes T38MaxBitRate to be negotiated at 2400 baud instead of 14400
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20897
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20897
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/T.38
>    Affects Versions: 11.1.2
>         Environment: Linux x86/64, however unimportant to the issue.
>            Reporter: Eric Hill
>            Assignee: Matt Jordan
>         Attachments: ASTERISK-20837-1.8.diff
>
>
> This problem started as an interoperability report with Level 3 communications T.38 fax service and an XMedius fax server with Asterisk handling the call supervision.  Faxes were being negotiated at 2400 baud rather than 14400 baud.  During testing, the XMedius fax server would indicate a=T38maxBitRate:14400, however Asterisk would relay a=T38MaxBitRate:2400 to Level 3.
> I traced the problem to chan_sip line 11138:
>     ...sscanf(a, "T38MaxBitRate:%30u"...
> sscanf is case sensitive with static strings, and as such, "T38MaxBitRate" does not match the offered "T38maxBitRate" from XMedius, and as such doesn't parse the 14400 into the rate field in the structure.  The structure baudrate is defaulted to the lowest value (2400), so the lower speed is offered to Level 3.
> RFC5347 section 2.5.2 includes this statement:
>    ...
>    The attribute "T38MaxBitRate" was once incorrectly registered with
>    IANA as "T38maxBitRate" (lower-case "m").  In accordance with T.38
>    examples and common implementation practice, the form "T38MaxBitRate"
>    SHOULD be generated by implementations conforming to this package.
>    In general, it is RECOMMENDED that implementations of this package
>    accept lowercase, uppercase, and mixed upper/lowercase encodings of
>    all the T.38 attributes.
>    ...
> Asterisk would be better compatible with other T.38 systems by implementing a case-insensitive match against T.38 parameters since the specification was incorrectly registered in past times.  By being case-sensitive, asterisk is compatible only at the slowest 2400 baud with equipment using the incorrect T38maxBitRate name.
> I have created this issue at Major since no workaround is possible without a code change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira