[asterisk-dev] Fwd: T38 and codecs negotiation

[federico cabiddu]

Hi Theo,
I had a look on your patch and I tried it on asterisk-1.4.36.
Unfortunately it doesn't solve my problem which is related to an audio call
with no compatible codecs.
My scenario is the following:
1) user A has a set of allowed codecs configured on Asterisk (let's say ulaw
and g729)
2) user A sends an INVITE with none of the allowed codecs in the SDP (let's
say is sending alaw) and no T.38
3) Asterisk does not reject the call with "488 - Not acceptable here" but
make the call to the extension and return an SDP with no codec.

As I wrote in my previous mail the problem is present only when t38 is
globally enabled.
What the patch doesn't change in the original chan_sip.c is at row 5757 of
the patched file:

5755:    if (!newjointcapability) {
5756:                /* If T.38 was not negotiated either, totally bail
out... */
5757:                if (!p->t38.jointcapability || !udptlportno) {
5758:                         ast_log(LOG_NOTICE, "No compatible codecs, not
accepting this offer!\n");
5759:                         /* Do NOT Change current setting */
5760:                         return -1;

If t38 is globally enabled the condition is never matched regardless the SDP
contained a FAX request or not.
That's why I thought to change it with

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

or something similar to check if the call was effectively a Fax only call.
Unfortunately I'm not a big expert of T38 and its problems.
I'm trying your patch with this further modification. Till now I've tested
some few scenarios:

1) call with no compatible codec (that's was my main interest)
2) call with RTP and T38
3) T38 only call

The tests were ok (in the first one I got a 488, as desired) but, I repeat,
my knowledge of T38 is not enough...

Kind regards,

Federico Cabiddu
2010/9/24 Theo Belder <tbelder at gmail.com>

> Hi Federico,
>
> We have encoutered the same problem. We have made a patch for this, so you
> can send T38 only invites. You can find the patch here:
> https://issues.asterisk.org/view.php?id=17966. You should grep the latest
> patch (rev3)!
>
> BR. Theo
>
>
>
> 2010/9/22 federico cabiddu <federico.cabiddu at gmail.com>
>
>>
>>
>> ---------- 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
>>
>>
>>
>> --
>>
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>>
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100924/3801bd6e/attachment.htm