[Home]

Summary:ASTERISK-13253: [patch] Multi-host T.38 negotiation
Reporter:Arcadiy Ivanov (arcivanov)Labels:
Date Opened:2008-12-21 19:16:06.000-0600Date Closed:2011-06-07 14:03:05
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) normalize_t38_datagram_size_1.4.diff
( 1) normalize_t38_datagram_size_1.6.0.diff
( 2) normalize_t38_datagram_size_1.6.1.diff
Description:Below please find the refined SIP negotiation log for the following setup:

Gafachi (64.192.112.13, sip.gafachi.com) <=> NAT <=> Asterisk Proxy (192.168.157.42, pbx1) <=> Grandstream HT2886 (192.168.157.11, fax1)

NOTE: The Asterisk is 1.4.22 patched with "relaxed-T.38" and "boolean handling" patches from issue ASTERISK-1380976.

Potential Problem #1
   Note the a=T38FaxMaxBuffer:512, a=T38FaxMaxDatagram:512 in Asterisk's response to HT286. According to udptl.c we're not even capable of reading UDPTL packets that exceed LOCAL_FAX_MAX_DATAGRAM, which is defined as 400. Assuming that Gafachi and HT286 would have agreed on 512 (not in this case though) could Asterisk even pass-through those packets? Are we passing the packets between the peers without reading them at all? Or does the bridge try to analyze the UDPTL packets to any extent before forwarding them? I can't get my head around the entire udptl.c to answer that question.

Potential Problem #2
    Depending on the answer to the question in #1 the same might apply to error correction negotiation mechanisms and rate management negotiations.



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

==========================================================================
<--- SIP read from 192.168.157.11:5060 --->
INVITE sip:fax1@192.168.157.42 SIP/2.0
Via: SIP/2.0/UDP 192.168.157.11;
From: <sip:fax1@fax1.myhomedomain>;
To: "unknown" <sip:fax1@192.168.157.42>;
Contact: <sip:fax1@192.168.157.11;user=phone>
Supported: replaces, timer
Call-ID: 06a419a15b4a4dc72eed6f9606f4d807@192.168.157.42
CSeq: 36938 INVITE
User-Agent: Grandstream HT287 1.1.0.30
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE
Content-Type: application/sdp
Content-Length: 353

v=0
o=fax1 8000 8001 IN IP4 192.168.157.11
s=SIP Call
c=IN IP4 192.168.157.11
t=0 0
m=image 60200 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:280
a=T38FaxUdpEC:t38UDPRedundancy


=======================================================================================


Transmitting (no NAT) to 64.192.112.13:5060:
INVITE sip:unknown@64.192.112.13 SIP/2.0
Via: SIP/2.0/UDP iphidden:5060;rport
From: <sip:numberhidden@iphidden>;
To: "unknown" <sip:unknown@sip.gafachi.com>;
Contact: <sip:numberhidden@iphidden>
Call-ID: 29dd0ea04d5c3f5253b32d0a496d9bd3@64.192.112.13
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
X-asterisk-info: SIP re-invite (T38 switchover)
Content-Type: application/sdp
Content-Length: 317

v=0
o=root 22070 22071 IN IP4 iphidden
s=session
c=IN IP4 iphidden
t=0 0
m=image 60122 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxMaxRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:280
a=T38FaxMaxDatagram:280
a=T38MaxDatagram:280
a=T38FaxUdpEC:t38UDPRedundancy


=======================================================================================


<--- SIP read from 64.192.112.13:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP iphidden:5060;received=iphidden;rport=5060
From: <sip:numberhidden@iphidden>;
To: "unknown" <sip:unknown@sip.gafachi.com>;
Call-ID: 29dd0ea04d5c3f5253b32d0a496d9bd3@64.192.112.13
CSeq: 102 INVITE
Server: Gafachi UAS v110.08
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Contact: <sip:unknown@64.192.112.13>
Content-Type: application/sdp
Content-Length: 283

v=0
o=root 942089705 942089706 IN IP4 67.216.37.18
s=session
c=IN IP4 67.216.37.18
t=0 0
m=image 13966 udptl t38
a=T38FaxVersion:0
a=T38FaxRateManagement:transferredTCFlocalTCF
a=T38FaxUdpEC:t38UDPFEC
a=T38FaxMaxBufferSize:2000
a=T38MaxDatagram:512
a=T38FaxMaxRate:14400


=======================================================================================


<--- Reliably Transmitting (no NAT) to 192.168.157.11:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.157.11;;received=192.168.157.11
From: <sip:fax1@fax1.myhomedomain>;
To: "unknown" <sip:fax1@192.168.157.42>;
Call-ID: 06a419a15b4a4dc72eed6f9606f4d807@192.168.157.42
CSeq: 36938 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:fax1@192.168.157.42>
Content-Type: application/sdp
Content-Length: 312

