[Home]

Summary:ASTERISK-07481: T.38 passthrough is not working between two Sipuras 2100
Reporter:Ahsan Masood (ahsan)Labels:
Date Opened:2006-08-08 03:13:16Date Closed:2007-02-05 10:25:18.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Cisco_T38_request.txt
( 1) Cisco_to_Veraz_T38_Passthrough.txt
( 2) Log_16112006.txt
( 3) sipura-t.38_debug.txt
( 4) SPA3102-debug.txt
( 5) t38.log
( 6) t38-fax.txt
( 7) UDPTL_tethereal_capture.txt
( 8) Veraz_T38_request.txt
( 9) verbose_debug_no_UDPTL_r51360_wDEBUG.txt
(10) verbose_debug_no_UDPTL_r51360.txt
(11) verbose_debug_no_UDPTL.txt
Description:I am trying to get T.38 tested between two sipuras 2100 on the same astersik server and having issues.




****** ADDITIONAL INFORMATION ******

My current sip.conf has following in default context

t38pt_udptl=yes
t38pt_rtp=no
t38pt_tcp=no

and Extensions are as

[200]
type=friend
dtmfmode=rfc2833
context=default
host=dynamic
callgroup=1
pickupgroup=1
username=200
secret=002
allow=all
;allow=ulaw
canreinvite=no
callerid=Reception <200>
accountcode=200
trustrpid=yes
t38pt_udptl=yes
t38pt_rtp=yes
t38pt_tcp=yes


[201]
type=friend
dtmfmode=rfc2833
context=default
host=dynamic
callgroup=1
pickupgroup=1
username=200
secret=002
;disallow=all
allow=all
accountcode=201
canreinvite=no
trustrpid=yes
t38pt_udptl=yes
t38pt_rtp=no
t38pt_tcp=no

I have attached the log file (t38.log)

Comments:By: Olle Johansson (oej) 2006-08-08 03:28:14

Version 1.2 of Asterisk does not support these configuration options or T.38 passthrough at all. It is only supported by svn trunk.
By: Ahsan Masood (ahsan) 2006-08-08 03:37:49

Sorry, I should made it cleaar earlier, I am using SVN trunk version and show version shows Asterisk SVN-trunk-r38826 in the CLI.
By: Olle Johansson (oej) 2006-08-08 04:11:52

You reported this as 1.2.10 :-)
By: Joshua C. Colp (jcolp) 2006-08-08 09:58:51

I'm not even seeing an attempt by the Sipuras to do a reinvite to T.38 on the sip debug you provided. Are they configured properly to reinvite to T.38 upon hearing a fax tone?
By: Dave Hindmarsh (niteowldave) 2006-08-09 18:36:37

Hi Ahsan, how did you go with the two Sipuras, I have ordered a couple of these to continue my testing.
By: Dave Hindmarsh (niteowldave) 2006-08-11 00:30:00

Hi All,

Have uploaded a sip debug trace(sipura2100.txt) of two Sipura 2100 units failing to use t.38 as requested.

The units always fallback to using g711.

Is there a special way to set the Sipuras up, I followed the instructions on the Sipura web site at http://www.sipura.com/support/spa2100faq/Section_3.html.

Cheers
Dave
By: Ahsan Masood (ahsan) 2006-08-11 03:57:39

Hi All,

I have followed the same instructions as on http://www.sipura.com/support/spa2100faq/Section_3.html to configure sipuras, and had no luck to get T.38 working with asterisk.

These settings does work when Sipura's are used with SER.
By: Serge Vecher (serge-v) 2006-08-11 09:27:02

the document talks about a lot of things. Did you set FAX_Passthru_Method to ReINVITE, under the Line tabs?
By: Dave Hindmarsh (niteowldave) 2006-08-13 18:30:55

Hi Vechers,

Yes, I set the FAX Passthru Method: to Re-Invite, this should be evident from the Sip debug attached.

Cheers
Dave
By: Rosario Pingaro (rpingar) 2006-08-19 06:00:14

upgrade the sipura firmware to 3.2.9b or best go with 3.3.6

the previus versions had a bug about t.38.

Regards
Rosario
By: Dave Hindmarsh (niteowldave) 2006-08-20 21:15:12

Hi rpingar,

I upgraded to 3.3.6 as suggested, 2100s are still falling back to alaw, see http://pastebin.ca/141686 for a sip debug.

Cheers
By: Serge Vecher (serge-v) 2006-08-21 10:27:02

