On 25/10/2014 11:43 PM, Larry Moore wrote:
On 24/10/2014 12:47 AM, Tim Nelson wrote:
----- Original Message -----
On 22/10/2014 11:23 AM, Tim Nelson wrote:
Greetings-
Working with the T.38 gateway functionality that is sparsely
documented
[1], I'm attempting to get the following functional:
What type of endpoint are you using which is originating the call and
is
it T.38 capable?
The originating endpoint is an IAXmodem controlled by Hylafax. Actual
call flow is IAXmodem --G.711u via localhost--> Asterisk (old version
with no T.38 support) --G.711u--> Asterisk 11.x --G.711u/T.38--> ITSP
The problem lies on the Asterisk 11.x system not being able to
reinvite to T.38 on the call leg with the ITSP, and given the ITSP
does not do this either, the call is stuck in G.711u with varying
performance. :/
--Tim
IAXmodem (other host on network) -> Asterisk 1.2 (IAX) -> Asterisk 1.8
with Fax Gateway Patch -> SIP provider -> PSTN Fax destination
I have successfully sent a fax using a full page image via an Asterisk
1.2 system which forwards the request to my Asterisk 1.8 over an IAX
channel, Asterisk 1.8 has the T.38 Fax Gateway patch installed. The
outbound call triggered the T.38 gateway and the fax was received
without error. I have ECM disabled in my IAX modem configuration in
Hylafax.
I don't have Asterisk 11 running to test with at this time however I
confirmed the T.38 Gateway functions in Asterisk 11 when testing it.
-- Accepting AUTHENTICATED call from 192.168.54.18:
> requested format = ulaw,
> requested prefs = (ulaw|alaw|slin),
> actual format = alaw,
> host prefs = (alaw|ulaw),
> priority = mine
-- Executing [<PSTN Number>@FAX-T30:1] Dial("IAX2/faxgw-iax-1210",
"SIP/<PSTN Number>@itsp-fax,55") in new stack
== Using SIP RTP TOS bits 184
-- Called SIP/<PSTN Number>@itsp-fax
-- SIP/itsp-fax-0000000b is making progress passing it to
IAX2/faxgw-iax-1210
-- SIP/itsp-fax-0000000b is making progress passing it to
IAX2/faxgw-iax-1210
== Using SIP RTP TOS bits 184
-- SIP/itsp-fax-0000000b answered IAX2/faxgw-iax-1210
[Oct 25 23:24:11] NOTICE[27896]: channel.c:4220 __ast_read: Dropping
incompatible voice frame on IAX2/faxgw-iax-1210 of format slin since our
native format has changed to 0x8 (alaw)
-- Got Fax Tone CED Chan SIP/itsp-fax-0000000b [1] Sending T.38 Params
Peer Is IAX2/faxgw-iax-1210 [0]
-- Request on IAX2/faxgw-iax-1210 [0] Storing I: SIP/itsp-fax-0000000b [1]
== Using UDPTL TOS bits 184
-- Negotiated on SIP/itsp-fax-0000000b [4] Ignoring I:
IAX2/faxgw-iax-1210 [0]
-- T.38 Gateway starting for chan SIP/itsp-fax-0000000b and peer
IAX2/faxgw-iax-1210
pbx*CLI> iax2 show channels
Channel Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format
FirstMsg LastMsg
IAX2/faxgw-iax-1210 192.168.54.18 faxgw-iax 01210/00004 00010/00005
00000ms -0001ms 0000ms alaw Rx:NEW Tx:ACK
1 active IAX channel
pbx*CLI> fax show sessions
Current FAX Sessions:
Channel Tech FAXID Type Operation State File(s)
SIP/itsp-fax-0000000 Spandsp 1 T.38 receive Active (null)
1 FAX sessions
-- Executing [h@FAX-T30:1] GotoIf("IAX2/faxgw-iax-1210", "0?2:3") in new
stack
-- Goto (FAX-T30,h,3)
-- Executing [h@FAX-T30:3] NoOp("IAX2/faxgw-iax-1210", "Finish
if_FAX-T30_37") in new stack
-- Executing [h@FAX-T30:4] NoOp("IAX2/faxgw-iax-1210", "Call/Fax Ended
2014-10-25 23:27:38 +0800") in new stack
-- Connection Statistics
Bit Rate :14400
ECM : No
Pages : 1
== Spawn extension (FAX-T30, <PSTN Number>, 1) exited non-zero on
'IAX2/faxgw-iax-1210'
-- Hungup 'IAX2/faxgw-iax-1210'
Well, forgive me as I should have had an Asterisk 11 system up and
running and performing tests before posting.
It would appear there is a behavioural difference with the patch created
for Asterisk 1.8 and the implementation applied to Asterisk 11.
The observations as listed above relating to the fax gateway stepping
in, occurs when an outbound fax call is made using either of the g711
codecs, Asterisk detects the fax tones in the calling leg about 3
seconds after the call has been answered and sends a T.38 re-invite to
the ITSP.
Using Asterisk 11, when an outbound call is made, the fax gateway
detection feature does not do anything on the leg of the call (as you
have observed) to the ITSP until it receives a T.38 re-invite from the
ITSP, my observations show this occurs about 4 seconds after the call is
answered. I suspect once the T.38 re-invite is received from the ITSP,
the T.38 Gateway sends a T.38 re-invite on the leg of the caller to
check if it is capable of T.38. I have not confirmed this definitively.
I'm obviously fortunate my ITSP is correctly handling T.38.
Larry.
--
_____________________________________________________________________
-- 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
