| 00:01.31 | *** join/#asterisk hfb (~hfb@47.139.23.240) |
| 00:47.21 | *** join/#asterisk hfb (~hfb@47.139.23.240) |
| 00:55.06 | *** join/#asterisk mikaey (~mikaey@rrcs-76-79-39-174.west.biz.rr.com) |
| 01:01.11 | mikaey | Hey all...I could use some help figuring out a T.38 issue. I'm about at my wit's end trying to figure this one out. |
| 01:06.27 | mikaey | Asterisk 16.2.1, FreePBX 15.0.16.81. I've got a Ricoh MFC that's *supposed* to be SIP/T.38 capable. I'm trying to receive a fax. In packet captures, I can see a session getting established, the Ricoh sends CED, several v21-preambles, NSF, CSI, DIS/DSR, then no-signal. The remote side sends a v21-preamble, TSI, DCS, no-signal, then v17-14400-long-training. And then the about 0.9 seconds later, the Ricoh starts over -- it sends severa |
| 01:08.37 | *** join/#asterisk UncleKiwi (~UncleKiwi@unaffiliated/unclekiwi) |
| 01:09.55 | mikaey | From what I'm seeing, the remote end is *supposed* to send a t4-non-ecm-data:v17-14400 after the v17-14400-long-training -- but it never shows up. |
| 01:24.33 | mikaey | The only thing I can think of is that the Ricoh isn't waiting long enough for the t4-non-ecm-data:v17-14400 to come in? In the packet capture, it looks like there's less than 1 second between when the v17-14400-long-training and when the Ricoh starts firing off v21-preambles/NSFs/CSI/DIS (and V.14 says that the long training lasts for 1.4 seconds)...but I don't know if that's indicative of a bad T.38 implementation or if something else |
| 01:34.42 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 02:21.34 | *** join/#asterisk tsal (~tsal@i59F5FE84.versanet.de) |
| 03:42.36 | *** join/#asterisk electronic_eel (~quassel@213.240.182.235) |
| 03:56.11 | *** join/#asterisk bmg505 (~leon@41.144.151.107) |
| 03:57.01 | *** join/#asterisk Zombie (~masterz@h221.23.191.173.dynamic.ip.windstream.net) |
| 03:58.29 | Zombie | Can Iask a conceptual question? Would there be a way, using SIP in conjunction with XMPP, that I could call an XMPP user, over SIP, Peer to Peer, without an ITSP being involved? |
| 05:01.34 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-mswyjikntrtkcpuc) |
| 05:50.42 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
| 05:50.54 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 06:48.39 | *** join/#asterisk jeffspeff (~overyande@209.141.208.197) |
| 06:49.47 | drmessano | Zombie: Why is XMPP involved? |
| 06:49.59 | drmessano | You don't call an XMPP user over SIP |
| 06:51.28 | Zombie | Its more of a DNS like mechanism for finding a user. |
| 06:51.40 | Zombie | sort of like DNS A or SRV Records. |
| 06:53.04 | drmessano | That's not really a great analogy |
| 06:53.13 | drmessano | I can call a SIP user with user@host |
| 06:53.17 | drmessano | using IP or DNS |
| 06:53.24 | drmessano | I don't need middleware |
| 06:57.22 | Zombie | Thats what I was referring to. |
| 06:57.40 | drmessano | That has nothing to do with XMPP |
| 06:58.50 | drmessano | XMPP wouldn't even help with that |
| 07:34.29 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 08:12.28 | *** join/#asterisk n0tiz (~n0tiz@82-69-15-38.dsl.in-addr.zen.co.uk) |
| 08:43.52 | *** join/#asterisk javi404 (~quassel@unaffiliated/javi404) |
| 11:10.19 | *** join/#asterisk [sr] (~kvirc@pal-213-228-163-73.netvisao.pt) |
| 12:26.01 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 13:33.37 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 13:43.15 | *** join/#asterisk MarkSX (~MarkSX@unaffiliated/marksx) |
| 14:12.32 | *** join/#asterisk n0tiz (~n0tiz@82-69-15-38.dsl.in-addr.zen.co.uk) |
| 14:27.02 | Kobaz | Gooooood morning |
| 14:27.21 | Kobaz | Could someone help me translate this error message? |
| 14:27.22 | Kobaz | https://file.io/ja9zbWmoscbv |
| 14:30.50 | Samot | Nothing there |
| 14:31.54 | Kobaz | it's an mp3 |
| 14:32.02 | Kobaz | there's a download link, lemme try another way |
| 14:32.31 | Kobaz | aaah this site auto deletes |
| 14:32.36 | Kobaz | never used file.oi before. okay lemme redo |
| 14:33.06 | Kobaz | https://filebin.net/b5x5tkrf9bw7rml9 |
| 14:33.11 | Kobaz | k should be better |
| 14:34.55 | Kobaz | i suppose the first step would be trying to figure out what language this is in |
| 14:35.07 | Kobaz | One of our guys said possibly some sort of arabic |
| 14:35.43 | Kobaz | which is kind of weird... this is a message that's coming up when dialing the Bahamas |
| 14:46.28 | *** join/#asterisk n0tiz (~n0tiz@82-69-15-38.dsl.in-addr.zen.co.uk) |
| 15:02.31 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 15:19.36 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-smkzlhpgiunoouvk) |
| 15:19.36 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:22.18 | Samot | So is the call answered? |
| 15:22.25 | Samot | Is this early media playback? |
| 17:08.50 | Kobaz | this is a full answer not early media |
| 17:08.51 | Kobaz | Samot: from your question earlier |
| 17:08.52 | Kobaz | .... had to run out |
| 17:09.32 | Samot | So a 200 OK |
| 17:09.47 | Samot | Which means something is answering the call and playing that recording back. |
| 17:57.58 | *** join/#asterisk hfb (~hfb@47.139.23.240) |
| 18:18.14 | *** join/#asterisk hfb (~hfb@47.139.16.87) |
| 18:29.42 | Kobaz | Exactly |
| 18:29.49 | Kobaz | I just don't know what the message is saying |
| 18:29.55 | *** join/#asterisk ckb (~ckb@unaffiliated/ckb) |
| 18:30.08 | Kobaz | No one I've asked can figure out what language this is |
| 19:18.24 | *** join/#asterisk akp55_ (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 19:45.47 | *** join/#asterisk imcdonald (~imcdona@2602:41:642e:a610:70c0:b73b:da38:107d) |
| 21:17.02 | Kobaz | trying to remember the guy who maintains a NANP database of phone numbers and switch types? |
| 21:17.13 | Kobaz | there's a website and a lookup tool... drawing a blank |
| 22:33.34 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
| 22:39.19 | Kobaz | fun |
| 22:39.39 | Kobaz | Samot: just got this back from our main term carrier: Every so often issues routing to the Caribbean come up that we have to do pretty extensive testing for. I have experienced dance music, foreign recordings in various languages, and even garden variety shows (actual talks about gardening).. My general theory is that it is a problem with either a ULC or term carrier - possibly providing false answer for fraudulent reasons or just having general technical |
| 22:39.39 | Kobaz | problems with their network. |
| 23:06.53 | *** join/#asterisk [TK]D-Fender (~joe@modemcable142.109-203-24.mc.videotron.ca) |
| 23:19.27 | *** join/#asterisk retentiveboy (~retentive@2601:cf:4500:5ea3:662b:9874:7b4d:ad6) |
| 23:27.23 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 23:59.01 | *** join/#asterisk ckb (~ckb@unaffiliated/ckb) |