[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

[Matt Jordan (JIRA)]

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

Matt Jordan edited comment on ASTERISK-21150 at 2/27/13 4:34 PM:
-----------------------------------------------------------------

Nitesh - why wouldn't we want to do something like the following for any error correction scheme:

* If the inbound INVITE request's error correction scheme matches the configuration option, simply put the value in the 200 OK and carry on
* If the inbound INVITE request's error correction scheme does not match, issue a WARNING or a NOTICE and respond with the configured value

I'm not sure why we'd want to only do this for NONE and not for all of the various values.

On the same vein, I have a feeling that we use the configuration value for outbound requests but never really intended to use it as a way to sanitize inbound requests. This may have some nasty repercussions from people who expected us to just echo whatever the endpoint told us. What is the drawback for being permissive and echoing what the endpoint wants?
                
      was (Author: mjordan):
    Nitesh - why wouldn't we want to do something like the following for any error correction scheme:

* If the inbound INVITE request's error correction scheme matches the configuration option, simply put the value in the 200 OK and carry on
* If the inbound INVITE request's error correction scheme does not match, issue a WARNING or a NOTICE and respond with the configured value

I'm not sure why we'd want to only do this for NONE and not for all of the various values.
                  
> 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: SVN
>         Environment: x86_64 Debian Squeeze Distro
>            Reporter: NITESH BANSAL
>            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
For more information on JIRA, see: http://www.atlassian.com/software/jira