This bug is looking more like a bug in Sipuras than in Asterisk.

all: when posting debugs, please always specify what revision of trunk you are using (and please make sure it's very close to the latest).

niteowldave: the sip debug you've posted on pastebin.ca is missing debug output. Please make follow these instructions to get the proper debug output:
1) Prepare test environment (reduce the ammount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete console log to file and _attach_ said file to the bug.
By: Dave Hindmarsh (niteowldave) 2006-08-22 02:16:53

I have uploaded the complete file as requested.

Thanks
By: Serge Vecher (serge-v) 2006-08-22 08:49:28

niteowldave: please post the sip.conf entries for respective peers. Thanks.
By: Dave Hindmarsh (niteowldave) 2006-08-22 19:22:31

Sip.conf entries for the 2100s are as follows.

Cheers

These boxes are all on public ips if you want to take a look.

[100397]
username=100397
type=friend
secret=secret
qualify=no
port=5060
nat=never
mailbox=100397@device
host=dynamic
dtmfmode=rfc2833
disallow=all
context=from-internal
canreinvite=yes
callerid=100397 <100397>
allow=alaw
allow=ulaw
t38pt_udptl=yes

[100398]
username=100398
type=friend
secret=secret
qualify=no
port=5060
nat=never
mailbox=100398@device
host=dynamic
dtmfmode=rfc2833
disallow=all
context=from-internal
canreinvite=yes
callerid=100398 <100398>
allow=alaw
allow=ulaw
t38pt_udptl=yes
By: Serge Vecher (serge-v) 2006-08-23 08:27:22

hmmm, interesting 100398 does a reinvite with T.38 info, but we respond with a 488. Moving this to confirmed for a developer to pick up.
By: Alex Coseru (alexcos) 2006-08-30 03:08:51

*CLI> show version
Asterisk SVN-trunk-r41241 built by root @ victoria on a x86_64 running Linux on 2006-08-29 19:35:53 UTC

Cannot get t38 passthrough to work either...

I have attached a log   (t38-fax.log).

The main problem is:

[Aug 30 09:03:26] DEBUG[26104]: chan_sip.c:4827 process_sdp: Our T38 capability = (3872), peer T38 capability (16160), joint T38 capability (3872)
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x0 (nothing)/video=0x0 (nothing), combined - 0x0 (nothing)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
[Aug 30 09:03:26] NOTICE[26104]: chan_sip.c:4862 process_sdp: No compatible codecs, not accepting this offer!


By: Alex Coseru (alexcos) 2006-09-04 04:05:38

Hello guys..
Any news on this ?

Confirmed on "Asterisk SVN-trunk-r41974 built by root @ gr-core-1 on a x86_64 running Linux on 2006-09-04 09:19:56 UTC" also

Regards


By: Ahsan Masood (ahsan) 2006-09-04 10:20:47

Hi,

Is there any update on the issue?

Telappliant is willing to add another $1000 to the existing bounty for T.38

Regards,

Ahsan
By: Serge Vecher (serge-v) 2006-09-05 11:12:26

guys: please post the bounty info on the wiki, thanks.
By: bcoppens (bcoppens) 2006-09-26 06:14:29

Same behavior for T.38 Fax call from a Cisco device onto Veraz NGN.

Sip Config

[VERAZ]
type=friend
context=default
host=172.16.150.100
canreinvite=yes
t38pt_udptl = yes

[cisco]
type=friend
context=internal
host=217.113.77.13
dtmfmode=rfc2833
;disallow =all
;allow=g729
allow=all
insecure=yes
nat=no
canreinvite=yes
t38pt_udptl = yes
insecure=yes
nat=no

Version: Asterisk SVN-trunk-r41974 built by root @ linux-atlantis-be on a i686 running Linux on 2006-09-04 11:33:33 UTC

See log enclosed  "Cisco_to_Veraz_T38_Passthrough.txt"
By: Leonardo Gomes Figueira (sabbathbh) 2006-09-29 15:00:44

I'm trying with 2 UTStarcom IAN-02EX ATAs and 1.4 branch and got the same problem:

[Sep 29 16:39:19] WARNING[30981]: chan_sip.c:4643 process_sdp: Unsupported SDP media type in offer: image 4504 udptl t38

Asterisk and ATAs on the same LAN with canreinvite working between then. No NAT.

I don't know if the T.38 implementation on this ATAs really work since I didn't find on google anyone that already tested this but I would like to help solving this issue anyway (and find out if this ATAs work with T.38).

Do you want debug/sip debug ?

Connected to Asterisk SVN-branch-1.4-r43997 currently running on pfdesenv (pid = 30932)
By: Andrew Lindh (andrew) 2006-09-29 16:46:52

I had T38 passthru working correctly with a patched version of asterisk 1.2 with the SPA2100 at one end and the cisco AS5300 on the other. With 1.4 and "t38pt_udptl=yes" set I just get "no compatible codecs" now and it uses G711u.
By: Serge Vecher (serge-v) 2006-10-04 14:40:24

what happens if you also allow=ulaw for both peers?
By: Leonardo Gomes Figueira (sabbathbh) 2006-10-05 07:38:47

andrew,

with which version of 1.2 and witch patch did you get it working ? I tried both patches of http://bugs.digium.com/view.php?id=5090 with 1.2.7.1 and got not luck with T.38.

Leonardo
By: Serge Vecher (serge-v) 2006-10-05 09:18:06

guys, please no discussions on backported patches on the bug-tracker!
instead, please see if this change in 1.4 has any effect on this issue...
http://lists.digium.com/pipermail/svn-commits/2006-October/017504.html
By: Leonardo Gomes Figueira (sabbathbh) 2006-10-05 12:27:26

serge-v,

Now the message "Unsupported SDP media type in offer: image 4500 udptl t38" appears just once on the console and the SIP negotiation stops. Before this changes it appeared several times.

Asterisk SVN-branch-1.4-r44465 built by root @ pfdesenv on a i686 running Linux on 2006-10-05 15:24:57 UTC

   -- SIP/3035-092be570 answered SIP/3028-092b8b30
   -- Native bridging SIP/3028-092b8b30 and SIP/3035-092be570
pfdesenv*CLI> channel list
Channel              Location             State   Application(Data)
SIP/3035-092be570    (None)               Up      Bridged Call(SIP/3028-092b8b30
SIP/3028-092b8b30    s@macro-atende:900   Up      Dial(SIP/3035|30|)
2 active channels
1 active call
pfdesenv*CLI> sip list channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)  Form  Hold     Last Message
172.16.10.112    3035        28bf6e1a6cf  00102/00000  alaw  No       Tx: ACK
172.16.10.128    3028        3421806508@  00101/00701  alaw  No       Rx: ACK
2 active SIP channels

Call established. FAX signal starts here.

[Oct  5 12:43:59] WARNING[13491]: chan_sip.c:4647 process_sdp: Unsupported SDP media type in offer: image 4500 udptl t38
pfdesenv*CLI> sip list channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)  Form  Hold     Last Message
172.16.10.112    3035        28bf6e1a6cf  00104/00000  alaw  No       Tx: ACK
172.16.10.128    3028        3421806508@  00102/00705  alaw  No       Rx: ACK
2 active SIP channels
 == Spawn extension (macro-atende, s, 900) exited non-zero on 'SIP/3028-092b8b30' in macro 'atende'
 == Spawn extension (macro-atende, s, 900) exited non-zero on 'SIP/3028-092b8b30'
