| 01:06.10 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-102-131-177.ks.ok.cox.net) |
| 01:15.14 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 01:17.13 | *** join/#asterisk cation21- (cation21@gateway/vpn/protonvpn/cation21) |
| 01:52.06 | *** join/#asterisk ghoti (~paul@dsl-rb-64-118-19-152.wtccommunications.ca) |
| 01:54.06 | *** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria) |
| 01:54.06 | *** join/#asterisk obrut (~obrut@static.108.201.69.159.clients.your-server.de) |
| 01:54.06 | *** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui) |
| 01:54.06 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
| 01:54.06 | *** join/#asterisk vancz (~vancz@unaffiliated/vancz) |
| 01:54.06 | *** join/#asterisk Maxxed (~Maxxed@nrgt.net) |
| 01:54.06 | *** join/#asterisk hvxgr (~wl2v_usrn@epjdn.zq3q.org) |
| 01:54.06 | *** join/#asterisk petris (~quassel@docker01.dallas.linode.host.petris.net) |
| 01:54.06 | *** join/#asterisk tris (tristan@camel.ethereal.net) |
| 01:54.06 | *** join/#asterisk Champi (Champi@damn.e-leet.be) |
| 01:54.58 | *** join/#asterisk tsal (~tsal@i59F52966.versanet.de) |
| 02:02.45 | *** join/#asterisk mr44er (~mr44er@dynamic-046-114-003-224.46.114.pool.telefonica.de) |
| 02:08.07 | *** join/#asterisk Typhon (~Typhon@dslb-088-066-107-040.088.066.pools.vodafone-ip.de) |
| 02:40.31 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 04:19.15 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 05:06.42 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 05:30.14 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 06:09.25 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 06:15.01 | *** join/#asterisk JAunis (~jean@lputeaux-658-1-51-39.w92-154.abo.wanadoo.fr) |
| 06:45.39 | *** join/#asterisk cryptic (~cryptic@142-196-139-017.res.spectrum.com) |
| 07:05.01 | *** join/#asterisk saint__ (~saint_@unaffiliated/saint-/x-0540772) |
| 08:29.08 | *** join/#asterisk tsal (~tsal@i59F52966.versanet.de) |
| 08:56.25 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 09:04.43 | *** join/#asterisk sudoneuron (~sudoneuro@garza.riseup.net) |
| 10:30.09 | *** join/#asterisk jkroon (~jkroon@165.16.204.110) |
| 10:52.08 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 11:15.24 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 12:01.02 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 12:07.22 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 12:07.58 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 12:22.23 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 13:20.00 | *** join/#asterisk rpifan (~rpifan@p200300d2672b5d007345ef678e3c0e86.dip0.t-ipconnect.de) |
| 13:21.35 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 13:31.27 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 13:31.28 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
| 13:52.47 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-honxkedkdpfemslt) |
| 13:52.47 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 13:56.11 | *** join/#asterisk mitrax (~mitrax@lfbn-ncy-1-607-219.w81-51.abo.wanadoo.fr) |
| 14:04.20 | mitrax | hello, with an asterisk ipbx is there any local setting that could cause call transfers *on the remote side* to fail? e.g local user A calls remote number through the IPBX, remote user B picks up, the communication is established and works until user B transfers the call to user C (same remote ipbx), at that point no audio can be heard anymore and the call fails. Is there any misconfiguration |
| 14:04.20 | mitrax | on the local side that could cause that? like codec renegociation or something? |
| 14:17.40 | mitrax | i would think it's something wrong on the remote side and that there's nothing i can do... but a user keeps complaining it happens very often with different remote parties and that they can't all have a problem. So, as i have limited experience with VOIP i thought maybe something completely eludes me |
| 14:30.29 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
| 14:30.58 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 14:34.28 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-lgurhpjixncscfbn) |
| 14:34.28 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:44.53 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 15:42.54 | orn | mitrax: generally it'll be an audio path issue, such as a NAT problem or direct media path problem |
| 15:43.40 | orn | mitrax: there are also multiple ways to transfer calls -- the PBX can handle it, the user agent can handle it (i.e. the end-device/softclient/whatever), which will bring further possible problems |
| 15:44.58 | orn | mitrax: best way to figure out what the issue is is to do a tcpdump and look at the SIP and RTP data, and see whether the media headers of the SDP are incorrect |
| 15:50.47 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 16:25.54 | mitrax | orn: sure but the issues you are listing are most likely to be on the remote side aren't they? the problem occurs when the remote party transfers the call to another user |
| 16:34.53 | mitrax | orn: everything works normally, i never get any blank calls, the only situation where this supposedly occurs (according to the user) is when a call is transfered between end-device by the remote side (on which i have no control) |
| 16:42.35 | orn | mitrax: not necessarily -- it could be an SDP originating from your side with wrong IP addresses or ports |
| 16:42.55 | orn | mitrax: just check the SIP packages as they leave your system, and see if you notice anything funny about the media description |
| 16:43.11 | orn | mitrax: and then check to see if you're actually transmitting and receiving RTP |
| 16:50.38 | mitrax | orn: but, there are like 4 PBX and the PSTN in between, MY PBX <=> MY VOIP PROVIDER PBX <=> PSTN <=> ... <=> REMOTE PARTY PBX, why would suddenly when a transfer is done between the remote party phones would MY pbx send invalid SDP packets? shouldn't the transfer be completely transparent from my side? |
| 16:52.56 | orn | mitrax: as I said, there are multiple ways to do the tansfer. Depending on how it's done, the remote party either knows about it, or not. If you can call the remote party side without audio issues, the problem is likely on your end. |
| 16:53.34 | orn | mitrax: If I had to guess, I'd say the problem is either between the transfering user and your PBX (if the user agent is handling the transfer), or your PBX and your phone provider |
| 16:54.13 | orn | mitrax: in the second case, your SDP to your provider might for example have an internal RFC1918 IP address |
| 16:54.22 | orn | mitrax: how is the transfer being done? |
| 16:57.28 | mitrax | orn: it's someone (a secretary) at the remote side transfering the call using her phone i guess, i don't know about their infrastructure, an attended transfer most likely, there's supposedly a on-hold music before the target person picks up, but audio goes blank for us as soon as the transfer is done |
| 16:58.35 | orn | mitrax: is she using a softclient or actual phone? is she transferring using the DTMF methods or built-in? |
| 16:59.11 | mitrax | orn: i have no idea, i would have to ask, it's a third party (customer) that we're just calling |
| 16:59.19 | orn | mitrax: in any effect, you're going to need to see how the actual transfer is performed to figure out where it's going wrong |
| 17:00.15 | orn | mitrax: you should at least do a capture where you can, and see if you can spot anything there |
| 17:00.35 | orn | mitrax: you can see if the SIP messages you see are okay and if you have 2-way RTP |
| 17:01.25 | mitrax | okay |
| 17:01.27 | mitrax | thanks |
| 17:02.17 | orn | mitrax: good luck |
| 17:03.14 | orn | mitrax: to clarify, i thought you were the one doing the transfer initially, and not the third party |
| 17:03.43 | orn | mitrax: so everything is flipped on its head -- i believe the problem resides on the transferring end, esp. if it is an internal PBX transfer that isn't leaving their system |
| 17:04.07 | orn | mitrax: but in some cases these things are done end-to-end, and if that is happening, there MIGHT conceivably something be wrong on your end, but it's unliklely |
| 17:10.19 | mitrax | orn: no no, they're the one doing the transfer, that's why i was doubtful it could be something on my end, sorry if i've been unclear |
| 17:20.27 | *** topic/#asterisk by bford -> #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 18.4.0, 16.18.0 (2021/05/06) Final Bugfix: 13.38.2, 17.9.3 (2021/03/04); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
| 17:21.14 | orn | mitrax: i probably didn't read it properly :) |
| 17:31.54 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 17:55.16 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 18:20.21 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 18:45.34 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 18:46.14 | *** join/#asterisk sinaowolabi (~Sina@105.112.147.249) |
| 18:52.31 | *** join/#asterisk rpifan (~rpifan@p200300d2672b5d00e056ecb696690cbe.dip0.t-ipconnect.de) |
| 19:17.20 | *** join/#asterisk pramsky (~pramsky@23.252.62.194) |
| 19:38.43 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 20:18.14 | ShaunR | I have a gosub running via dial to a queue member, is there a way I could disable the queue from trying the same member again while that gosub is running? |
| 20:18.49 | ShaunR | Wondering if I could set a state for the device or something, ideally one that would reset if/when the member hangs up. |
| 20:35.46 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 20:51.00 | igcewieling | Heh, one of our sales reps thinks we can just add Microsoft Teams support to our hosted platform because they asked. |
| 21:04.59 | seanbright | igcewieling: press the make-it-work button, come on |
| 22:05.52 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 22:08.03 | *** join/#asterisk znf (~ibm86@toaster.linge-ma.ro) |
| 22:19.31 | *** join/#asterisk Typhon (~Typhon@dslb-088-066-104-036.088.066.pools.vodafone-ip.de) |
| 22:27.05 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
| 23:53.02 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-biesvbmmabqmfpct) |