[asterisk-dev] fallback to audio faxing when T.38 INVITE fail with 488/606 Not acceptable

[Kristijan Vrban]

> I do not understand why the hiQ rejects the normal INVITE. But if it works,
> why not.

because it's _not_ a normal INVITE. It is the fallback INVITE that need
silenceSupp:off. And in my test setup silenceSupp:off was not set into
the SDP, beacuse
i have used the internal_timing option in asterisk.conf

in chan_sip.c/add_sdp:

if (!p->owner || !ast_internal_timing_enabled(p->owner))
                       ast_str_append(&a_audio, 0, "a=silenceSupp:off
- - - -\r\n");


Again http://tools.ietf.org/html/draft-ietf-sipping-realtimefax-01#section-6.2

"The terminating gateway SHOULD react by proposing a fallback to G.711
fax pass-through with special codec characteristics - -silence suppression OFF"

Kristijan


2010/2/9 Klaus Darilion <klaus.mailinglists at pernau.at>:
>
>
> Am 09.02.2010 11:52, schrieb Kristijan Vrban:
>>
>> I was struggling to get the T.38 fallback working with a Siemens Media
>> Gateway hiQ 9200 (used by british telecom in germany)
>> and my fallback re-re-INVITE to PCMA always faild with a "500 Internal
>> Server Error" then i read again:
>>
>> http://tools.ietf.org/html/draft-ietf-sipping-realtimefax-01#section-6.2
>>
>> An the i added hardcoded
>>
>> silenceSupp:off - - - -
>>
>> into the SDP in the fallback INVITE. Then it was working!
>>
>> So i want to ask, if you agree than we need to add this in case of a
>> T.38 fallback INVITE? Then i can try to make a patch.
>
> I do not understand why the hiQ rejects the normal INVITE. But if it works,
> why not.
>
> klaus
>
>>
>> Kristijan
>>
>>
>> 2010/1/25 Kristijan Vrban<vrban.lkml at googlemail.com>:
>>>
>>> hello klaus,
>>>
>>> check: https://issues.asterisk.org/view.php?id=16692
>>>
>>> kristijan
>>>
>>> 2010/1/21 Klaus Darilion<klaus.mailinglists at pernau.at>:
>>>>
>>>>
>>>> Kristijan Vrban schrieb:
>>>>>
>>>>> i can offer the patch for 1.4 on issue.asterisk.org but digium must
>>>>> decide if this is a bugfix or a feature.
>>>>> @digium bugfix or feature?
>>>>
>>>> a missing ACK is always a bug.
>>>>
>>>> please post the patch at the bugtracker
>>>>
>>>> regards
>>>> klaus
>>>>
>>>>>
>>>>> Kristijan
>>>>>
>>>>> p.s.
>>>>> and yes, i also would like to upgrade to 1.6. but this decision taken
>>>>> by the management team, and unfortunately not the technical staff :-(
>>>>>
>>>>> 2010/1/18 Klaus Darilion<klaus.mailinglists at pernau.at>:
>>>>>>
>>>>>> Kristijan Vrban schrieb:
>>>>>>>
>>>>>>> I took a look into 1.6 source. 1.6 does a re-re-INVITE to audio after
>>>>>>> its T.38 re-INVITE failed. A backport is simple. But i think in
>>>>>>> allready know the answer. No, this is a new feature, no new features
>>>>>>> into 1.4 So one more backport patch into my patch folder for my
>>>>>>> asterisk 1.5 :)
>>>>>>
>>>>>> IMO this isn't a new feature, but a bugfix.
>>>>>>
>>>>>> I experienced same problems too.
>>>>>>
>>>>>> regards
>>>>>> klaus
>>>>>>
>>>>>>> kristijan
>>>>>>>
>>>>>>> 2010/1/13 Kevin P. Fleming<kpfleming at digium.com>:
>>>>>>>>
>>>>>>>> Kristijan Vrban wrote:
>>>>>>>>>>
>>>>>>>>>> However, the original message was a bit unclear if it was a
>>>>>>>>>> re-invite or an invite.
>>>>>>>>>
>>>>>>>>> re-invite
>>>>>>>>>
>>>>>>>>> And there is no difference if chan_sip get a 488 or 606 for the
>>>>>>>>> T.38
>>>>>>>>> re-INVITE (both are valid response) . As far as i can see, there is
>>>>>>>>> simply no logic that handle a fallback to audio fax when the caller
>>>>>>>>> can not handle T.38? I examined how a Cisco/Linksys SPA2120 handel
>>>>>>>>> this: It ACK the 488/606 for its rejected T.38 re-INVITE and send a
>>>>>>>>> re-re-INVITE with PCMU, and then the fax is transported via audio
>>>>>>>>> RTP.
>>>>>>>>
>>>>>>>> If Asterisk sends a re-INVITE to T.38, and the other end rejects it,
>>>>>>>> there is nothing to be done to 'fallback' to audio mode; the call is
>>>>>>>> still in audio mode, because it never left audio mode.
>>>>>>>>
>>>>>>>> Also, you are doing this testing with Asterisk 1.4, which has very
>>>>>>>> limited support for T.38; the T.38 support in Asterisk 1.6.x is
>>>>>>>> vastly
>>>>>>>> improved, and I'd highly encourage you to use instead if you can.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Kevin P. Fleming
>>>>>>>> Digium, Inc. | Director of Software Technologies
>>>>>>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>>>>>>> skype: kpfleming | jabber: kpfleming at digium.com
>>>>>>>> Check us out at www.digium.com&  www.asterisk.org
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> _____________________________________________________________________
>>>>>>>> -- 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
>>>>>>
>>>>>
>>>>
>>>> --
>>>> _____________________________________________________________________
>>>> -- 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
>>>>
>>>
>>
>