[Oct  5 12:44:46] WARNING[13491]: chan_sip.c:11514 handle_response_invite: Re-invite to non-existing call leg on other UA. SIP dialog '3421806508@172.16.10.128'. Giving up.
pfdesenv*CLI> sip list channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)  Form  Hold     Last Message
172.16.10.128    3028        3421806508@  00103/00705  unkn  No       Tx: ACK
1 active SIP channel
pfdesenv*CLI>

Uploaded file debug_t38_1.4-r44465_consoledebug.txt with debug enabled on console like you asked.
By: Joshua C. Colp (jcolp) 2006-10-05 12:29:29

Are you sure the settings are the same? The modification I made would not have caused that issue.
By: Joshua C. Colp (jcolp) 2006-10-05 12:33:26

Actually upon further inspection of the debug it looks as though one side has T.38 enabled and the other side doesn't.
By: Leonardo Gomes Figueira (sabbathbh) 2006-10-05 17:19:02

file,

forget what I said about the message showing up several times on the console. This is not related to this tests with 1.4 branch or to your changes.

About the ATAs:

I have two UTStarcom IAN-02EX ATAs with the same firmware and same config on both sides. Just to be sure they have the same config I used the "Save Config" on one unit and uploaded to the other unit to "clone it" (Later I changed sip username and password on this unit of course).