v=0
o=root 22070 22071 IN IP4 192.168.157.42
s=session
c=IN IP4 192.168.157.42
t=0 0
m=image 60128 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxMaxRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:512
a=T38FaxMaxDatagram:512
a=T38MaxDatagram:512
a=T38FaxUdpEC:t38UDPFEC


=======================================================================================


Transmitting (no NAT) to 64.192.112.13:5060:
ACK sip:unknown@64.192.112.13 SIP/2.0
Via: SIP/2.0/UDP iphidden:5060;rport
From: <sip:numberhidden@iphidden>;
To: "unknown" <sip:unknown@sip.gafachi.com>;
Contact: <sip:numberhidden@iphidden>
Call-ID: 29dd0ea04d5c3f5253b32d0a496d9bd3@64.192.112.13
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


=======================================================================================


<--- SIP read from 192.168.157.11:5060 --->
ACK sip:fax1@192.168.157.42 SIP/2.0
Via: SIP/2.0/UDP 192.168.157.11;branch=z9hG4bK362615d6e3fcadb0
From: <sip:fax1@fax1.myhomedomain>;
To: "unknown" <sip:fax1@192.168.157.42>;
Contact: <sip:fax1@192.168.157.11;user=phone>
Call-ID: 06a419a15b4a4dc72eed6f9606f4d807@192.168.157.42
CSeq: 36938 ACK
User-Agent: Grandstream HT287 1.1.0.30
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE
Content-Length: 0
Comments:By: Arcadiy Ivanov (arcivanov) 2008-12-21 19:16:46.000-0600

Please add "Related-to" ASTERISK-1380976.


By: Arcadiy Ivanov (arcivanov) 2008-12-21 20:34:06.000-0600

I might be wrong, but I can't find ast_udptl_bridge to be used anywhere in Asterisk. ast_udptl_read and ast_udptl_write, on the other hand, appear to be used in chan_sip. Can someone with experience weigh-in whether my concerns above are valid?
By: Joshua C. Colp (jcolp) 2008-12-22 08:51:27.000-0600

Packets are not forwarded unaltered and the ast_udptl_bridge code is not used. It is entirely possible and acceptable for the two ends to negotiate independently. Data is received on one udptl port and then encapsulated in an Asterisk frame. It is then written out the other udptl port with a packet created following the new parameters that have been negotiated (such as error correction type). Are you seeing an issue somewhere?
By: Arcadiy Ivanov (arcivanov) 2008-12-22 09:05:21.000-0600

Yes, Gafachi faxing stopped working for me with HT286 and I'm trying to isolate the root cause. Obviously I don't have access to either HT286 firmware source or Gafachi's setup so I'm trying to figure out whether Asterisk could be a problem.
By: Joshua C. Colp (jcolp) 2008-12-22 09:07:54.000-0600

It was working previously? Have you gotten a udptl debug? Tried a direct connection to throw Asterisk out of the loop? Change anything recently?
By: Arcadiy Ivanov (arcivanov) 2008-12-23 22:12:44.000-0600

1) Yes, it was working previously.

2) I have used another provider (IPcomms.net) with the same result: T.38 is negotiated some UDPTL traffic goes back and forth and the connection is abruptly terminated. I also found that firmware auto-update on HT286 sneaked in a new version, thus making the ATA the primary suspect.
By: Arcadiy Ivanov (arcivanov) 2008-12-23 22:36:14.000-0600

My previous note notwithstanding, let's consider the following scenario:

X <=> Asterisk <=> Y

1) Let's assume that X and Y can support datagrams of 512 bytes.
2) Y detected fax tone, sends re-invite that includes: a=T38FaxMaxDatagram:512.
3) Asterisk processes the re-invite and sends it to X with the following attributes: a=T38FaxMaxBuffer:512, a=T38FaxMaxDatagram:512
4) X sends a 200 OK to Asterisk with, a=T38FaxMaxBuffer:512, a=T38FaxMaxDatagram:512; then ACKs.
5) Asterisk sends 200 to Y with a=T38FaxMaxBuffer:512, a=T38FaxMaxDatagram:512.
6) Y ACKs.

Asterisk is unable to support 512 byte datagrams, yet both X-Asterisk and Y-Asterisk channels have negotiated the 512 byte datagrams. This is due to the fact that in chan_sip.c (lines 7326 - 7331) the joint capability will NOT take datagram sizes under consideration. The udptl.c (lines 1268 - 1274) will silently max out the datagram sizes at LOCAL_FAX_MAX_DATAGRAM, that is defined as 400 (line 89).

I unfortunately lack the physical hardware to reproduce this scenario.
However, the fix (ensuring that joint capability always caps the datagram/buffer sizes at maximum supported by Asterisk proxy) should be completely benign with respect to existing clients.

I'll submit a patch fixing this scenario for consideration.

Note: all code references are for branch 1.6.1,rev. 166730.
By: Joshua C. Colp (jcolp) 2009-03-10 14:27:40

As a result of another issue the maximum size was raised, which means this has already been taken care of another way.