Hello,
at first, thanks for helping!
In the meantime, I have done a lot of research and trial and error, and I could
solve that specific problem. Obviously, the dialplan application "Answer" was
playing a key role here. My original dialplan snippet (which produced that
problem) was:
exten => _00., 1, NoOp()
same => n, Set(FAXOPT(gateway)=yes)
same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg)
same => n, Hangup()
The problem vanished when I changed that to:
exten => _00., 1, NoOp()
same => n, Answer()
same => n, Progress()
same => n, Set(FAXOPT(gateway)=yes)
same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg)
same => n, Hangup()
However, I got another problem then:
The fax training now went well, and a part of the fax was transmitted, i.e.
switching from G711 to T32 now worked. But after 32 seconds (measured from the
begin of the transmission) Asterisk claimed that there was a timeout with
receiving an answer to a critical packet, and ended the transmission (by
sending BYE messages to both ends).
Wireshark and SIP debug analysis have shown that this error message is
completely humbug. I have thoroughly gone through the logs line by line more
times that I could count, and (by following the CSeq) I every time have seen
that the error message was relating to one or more OK messages which Asterisk
had sent to the provider, but I swear that the provider correctly had ACKed
every single of these OK messages. So I really can't imagine how Asterisk came
to the idea that it hadn't received the answer. Maybe my interpretation of the
logs is wrong, but if Wireshark's logs show an ACK for every OK, all should be
well, shouldn't it?
Anyway, that means that I now can send an average one page fax document to fast
endpoints which do the training quickly and provide high data rates. But if the
endpoint is slower or if the fax document has multiple pages or a
disadvantageous structure, it will take more than 32 seconds to transmit and
thus will be cut by Asterisk. The receiving fax machine in this case either
sees a part of the page or some weird random patterns.
I think that this is a bug in chan_sip which seemingly does not have the best
reputation when it comes to T38. The erroneous behaviour has shown in every
test I have done (4 different fax machines at the other end serviced by three
different providers, each tested with two different SIP providers (trunks)).
At this point, I have given up chan_sip and hoped that pjsip would behave
correctly, but what a frustration: Although spending three complete days with
it, I even couldn't make it do the training. It always makes the SIP provider
switch to T38 at once at the very beginning of the transmission which of course
won't work. I think I'll open another thread about that problem; it's somehow
off-topic here.
Regards and thank you very much,
Recursive
On 10.12.2014 11:42, Frederic Van Espen wrote:
> Hi,
>
> On Tue, Dec 2, 2014 at 9:24 AM, Recursive <[email protected]> wrote:
>> - Packets 14313, 14314: The provider re-invites asterisk for T.38 (confirmed
>> by viewing the packet's details), asterisk answers "Trying ..." to the
>> provider
>> - Packets 14315, 14321, 14322: Asterisk re-invites the local endpoint (again
>> confirmed by looking into the packet's details), the local endpoint answers
>> "OK", and asterisk ACKs the OK.
>> - Packets 14323, 14329: Asterisk accepts the invitation from the provider by
>> sending "OK" to the provider, and the provider ACKs the OK.
>> - Packets 14453, 14454 and 14649: The local endpoint again tries to
>> re-invite asterisk for T.38 (confirmed by looking into the packet's
>> details), Asterisk answers "Trying" and then refuses, saying "488: Not
>> acceptable here"
>> - From then on, things go horribly wrong (probably, the local endpoint is
>> still expecting G.711 packets, but gets T.38 packets)
>>
>> I have provided all packets which are relevant. The packet numbers are not
>> contiguous since asterisk currently is on a test server which runs many
>> other services (the packets of which I have filtered out).
>>
>> I didn't want to clutter this post too much, thus I have only provided an
>> overview and not the details of each packet. Furthermore, please forgive me
>> that it's much easier for me to read Wireshark's logs than Asterisk's logs.
>> Of course, I will provide every log anybody trying to help out asks me for.
>>
>> But my first question is a very simple one:
>>
>> From the log above, I am quite sure that switching to T.38 is done right up
>> to (and including) packet 14329. I think that my local endpoint then
>> misbehaves by again re-inviting asterisk for T.38 (as all parties already
>> have agreed upon T.38).
>>
>> Thus, is my endpoint really misbehaving, and if yes, is there anything I can
>> do about it on Asterisk's side? Or do the SIP/T.38 state machines allow such
>> (seemingly superfluous) re-invite, and it's Asterisk's fault to answer with
>> 488?
>
> - Could you share the details of the SDP in each INVITE and OK packet?
> - How are your SIP endpoints configured in asterisk sip.conf? (the SIP
> trunk provider and the local endpoint)
> - What type is the local endpoint?
>
> Cheers,
>
> Frederic
>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