Even the FAX machines are the same  brand/model on both sides :)

If I dial from 3028 to 3035 and press the FAX start on 3035 then 3035 make the INVITE with T.38 (and Asterisk returns 488).
If I reverse the process, dial from 3035 to 3028 and press the FAX start on 3028 then it's 3028 that makes the INVITE with T.38 (and Asterisk returns 488 too).
So this shows that both sides have T.38 enabled.

Like I said on my initial post I never tested this UTStarcom ATAs with T.38 so I can't be sure they are not the source of the problem but I think the ATAs are not the issue here.

I just had an ideia: I'll test the ATAs with SER if it's capable of T.38 passthrough to make sure they work fine with T.38. I'll try to install SER tomorrow to make this test (never worked with SER before so it may take a while to learn). I'll post results if they might help on this issue.

The SIP messages of both ATAs trying to start T.38:

3028 started the FAX tone.

pfdesenv*CLI>
<-- SIP read from 172.16.10.128:5060:
INVITE sip:3035@172.16.10.189 SIP/2.0
Via: SIP/2.0/UDP 172.16.10.128:5060;branch=z9hG4bK3849291444
From: 3028 <sip:3028@172.16.10.189>;tag=1250977386
To: <sip:3035@172.16.10.189>;tag=as0ea655e7
Call-ID: 513682463@172.16.10.128
CSeq: 203 INVITE
Contact: <sip:3028@172.16.10.128:5060>
max-forwards: 70
user-agent: iAN-02EX V4.8.2.50b
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Content-Type: application/sdp
Content-Length:   260

v=0
o=- 4647 3044 IN IP4 172.16.10.128
s=-
c=IN IP4 172.16.10.128
t=0 0
m=image 4500 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:0
a=T38FaxMaxDatagram:176
a=T38FaxUdpEC:t38UDPRedundancy

--- (12 headers 12 lines) ---
Sending to 172.16.10.128 : 5060 (no NAT)
[Oct  5 18:55:17] WARNING[16029]: chan_sip.c:4647 process_sdp: Unsupported SDP media type in offer: image 4500 udptl t38
Transmitting (no NAT) to 172.16.10.128:5060:
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 172.16.10.128:5060;branch=z9hG4bK3849291444;received=172.16.10.128
From: 3028 <sip:3028@172.16.10.189>;tag=1250977386
To: <sip:3035@172.16.10.189>;tag=as0ea655e7
Call-ID: 513682463@172.16.10.128
CSeq: 203 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16


---


3035 started the FAX tone.

pfdesenv*CLI>
<-- SIP read from 172.16.10.112:5060:
INVITE sip:3028@172.16.10.189 SIP/2.0
Via: SIP/2.0/UDP 172.16.10.112:5060;branch=z9hG4bK1478375348
From: 3035 <sip:3035@172.16.10.189>;tag=3948329590
To: <sip:3028@172.16.10.189>;tag=as10a1f03e
Call-ID: 2799244669@172.16.10.112
CSeq: 303 INVITE
Contact: <sip:3035@172.16.10.112:5060>
max-forwards: 70
user-agent: iAN-02EX V4.8.2.50b
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Content-Type: application/sdp
Content-Length:   261

v=0
o=- 28467 3132 IN IP4 172.16.10.112
s=-
c=IN IP4 172.16.10.112
t=0 0
m=image 4500 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:0
a=T38FaxMaxDatagram:176
a=T38FaxUdpEC:t38UDPRedundancy

--- (12 headers 12 lines) ---
Sending to 172.16.10.112 : 5060 (no NAT)
[Oct  5 18:57:08] WARNING[16029]: chan_sip.c:4647 process_sdp: Unsupported SDP media type in offer: image 4500 udptl t38
Transmitting (no NAT) to 172.16.10.112:5060:
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 172.16.10.112:5060;branch=z9hG4bK1478375348;received=172.16.10.112
From: 3035 <sip:3035@172.16.10.189>;tag=3948329590
To: <sip:3028@172.16.10.189>;tag=as10a1f03e
Call-ID: 2799244669@172.16.10.112
CSeq: 303 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16


---
By: Joshua C. Colp (jcolp) 2006-10-05 17:23:04

Out of curiosity - what Asterisk version are you testing with?
By: Marcel Barbulescu (marcelbarbulescu) 2006-10-05 20:07:03

