Understanding T.38 negotiation

Asterisk Asterisk Fax
1

We’re trying to resolve T.38 fax issues, and hoping someone can help us understand the negotiation that takes please. Your advice would be much appreciated!

The scenario is that an ATA makes a call to Asterisk, Asterisk makes a call to the PSTN, and the PSTN delivers the call to a different Asterisk destination. The T.38 re-INVITEs are below, and in sip.conf there is:
t38pt_udptl = yes
t38_udptl = yes
t38pt_rtp = no
t38pt_tcp = no

You can see that the first Asterisk changes the T38FaxMaxDatagram and T38FaxUdpEC which are received from the ATA for the outbound leg to the PSTN. Why does Asterisk do this?

Then the second Asterisk receives different values yet again from the PSTN for the T38FaxMaxDatagram and T38FaxUdpEC. Is it normal and acceptable for intermediate parties to do this, and doesn’t doing so upset the T.38 negotiation?

Thanks in advance for any insight into what is going on here.

<— SIP read by Asterisk from the ATA which is sending the fax —>
INVITE sip:4081234567@11.22.33.72:5070 SIP/2.0
…
v=0
o=1009548484 8000 8001 IN IP4 22.33.44.254
s=SIP Call
c=IN IP4 22.33.44.254
t=0 0
m=image 13042 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:280
a=T38FaxUdpEC:t38UDPRedundancy

<— SIP transmit from Asterisk to the PSTN —>
INVITE sip:4081234567@33.44.55.188:5060 SIP/2.0
…
v=0
o=root 171120754 171120755 IN IP4 11.22.33.72
s=ES8
c=IN IP4 11.22.33.72
t=0 0
m=image 4275 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:187
a=T38FaxUdpEC:t38UDPFEC

<— SIP read from the PSTN on the receiving side —>
INVITE sip:4081234567@11.22.33.51:5060;transport=tcp SIP/2.0
…
v=0
o=Sonus_UAC 902215 1833 IN IP4 33.44.55.12
s=SIP Media Capabilities
c=IN IP4 33.44.66.150
t=0 0
m=image 64716 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:262
a=T38FaxMaxDatagram:176
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv

2

Asterisk has a UDPTL stack in it which handles packet sizing and error correction, so each side can be independently negotiated therefore the SDP can differ like so.

3

Thank you for that @jcolp ! So does that mean that different T38FaxMaxDatagram and T38FaxUdpEC values shouldn’t cause a failure?

If that’s the case then how does the “UDPTL asked to send X bytes when far end only prepared to accept Y bytes; data loss will occur” error occur?

4

I don’t think it should cause a failure, and I’m not aware of any current issues. I’d suggest providing an actual full debug log including SIP trace instead of bits and pieces.

5

Thanks again @jcolp . The fax is failing on an ATA and so far we haven’t got a clear error message from it, but if we get something useful I’ll let you know. I was hoping to generally understand how T.38 negotiates different ends supporting different values.