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

[Kristijan Vrban]

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
>