[asterisk-bugs] [JIRA] (ASTERISK-24928) t38_udptl_maxdatagram in pjsip.conf not honored
Juergen Spies (JIRA)
noreply at issues.asterisk.org
Tue Mar 31 13:00:32 CDT 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-24928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Juergen Spies updated ASTERISK-24928:
-------------------------------------
Attachment: pjsipT38patch20150331.txt
Proposed patch to this issue
> t38_udptl_maxdatagram in pjsip.conf not honored
> -----------------------------------------------
>
> Key: ASTERISK-24928
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-24928
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_pjsip_t38
> Affects Versions: 13.2.0
> Environment: CentOS 7, Pure VoIP
> Reporter: Juergen Spies
> Severity: Minor
> Attachments: pjsipT38patch20150331.txt
>
>
> When in pjsip.conf for an endpoint „t38_udptl_maxdatagram” is set it will not be used to initialize the udptl structure in “t38_initialize_session”. “far_max_datagram” will be only set from the SIP INVITE SDP MediaAttribute T38FaxMaxDatagram from the remote endpoint.
> The bug was discovered as our ISP does not provide T38FaxMaxDatagram in his SIP INVITE SDP message. The result was “WARNING[3849]: udptl.c:852 calculate_far_max_ifp: UDPTL (PJSIP/versateltrunk_endpoint-0000008b): Cannot calculate far_max_ifp before far_max_datagram has been set.” in asterisk messages and the INVITE was rejected with “SIP/2.0 488 Not Acceptable Here”.
> According to our analysis the root cause is that in “t38_initialize_session” the new udptl-structure is not initialized with the value from “session->endpoint->media.t38. maxdatagram”. The values for nat and error_correction in contrast are initialized properly.
> Therefor if the remote point does not provide a value for T38FaxMaxDatagram the value of “udptl->far_max_datagram” remains “-1” because ast_udptl_set_far_max_datagram is never called which results in the warning above.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list