Help with SPA112 and T38 UDPTL

[CPORich]

How do i configure and see that my spa112 is using UDPTL over RTP?

[Dan Lukes]

Just catch the communication and look at it ...

[CPORich]

Dan,

Thank you for the response. I can see UDPTL working on the PBX logs.

Maybe my question should be, can I capture that communcation on the log from the ATA? or do i need to use wireshark or similar?

here are cliffs from ATA log, I took out the redundant info.

Dec 29 20:40:07 SPA112 kern.info [17212101.496000] voice_request_start_chan audioMode 0
Dec 29 20:40:08 SPA112 user.notice sprvoip: cmd - 5, response 46

Dec 29 20:40:12 SPA112 daemon.notice msgswitchd[164]: MSGSWD RTCP Reqt len 12 Data 2,3523800,1082497600,156
Dec 29 20:40:12 SPA112 user.notice sprvoip: cmd - 5, response 46

Dec 29 20:40:33 SPA112 daemon.notice msgswitchd[164]: MSGSWD RTCP Reqt len 12 Data 2,0,5,156
Dec 29 20:40:33 SPA112 user.notice sprvoip: cmd - 12, response 48

Dec 29 20:40:33 SPA112 kern.warning [17212127.552000] voice_release, chan: 0
Dec 29 20:40:43 SPA112 daemon.notice msgswitchd[164]: MSGSWD RTCP Reqt len 12 Data 2,3524240,1082497600,156

[Dan Lukes]

I recommended you "catch tne communication: not "check logs" (moreover you checked kernel syslog which contain no information related to Voice Application activity) . But if you PBX claimed the SPA112 has used UDPTL for a call, then you can assume the UDPTL has been used by SPA112 for such call.

If you wish to be firmly convinced, catch the call data (e.g. SIP as well as RTP packets), not the logs on either side.

---

can I capture that communcation on the log from the ATA? or do i need to use wireshark or similar?

You need configure SPA112 to send log over the wire to a syslog server. Note that there are TWO logs on SPA112. The first one is kernel log (it's the log you disclosed). It have little or no value for you most of time. The second one is log of Voice Application  - configure both log and debug (higher level possible). It's the log you wish to read.

Transmitted log records can be received by dedicated syslog server or by a generic packet catching tool like wireshark. Ask your local network administrator for help.

But once more - if you wish to verify details of particular call, catch call itself instead of just logs.