[asterisk-users] t.38 interop with metaswitch

[Jeremy Kister]

I'm trying to receive a t.38 fax from a Metaswitch 7.3. I have full
control over the metaswitch, but it is in production.

I have the Metaswitch hooked to Asterisk 1.8.7.0 (middleman named s3).
Then I have the target Asterisk 1.8.7.0 with res_fax_digum 1.8.4_1.3.0
(named pbx1) registered to s3.

attempts to receive fax over t.38 always error in res_fax with "fax
session timed-out"

i have debug output at:
http://jeremy.kister.net/tmp/t38/pbx1.txt
http://jeremy.kister.net/tmp/t38/s3.txt

is the UDPTL debug on pbx1.txt (near line 474) interesting in that
LOG_TAG(s) is evaluated to 'SIP/' ?

I don't think my (sip|udptl|extensions).conf are interesting, but i'd be
happy to post them. the only interesting tidbit is that when i changed
't38pt_udptl=yes' to 'yes,none' or 'yes,redundancy' the fax would fail
with 't38 negotiation failed".

fyi, g711/rtp audio detected faxes are working fine.

anyone have suggestions on what i can try next?

[Kevin P. Fleming]

I'm trying to receive a t.38 fax from a Metaswitch 7.3. I have full
control over the metaswitch, but it is in production.
I have the Metaswitch hooked to Asterisk 1.8.7.0 (middleman named s3).
Then I have the target Asterisk 1.8.7.0 with res_fax_digum 1.8.4_1.3.0
(named pbx1) registered to s3.
attempts to receive fax over t.38 always error in res_fax with "fax
session timed-out"
http://jeremy.kister.net/tmp/t38/pbx1.txt
http://jeremy.kister.net/tmp/t38/s3.txt

It appears that the FAX transaction attempted training a few times and
failed, then fell back to audio mode (or the calling endpoint hung up).

is the UDPTL debug on pbx1.txt (near line 474) interesting in that
LOG_TAG(s) is evaluated to 'SIP/' ?

This bug with UDPTL debug messages was just fixed last week.

I don't think my (sip|udptl|extensions).conf are interesting, but i'd be
happy to post them. the only interesting tidbit is that when i changed
't38pt_udptl=yes' to 'yes,none' or 'yes,redundancy' the fax would fail
with 't38 negotiation failed".

Well, as a starting point, I'd suggest disabling directmedia
(canreinvite) on s3. It should be possible for directmedia to be enabled
for RTP and not interfere with UDPTL, but there could still be lingering
problems there.

[Jeremy Kister]

Post by Kevin P. Fleming
Well, as a starting point, I'd suggest disabling directmedia
(canreinvite) on s3. It should be possible for directmedia to be enabled
for RTP and not interfere with UDPTL, but there could still be lingering
problems there.

yep, you hit the nail on the head.

setting directmedia=no on s3 allows me to receive t38 faxes on pbx1.

debug for successful faxes in this case are at:
http://jeremy.kister.net/tmp/t38/no-reinvite-on-s3/pbx1.txt
http://jeremy.kister.net/tmp/t38/no-reinvite-on-s3/s3.txt

is there further changes that can be done to allow reinvite on s3? or
is this something that should go to the tracker ?

thanks,

[Kevin P. Fleming]

Post by Jeremy Kister

Post by Kevin P. Fleming
Well, as a starting point, I'd suggest disabling directmedia
(canreinvite) on s3. It should be possible for directmedia to be enabled
for RTP and not interfere with UDPTL, but there could still be lingering
problems there.

yep, you hit the nail on the head.
setting directmedia=no on s3 allows me to receive t38 faxes on pbx1.
http://jeremy.kister.net/tmp/t38/no-reinvite-on-s3/pbx1.txt
http://jeremy.kister.net/tmp/t38/no-reinvite-on-s3/s3.txt
is there further changes that can be done to allow reinvite on s3? or is
this something that should go to the tracker ?

It should be reported as a bug; even if the UDPTL stack doesn't support
directmedia, Asterisk should be able to properly setup a UDPTL media
stream in spite of a previous directmedia RTP path.