[asterisk-bugs] [JIRA] (ASTERISK-21150) UDPTL Error Correction Scheme Negotiation Issue, Asterisk copies the Error Correction Scheme from T38 offer from remote peer even if UDPTL error correction scheme is set to NONE for that peer in sip.conf

[Mark Michelson (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210136#comment-210136 ] 

Mark Michelson commented on ASTERISK-21150:
-------------------------------------------

I just had a look at the patch on reviewboard, and thought I'd comment here.

My initial thoughts on the matter were pretty much exactly the same as Matt's that he made back in February.

1) My interpretation of the sip.conf option is that you are configuring what Asterisk believes the peer capabilities are. This means that if we are offering T.38 to the peer, then that is the error correction we should use. For incoming T.38 reinvites, just go with the error correction that was offered, as it's less likely to cause issues with the peer. This would be in agreement with the snippet of T.38 you pasted in the description. This is because Asterisk is the answering endpoint in this scenario and Asterisk supports all three error correction schemes. Since Asterisk supports the offered scheme, then it should answer with the offered scheme.

2) If my interpretation of 1) is not correct, then I think that it is arbitrary to only apply this logic for "none" and not other error correction options. I read your explanation, but I'm not buying it. It makes the configuration setting much more difficult to explain by having the value sometimes overrule what the incoming reinvite offers and sometimes not.

One thing that has not been mentioned anywhere in this issue is what actual real-world problems have been encountered because of Asterisk's current behavior. If the problem is strictly hypothetical, I don't think the current behavior should be changed. If there have been interoperability issues, then that's a different story. My expectation would be Asterisk would interoperate much *better* with the current behavior since Asterisk is responding with an error correction scheme that is known to be supported since the scheme was offered in the inbound reinvite.
                
> UDPTL Error Correction Scheme Negotiation Issue, Asterisk copies the Error Correction Scheme from T38 offer from remote peer even if UDPTL error correction scheme is set to NONE for that peer in sip.conf
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21150
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21150
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/T.38
>    Affects Versions: 11.4.0
>         Environment: x86_64 Debian Squeeze Distro
>            Reporter: NITESH BANSAL
>            Assignee: Jonathan Rose
>            Severity: Minor
>         Attachments: do-not-use-ec-from-offer-if-configured-ec-is-none.patch
>
>
> Scenario: Asterisk receives a T38 invite which proposes some error correction scheme, Asterisk copies the error correction scheme from the offer and puts it in 200 OK. This behaviour does not change even if UDPTL error correction scheme is set to NONE for this peer.
> Expected Output: Asterisk should respond with no error correction scheme if this peer has t38_udptl error correction scheme set to NONE.
> Below is the reference from T38 spec:
> """"T38FaxUdpEC is negotiated only when using UDPTL as the transport. This parameter can have
> one of three values (see also Table D.2): t38UDPNoEC, t38UDPRedundancy, or t38UDPFEC. If
> the answering endpoint supports the offered error correction mode, then it shall return the same
> value in the answer, otherwise a different value shall be returned""""

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira