[asterisk-dev] Fwd: T38 and codecs negotiation

[federico cabiddu]

---------- Forwarded message ----------
From: federico cabiddu <federico.cabiddu at gmail.com>
Date: 2010/9/22
Subject: [asterisk-users] T38 and codecs negotiation
To: asterisk-users at lists.digium.com


Hi,
I'm working with asterisk 1.4.35 and found an issue regarding codecs
negotiation when T38 is enabled (t38pt_udptl=yes).
In particular if the INVITE sdp contains no allowed codec the call is not
rejected with "488 - Not acceptable here" but it goes through and the 200 OK
SDP is as follows:

v=0
o=root 27285 27285 IN IP4 xxx.xxx.xxx.xxx
s=session
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio xxxxx RTP/AVP
a=silenceSupp:off - - - -
a=sendrecv

or

v=0
o=root 27285 27285 IN IP4 xxx.xxx.xxx.xxx
s=session
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio xxxxx RTP/AVP 96
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=silenceSupp:off - - - -
a=sendrecv

if in the originating INVITE there was the a line for telephone-event
mapping.
Looking chan_sip.c I understood that the problem is related to t38
capabilities and in particular at row 5636:

if (!newjointcapability) {
        /* If T.38 was not negotiated either, totally bail out... */
        if (!p->t38.jointcapability || !udptlportno) {
                ast_log(LOG_NOTICE, "No compatible codecs, not accepting
this offer!\n");
                /* Do NOT Change current setting */
                return -1;
        } else {
                if (option_debug > 2)
                        ast_log(LOG_DEBUG, "Have T.38 but no audio codecs,
accepting offer anyway\n");
        }
 }

As I understand if t38 is globally enabled p->t38.jointcapability
and udptlportno are always true even so the call is never rejected.
As this behavior caused me some problems with a customer I modified, for the
moment, the line 5638 as follows:

if (!p->t38.jointcapability || !udptlportno || p->t38.state == T38_DISABLED)

cause if I understand well the code if there is no fax request in the INVITE
SDP p->t38.state is set to T38_DISABLED.
This did the trick for me but I don't know the implications of such change
and if it is correct to manage it this way.

Kind regards,

Federico Cabiddu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100922/49ae56ee/attachment.htm