file: just added SPA3102-debug.txt that is collected from a spa3102 with canreinvite=no. Asterisk 1.4beta2 + http://lists.digium.com/pipermail/svn-commits/2006-October/017504.html
By: Leonardo Gomes Figueira (sabbathbh) 2006-10-06 07:01:25

file,

like I posted on comment 0052602:

Asterisk SVN-branch-1.4-r44465 built by root @ pfdesenv on a i686 running Linux on 2006-10-05 15:24:57 UTC
By: Serge Vecher (serge-v) 2006-10-06 11:05:08

sabbathbh: there was another fix committed in r44486 (http://lists.digium.com/pipermail/svn-commits/2006-October/017512.html). Please always check the latest 1.4 branch while in beta stage!

marcelbarbulescu: also, do check out the latest 1.4 branch code straight from SVN. canreinvite must be 'yes' in order for t38 passthrough to work properly.
By: Marcel Barbulescu (marcelbarbulescu) 2006-10-06 11:08:28

serge-v: I posted that trace at file's request. We talked on IRC and he wanted me to try with canreinvite=no.
By: Leonardo Gomes Figueira (sabbathbh) 2006-10-06 13:18:11

serge-v,

tested with:

Asterisk SVN-branch-1.4-r44581 built by root @ pfdesenv on a i686 running Linux on 2006-10-06 18:10:51 UTC

Still not working:

[Oct  6 15:14:29] DEBUG[28502]: chan_sip.c:2010 __sip_ack: Acked pending invite 102
   -- SIP/3035-092327f0 answered SIP/3028-0922dd58
   -- Native bridging SIP/3028-0922dd58 and SIP/3035-092327f0
[Oct  6 15:14:43] WARNING[28502]: chan_sip.c:4647 process_sdp: Unsupported SDP media type in offer: image 4500 udptl t38
[Oct  6 15:14:44] DEBUG[28526]: chan_sip.c:1578 initialize_initreq: Initializing already initialized SIP dialog 7e6f358959efc89757e167fb673cec79@172.16.10.189 (presumably reinvite)
[Oct  6 15:14:44] DEBUG[28502]: chan_sip.c:2010 __sip_ack: Acked pending invite 103
[Oct  6 15:14:44] DEBUG[28502]: chan_sip.c:7633 build_route: build_route: Retaining previous route: <sip:3035@172.16.10.104:5060>
[Oct  6 15:14:44] DEBUG[28526]: chan_sip.c:1578 initialize_initreq: Initializing already initialized SIP dialog 598252286@172.16.10.153 (presumably reinvite)
[Oct  6 15:14:44] DEBUG[28502]: chan_sip.c:2010 __sip_ack: Acked pending invite 102
[Oct  6 15:14:44] DEBUG[28526]: chan_sip.c:1578 initialize_initreq: Initializing already initialized SIP dialog 7e6f358959efc89757e167fb673cec79@172.16.10.189 (presumably reinvite)
[Oct  6 15:14:44] DEBUG[28502]: chan_sip.c:2010 __sip_ack: Acked pending invite 104
[Oct  6 15:14:44] DEBUG[28502]: chan_sip.c:7633 build_route: build_route: Retaining previous route: <sip:3035@172.16.10.104:5060>
pfdesenv*CLI>
By: Leonardo Gomes Figueira (sabbathbh) 2006-10-06 15:08:26

Like I said yesterday I didn't know if this UTStarcom ATAs really work with
T.38 so to be sure I created a test enviroment with SER (SIP Express Router)
and got them working with T.38.

In the initial tests the UDPtl session started from the receiver to the
sender but the FAX was not transmited by the sender. So I noticed that
when the FAX signal starts on the receiver machine the sender machine sends an DTMF and this DTMF was sent via SIP INFO (cause in the ATA config it's set to use SIP INFO). So I tried changing the ATA config to send DTMF inband and the T.38 started working using SER.

After that I tried again with Asterisk but it still not work (when the ATA
reinvite to T.38 Asterisk refuses with "488 Not acceptable here" and the
"Unsupported SDP media type in offer: image 4500 udptl t38" shows up.

Uploaded a new console debug with revision 44581 and this ATAs setup that
work with SER: consoledebug_t38_1.4-r44581_nodtmf.txt

About the SER setup just to be clear before someone says it maybe different
configuration on the ATAs: it's absolutely the SAME config in the ATAs testing with Asterisk or SER. I just "service asterisk stop" and "service ser start" and reboot the ATAs so they register with SER.

When I want to test Asterisk again I just "service ser stop" and "service asterisk start" (and reboot the ATAs to register with Asterisk).
By: Leonardo Gomes Figueira (sabbathbh) 2006-10-10 11:53:18

serve-v,

please delete this debug files that I sent:
debug_t38_1.4-r44465_consoledebug.txt [^] (107,084 bytes) 10-05-06 12:24
consoledebug_t38_1.4-r44581_nodtmf.txt [^] (580,781 bytes) 10-06-06 14:55

The error I got in this situations were due to a missing "t38pt_udptl=yes" in the [general] section. My fault.

Even then, T.38 is not working yet but I think the debug posted in SPA3102-debug.txt is the same error that I get now.

I got it working in 1.2.7.1 with the 1.2.4 patch of issue 5090 and that is what I needed anyway. But I will be glad to test patches on 1.4 when they are available.
By: Serge Vecher (serge-v) 2006-10-13 08:21:37

sabbathbh: what's the status with the latest 1.4 branch? Please post an updated debug.
By: bcoppens (bcoppens) 2006-10-17 08:54:51

Have been testing with the latest 1.4 CVS and found the following mismatch.

The T38 negociation seems to work well but I detected some issues in the Asterisk 200-OK response towards the T38 initiator (re-invite).

Asterisk is not responding with the right header when transmitting the "200 OK"

In stead of taking the header of the Re-ivinte (requesting T38), Asterisk takes the header of the previously received "200 OK", which was used for the answer.

This scenario happens in both directions; When Called initatiates T38 reinvite and when calling initaties the re-invite.

Both devices ignore the "200-OK" and retry the T38 request.

example:
Cisco requesting T38 with:

<--- SIP read from 217.113.77.13:56909 --->
INVITE sip:3271492041@217.113.77.17:5060 SIP/2.0
Via: SIP/2.0/UDP  217.113.77.13:5060;branch=z9hG4bK1031FE7
From: <sip:7001@217.113.77.13>;tag=6758DAB2-1B1F
To: <sip:3271492041@217.113.77.17>;tag=as5b009254
Date: Fri, 18 Apr 2003 19:47:58 GMT
Call-ID: 64A03D1C-710D11D7-82F2B5B0-303B2474@217.113.77.13
Supported: 100rel,timer
Min-SE:  1800
Cisco-Guid: 1640384452-1896681943-2196747696-809182324
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
CSeq: 102 INVITE
Max-Forwards: 70
Remote-Party-ID: <sip:7001@217.113.77.13>;party=calling;screen=no;privacy=off
Timestamp: 1050695278
Contact: <sip:7001@217.113.77.13:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 398

v=0
o=CiscoSystemsSIP-GW-UserAgent 4104 4293 IN IP4 217.113.77.13
s=SIP Call
c=IN IP4 217.113.77.13
t=0 0
m=image 18468 udptl t38
c=IN IP4 217.113.77.13
a=T38FaxVersion:0
a=T38MaxBitRate:7200
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy

Asterisk responds with:

<--- Reliably Transmitting (no NAT) to 217.113.77.13:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP  217.113.77.13:5060;branch=z9hG4bK10123CE;received=217.113.77.13
From: <sip:7001@217.113.77.13>;tag=6758DAB2-1B1F
To: <sip:3271492041@217.113.77.17>;tag=as5b009254
Call-ID: 64A03D1C-710D11D7-82F2B5B0-303B2474@217.113.77.13
CSeq: 101 INVITE
User-Agent: gatewaycomms
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:3271492041@217.113.77.17>
Content-Type: application/sdp
Content-Length: 261

v=0
o=root 14799 14801 IN IP4 217.113.77.17
s=session
c=IN IP4 217.113.77.17
t=0 0
m=image 4906 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:7200
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:72
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy


As you can see, both dialogues are different.

enclosed, you will find two traces:
- T38 request initated from the calling side (Cisco_T38_request.txt)
- T38 request initiated from called (Veraz_T38_request.txt)


Using Asterisk SVN-branch-1.4-r44684 built by root @ linux-atlantis-be on a i686 running Linux on 2006-10-17 10:30:19 UTC

Please let me know if you require anything else
By: Olle Johansson (oej) 2006-10-17 10:34:31

This confuses me.

"As you can see, both dialogues are different." - how? It's the same tags and call id.

What am I missing here?
By: bcoppens (bcoppens) 2006-10-17 11:33:18

For the calling T.38 trigger, I guess the Via headers are different.
The response should indicate the same Via header.

For the called T.38 trigger, From header and To header are switched and the Via headers are not equal.

Sorry for not specifying
By: Olle Johansson (oej) 2006-10-17 12:28:23

The from/to header mismatch is something I'm working on in a separate branch. Hopefully that will be resolved soon.
By: bcoppens (bcoppens) 2006-10-18 05:39:39

Just inversing to/from would not be enough. You will have to take into account all headers from the origin T38 "re-invite". This is To/From and Via(branch).
By: dea (dea) 2006-11-10 20:23:38.000-0600

There was a bug where Asterisk would be unhappy if no audio codecs
were present, which looks to be present in attached logs.  That was
fixed sometime ago, and a small patch in 7844 deals with the transition
from RTP to UDPTL.

Seeking testers of that patch against branches/1.4 > 47337
By: Olle Johansson (oej) 2006-11-12 09:39:28.000-0600

I've committed some changes to t.38 today (1.4 and svn trunk). can you please re-test and see if any of that changes the states on your bugs? Thanks.
By: Marcel Barbulescu (marcelbarbulescu) 2006-11-15 10:06:31.000-0600

Just tested Asterisk SVN-branch-1.4-r47494 with a Sipura 2100 and a Cisco endpoint and T.38 passthrough works well now. Still have problems with Grandstream ATAs and the same Cisco endpoint, the signaling looks fine, UDPTL starts flowing, but the fax machines do not sync (that's probably not really related to this bug).
By: Olle Johansson (oej) 2006-11-15 15:37:55.000-0600

Can we agree to close this bug finally? Anyone still having issues?
By: dea (dea) 2006-11-15 15:59:40.000-0600

OEJ-
 I think the root cause has been addressed (damn I wish I had
gear to test with this to help).

I think I see something odd in the Cisco_T38_request.txt.  Am I reading
it right that Asterisk is sending the ACKs with the wrong CSeq?
By: bcoppens (bcoppens) 2006-11-16 00:48:34.000-0600

Tested with the latest 1.4 and fix seems to work for my setup
Cisco IOS Version 12.3(14)T3
Veraz version 5.5.5.20

tested with canreivite=no and yes - both working like a charm

see Log_16112006.txt enclosed
By: ivoc (ivoc) 2006-11-16 06:59:07.000-0600

oej:
T.38 pass-through works just fine, except I get BYE message from asterisk for lack of RTP activity in 20 sec /I have set rtptimeout=20 in sip.conf/
Config is SPA2102/3.3.6 firmware/ sending fax to Cisco through asterisk/SVN-branch-1.4-r47584/

When the T.38 call is set up with re-INVITE there are no audio/video capabilities present:
Capabilities: us - 0x50a (gsm|alaw|g729|ilbc), peer - audio=0x0 (nothing)/video=0x0 (nothing), combined - 0x0 (nothing)

Why does asterisk consider rtptimeout value in T.38 call, there are actually no RTP packets but T.38?
By: dea (dea) 2006-11-16 12:26:30.000-0600

ivec, if you are comfortable with a small manual edit, can you try this:

Find this section of code (near line 5066)
   ast_log(LOG_DEBUG, "Have T.38 but no audio codecs, accepting offer anyway\n");
return 0;

And add this line just above the return 0;
p->rtptimeout = 0;
By: Andrew Lindh (andrew) 2006-11-16 14:08:50.000-0600

It works better for me now using Sipura 2100 (v3.3.6) and Cisco AS5300 (IOS 12.3). T38fax shows up as the codec the cisco is using and the fax completes. But everything is on the same LAN so it's not a good real world test.
By: Olle Johansson (oej) 2006-11-16 14:47:14.000-0600

DEA: Absolutely - GOOD CATCH!!! I need to temporarily disable RTP timers if the T38 reinvite is accepted.
By: dea (dea) 2006-11-16 16:08:21.000-0600

I looked over the code, and I think there are a couple of candidates
for the best place to disable the rtptimeout.

Once we determing that the T38 handshake has completed and switch
t38.state to T38_ENABLED seems like best choice.  We seem to
switch to that state in a couple of places, and I haven't had a
chance to backtrack the call flow to identify the right one.

The converse has to be considered as well.  If the call starts out
with T38 and falls back to RTP, the timeout should be re-established.

Shall I keep digging towards a patch, or do you have a good idea where
you want to put the changes?
By: Andrew Lindh (andrew) 2006-11-20 09:50:52.000-0600

Rather than temporarily disabling the RTP timers can the T.38 traffic just update the RTP timer so there is still a "no-traffic" timeout in place? I guess you could make a new T.38 timout setting rather than use the RTP setting. It's partly the codec vs. protocol issue. But I think it's a good idea to keep a timer running so dead sessions are cleared.


By: Olle Johansson (oej) 2006-12-02 06:07:21.000-0600

I've added a function to disable RTP timers during fax transmission. If RTP keepalives are enabled, they will go on to keep the NAT binding open.

I did not re-enable them, since there's currently no function to stop UDPTL. Does any device send a re-invite back to audio after fax transmission? If so, we have to fix this too.

Please test - 1.4 svn r > 48199.


By: ivoc (ivoc) 2006-12-05 10:01:09.000-0600

NOT possible to test; it seems UDPTL packets are not forwarded by asterisk /SVN-oej-invitestate-1.4-r48215/ between both call legs : Cisco--UDPTL-->Asterisk--no_UDPTL_packets-->UA and vice versa.
By: Olle Johansson (oej) 2006-12-05 10:16:33.000-0600

ivoc: That's interesting facts so please upload a SIP debug so we can help you fix this. Just saying "it doesn't work" doesn't help me really. Thanks for a quick reply.
By: Serge Vecher (serge-v) 2006-12-05 10:24:34.000-0600

the following instructions will help you produce the log oej is looking for.

1) Prepare test environment (reduce the amount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterisk with the following command:
  'asterisk -Tvvvvvdddddgc | tee /tmp/verbosedebug.txt'
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Attach verbosedebug.txt to the issue.
By: ivoc (ivoc) 2006-12-06 08:43:15.000-0600

Attached 3 files:
UDPTL_tethereal_capture.txt, verbose_debug_no_UDPTL.txt
h263_no_path_to_translate.txt

where:
IP 10.3.0.1 Cisco
IP 10.0.0.1 openSER proxy
IP 10.2.0.1 SPA
IP 10.0.0.2 asterisk
1234 dialed number, 2222 ANI
Third file contains debug where can be seen one more issue:
when h263 codec is enabled in sip.conf, asterisk tries to do codec translation from h263 to slin and then send BYE message.


By: Olle Johansson (oej) 2006-12-06 09:21:12.000-0600

Can we please stick to the original problem in one bug report, thanks?
By: Serge Vecher (serge-v) 2006-12-06 10:36:34.000-0600

ivoc: h263_no_path_to_translate.txt does look like a bug, please file it separately.
By: ivoc (ivoc) 2007-01-24 02:55:57.000-0600

Still the same behaviour, UDPTLs are not forwarded in either way, tested w/ revision 51360.
Uploaded verbose_debug_no_UDPTL_r51360_wDEBUG.txt
By: Serge Vecher (serge-v) 2007-01-29 16:13:49.000-0600

ivoc: everything seems to be going well in verbose_debug_no_UDPTL_r51360_wDEBUG.txt until the Sipura decides to end a transaction with a 'BYE'. I think it's a problem in the Sipura, not Asterisk.
By: ivoc (ivoc) 2007-01-30 03:41:40.000-0600

This should be expected as long as the Sipura does not get any T.38 packets coming out from Asterisk /take a look at UDPTL_tethereal_capture.txt/
By: dea (dea) 2007-01-30 10:56:43.000-0600

I posted this in 7844, but it might help here as well:

This code in sip_write() ~line 3504 looks fishy:

    if (p->udptl && ast->_state != AST_STATE_UP)
        res = ast_udptl_write(p->udptl, frame);

There are no changes to T38 anywhere near the commit where
T38 stops working, but I seem to recall that there were a
number of changes/fixes to state state tracking around that
time.
By: Olle Johansson (oej) 2007-02-01 15:21:34.000-0600

We've tested with latest 1.4 from subversion and two Sipura 2100 and it now works with or without NAt and with or without reinvites.

Please test a.s.a.p. and confirm that it works for you too. Thanks!
By: ivoc (ivoc) 2007-02-05 02:42:46.000-0600

Thats right, it works fine now.
By: Joshua C. Colp (jcolp) 2007-02-05 10:25:11.000-0600

I'm comfortably that this issue has been fixed now, but if this is not the case please reopen. Thanks!