[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

[Jonathan Rose (JIRA)]

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

Jonathan Rose edited comment on ASTERISK-21150 at 9/9/13 12:45 PM:
-------------------------------------------------------------------

This patch has a bit of a flaw. If the SDP is being processed against a pvt that has already had the t38 state set to T38_ENABLED then once we reach the following line:

			if (error_correction_scheme_prior_offer_from_peer != ast_udptl_get_error_correction_scheme(p->udptl) && \
				UDPTL_ERROR_CORRECTION_NONE == error_correction_scheme_prior_offer_from_peer)

error_correction_scheme_prior_offer_from_peer will be used uninitialized which could cause this condition's evaluation to be a bit unpredictable.

Aside from that, I personally don't see anything wrong with what this patch is trying to accomplish. It seems sensible. But we need to work out whether or not it's appropriate to have a presumptive setting to initialize the error correction scheme variable with or else whether we should postpone the fetch until we have actually reached the point where it will be needed. (For instance, have a flag that gets raised by what is currently setting the error correction variable and then retrieve it before using it when that flag is raised). I'll wait a bit on this to see if you have an opinion on which would be more appropriate.
                
      was (Author: jrose):
    This patch has a bit of a flaw. If the SDP is being processed against a pvt that has already had the t38 state set to T38_ENABLED then once we reach the following line:

			if (error_correction_scheme_prior_offer_from_peer != ast_udptl_get_error_correction_scheme(p->udptl) && \
				UDPTL_ERROR_CORRECTION_NONE == error_correction_scheme_prior_offer_from_peer)

error_correction_scheme_prior_offer_from_peer will be used uninitialized which could cause this condition's evaluation to be a bit unpredictable.

Aside from that, I personally don't see anything wrong with what this patch is trying to accomplish. It seems sensible.
                  
> 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
>            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