[asterisk-users] T.38 not working - help needed with log interpretation

Recursive lists at binarus.de
Tue Dec 2 02:24:39 CST 2014


Dear all,

I have the following situation:

Local T.38 endpoint <-> ASTERISK <-> SIP provider (with T.38 support)

I am trying to send a fax from my local T.38 endpoint to arbitrary external fax numbers (which I am not in control of, so I don't know if the other end supports T.38, is connected to a PBX, who is their provider, and so on), of course trying to use T.38 at least from my local endpoint to the provider's gateway. This always fails.

I have recorded the respective network traffic with Wireshark. From the log, I can see that the training is successful. The transmission fails exactly at the moment when it should switch to T.38. I think that my endpoint is misbehaving in that situation and wanted to make sure that I am right by asking the experts.

Here is an excerpt of the log (the part which I am considering relevant):

No.     Time        Source                Destination           Protocol Length Info
  14308 16.089226   192.168.20.48         192.168.20.14         RTP      214    PT=ITU-T G.711 PCMU, SSRC=0x8A086DE, Seq=63333, Time=23840
  14311 16.109178   83.125.8.155          192.168.20.48         RTP      214    PT=ITU-T G.711 PCMU, SSRC=0x71FD8337, Seq=41621, Time=24000
  14312 16.110788   192.168.20.48         192.168.20.14         RTP      214    PT=ITU-T G.711 PCMU, SSRC=0x8A086DE, Seq=63334, Time=24000
  14313 16.118096   83.125.8.71           192.168.20.48         SIP/SDP  988    Request: INVITE sip:000387839679 at 79.211.71.113:64280, in-dialog | 
  14314 16.118466   192.168.20.48         83.125.8.71           SIP      633    Status: 100 Trying | 
  14315 16.118739   192.168.20.48         192.168.20.14         SIP/SDP  923    Request: INVITE sip:bCo9m7OfHWK2Y2sb at 192.168.20.14:5060, in-dialog | 
  14321 16.169196   192.168.20.14         192.168.20.48         SIP/SDP  982    Status: 200 OK | 
  14322 16.170900   192.168.20.48         192.168.20.14         SIP      476    Request: ACK sip:bCo9m7OfHWK2Y2sb at 192.168.20.14:5060 | 
  14323 16.171160   192.168.20.48         83.125.8.71           SIP/SDP  951    Status: 200 OK | 
  14329 16.208396   83.125.8.71           192.168.20.48         SIP      559    Request: ACK sip:000387839679 at 79.211.71.113:64280 | 
  14453 17.611041   192.168.20.14         192.168.20.48         SIP/SDP  1204   Request: INVITE sip:004921123704144 at spock-asterisk.home.omeganet.de:5060, in-dialog | 
  14454 17.611304   192.168.20.48         192.168.20.14         SIP      577    Status: 100 Trying | 
  14649 22.611128   192.168.20.48         192.168.20.14         SIP      612    Status: 488 Not acceptable here | 
  14650 22.661007   192.168.20.14         192.168.20.48         UDP      42     Source port: 5060  Destination port: 5060[Malformed Packet]
  14651 23.111663   192.168.20.48         192.168.20.14         SIP      612    Status: 488 Not acceptable here | 
  14652 23.162024   192.168.20.14         192.168.20.48         UDP      42     Source port: 5060  Destination port: 5060[Malformed Packet]
  14653 24.112190   192.168.20.48         192.168.20.14         SIP      612    Status: 488 Not acceptable here | 
  14654 24.162038   192.168.20.14         192.168.20.48         UDP      42     Source port: 5060  Destination port: 5060[Malformed Packet]
  14655 25.838900   192.168.20.14         192.168.20.48         SIP      484    Request: BYE sip:004921123704144 at 192.168.20.48:5060 | 
  14656 25.839076   192.168.20.48         192.168.20.14         SIP      519    Status: 500 Server error | 
  14657 26.110508   192.168.20.48         192.168.20.14         SIP      612    Status: 488 Not acceptable here | 
  14658 26.161125   192.168.20.14         192.168.20.48         UDP      42     Source port: 5060  Destination port: 5060[Malformed Packet]
  19910 30.111548   192.168.20.48         192.168.20.14         SIP      612    Status: 488 Not acceptable here | 
  19911 30.162368   192.168.20.14         192.168.20.48         UDP      42     Source port: 5060  Destination port: 5060[Malformed Packet]

192.168.20.14 is my local T.38 endpoint, 192.168.20.48 is ASTERISK, and 83.125.8.xxx are the provider's gateways / servers. My interpretation of the log is as follows:

- The first three packets are the end of the training (quite sure about that)
- Packets 14313, 14314: The provider re-invites asterisk for T.38 (confirmed by viewing the packet's details), asterisk answers "Trying ..." to the provider
- Packets 14315, 14321, 14322: Asterisk re-invites the local endpoint (again confirmed by looking into the packet's details), the local endpoint answers "OK", and asterisk ACKs the OK.
- Packets 14323, 14329: Asterisk accepts the invitation from the provider by sending "OK" to the provider, and the provider ACKs the OK.
- Packets 14453, 14454 and 14649: The local endpoint again tries to re-invite asterisk for T.38 (confirmed by looking into the packet's details), Asterisk answers "Trying" and then refuses, saying "488: Not acceptable here"
- From then on, things go horribly wrong (probably, the local endpoint is still expecting G.711 packets, but gets T.38 packets)

I have provided all packets which are relevant. The packet numbers are not contiguous since asterisk currently is on a test server which runs many other services (the packets of which I have filtered out).

I didn't want to clutter this post too much, thus I have only provided an overview and not the details of each packet. Furthermore, please forgive me that it's much easier for me to read Wireshark's logs than Asterisk's logs. Of course, I will provide every log anybody trying to help out asks me for.

But my first question is a very simple one:

>From the log above, I am quite sure that switching to T.38 is done right up to (and including) packet 14329. I think that my local endpoint then misbehaves by again re-inviting asterisk for T.38 (as all parties already have agreed upon T.38).

Thus, is my endpoint really misbehaving, and if yes, is there anything I can do about it on Asterisk's side? Or do the SIP/T.38 state machines allow such (seemingly superfluous) re-invite, and it's Asterisk's fault to answer with 488?

Thank you very much,

Recursive



More information about the asterisk-users mailing list