- Steve Underwood ste...@coppice.org escreveu:
Hi Vinícius,
Don't post big things, like wireshark traces, to a mailing list. They
are likely to ban you.
The first two calls in your wireshark log decode to the attached
images.
There were no lost packets. The wireshark logs
- Steve Underwood ste...@coppice.org escreveu:
Hi Vinícius,
Don't post big things, like wireshark traces, to a mailing list. They
are likely to ban you.
The first two calls in your wireshark log decode to the attached
images.
There were no lost packets. The wireshark logs
- Vinícius Fontes vinic...@canall.com.br escreveu:
- Steve Underwood ste...@coppice.org escreveu:
Hi Vinícius,
Don't post big things, like wireshark traces, to a mailing list.
They
are likely to ban you.
The first two calls in your wireshark log decode to the attached
- Kevin P. Fleming kpflem...@digium.com escreveu:
Vinícius Fontes wrote:
Will do. You guys will have my feedback on monday. If everything
goes okay with that change, I'll post a patch on Mantis.
No need for the patch; it's already on my radar, and if you confirm
that
it
On 02/15/2010 08:57 PM, Vinícius Fontes wrote:
- Kevin P. Flemingkpflem...@digium.com escreveu:
Vinícius Fontes wrote:
Will do. You guys will have my feedback on monday. If everything
goes okay with that change, I'll post a patch on Mantis.
No need for the
Steve Underwood wrote:
FFA sends its repeating no-signal and preamble packets with incrementing
sequence numbers. While its not the only system which does that, it
confuses some T.38 implementations. The T.38 spec is too vague to say
whether the practice is right or wrong. In other
On 02/15/2010 11:27 PM, Kevin P. Fleming wrote:
Steve Underwood wrote:
FFA sends its repeating no-signal and preamble packets with incrementing
sequence numbers. While its not the only system which does that, it
confuses some T.38 implementations. The T.38 spec is too vague to say
Steve Underwood wrote:
In callweaver we gave the frames an extra parameter, which is the number
of copies to send. It is the UDPTL code which creates the extra copies
on the wire. They are not spaced in time, which would probably be a good
enhancement. Packet loss tends to be bursty, so if
You could try defining the same identity string for app_fax that you
have defined for FFA. Trying to make the other things more similar
would
require additional work. Maybe you should try that change first, as it
is very simple, and requires no code changes.
My receiving fax macro,
- Kevin P. Fleming kpflem...@digium.com escreveu:
Vinícius Fontes wrote:
Will do. You guys will have my feedback on monday. If everything
goes okay with that change, I'll post a patch on Mantis.
No need for the patch; it's already on my radar, and if you confirm
that
it
Unfortunely it didn't solve the problem. Here's the session packet capture
after editing app_fax.c. http://www.canall.com.br/wireshark_t38_jbig.gz
Atenciosamente,
Vinícius Fontes
Gerente de Segurança da Informação
Canall Tecnologia em Comunicações
Passo Fundo - RS - Brasil
+55 54 2104-7000
Hi Vinícius,
Comparing the successful log using FFA and the failing one using
app_fax, I see the following:
In the call using FFA, the far end system sends a V.29/9600bps FAX page,
using T.38, which transfers cleanly, and the call ends.
In the call using app_fax/spandsp, the SIP has a couple
Steve Underwood wrote:
The only wrongdoing I see is the far end going weird in the training
data, yet this doesn't happen with the FFA call. Whatever makes the far
end fall over must be something fairly subtle. Since the 2 SDP lines I
listed above shouldn't be there, I think they should be
Will do. You guys will have my feedback on monday. If everything goes okay with
that change, I'll post a patch on Mantis.
Atenciosamente,
Vinícius Fontes
Gerente de Segurança da Informação
Canall Tecnologia em Comunicações
Passo Fundo - RS - Brasil
+55 54 2104-7000
Information Security
Vinícius Fontes wrote:
Will do. You guys will have my feedback on monday. If everything goes okay
with that change, I'll post a patch on Mantis.
No need for the patch; it's already on my radar, and if you confirm that
it actually solves an interop problem, I'll commit the update to the
This message is pointed directly to Steve Underwood. I tought it would not be
nice to directly email him with a question that interests a good part of the
Asterisk community, so here it is. :)
Steve, remember a few days ago when we discussed about issues on Asterisk
1.6.1.13 and T.38 fax
On 02/05/2010 07:40 PM, Vinícius Fontes wrote:
This message is pointed directly to Steve Underwood. I tought it would not be
nice to directly email him with a question that interests a good part of the
Asterisk community, so here it is. :)
Steve, remember a few days ago when we discussed
Yes, the fax machine only transmits at 9600. That's normal and expected. I'll
capture the packets and will provide you with a link to download it in a few
minutes.
Atenciosamente,
Vinícius Fontes
Gerente de Segurança da Informação
Canall Tecnologia em Comunicações
Passo Fundo - RS - Brasil
Here's the packet trace I promised:
http://www.zshare.net/download/72186098494e6f8c/.
As this is a production system, there were a few calls along with the one that
interests us. The one you're looking for is that from 5433142...@10.150.65.16
to 5421047...@10.153.66.146. The provider has the
There you go: http://www.canall.com.br/wireshark_trace_t38_ffa.gz
Atenciosamente,
Vinícius Fontes
Gerente de Segurança da Informação
Canall Tecnologia em Comunicações
Passo Fundo - RS - Brasil
+55 54 2104-7000
Information Security Manager
Canall Tecnologia em Comunicações
Passo Fundo - RS -
20 matches
Mail list logo
