Scott1234

On an iPhone under recent it does have a sub section that says "Phone System Audio" for these calls to distinguish them at least, and if you are presenting the Group Name it will have that info as well.

FYI when I was playing around with the beta for OpenAI the AU numbers seem to work correctly in that build. 1300/1800/13/local etc. Everything has corrected spacing with the visual presentation once dialled except for the 8-digit local which is just mashed together as one number instead of the space xxxx xxxx, but at least its progress. when you use an area code it will space it all correctly i.e. xx xxxx xxxx.

I am curious how you are doing the transfer? care to share more of your config.

Thanks, tested working. Also noticed in the beta the AU numbers have been fixed, thanks.

Yep please fix.

I would have thought something like this would work, but no luck. !^61299887([0-9]{2})$!1\1!u! Not sure why you would want to use an expression other than just map the DID?

We just need parks implemented in the app then it can be easier

what's the release notes for 39?

Thanks, yeah not ready for 69.3.2 yet. The last update broke AU number handling, we are still waiting for that to be fixed. Before I look at it again.

I notice inbound pushed calls to iOS app are hit and miss. For example, if I test with back-to-back calls (using call q), on the first call I can get pushed to the iOS app then if I hang up and call back simulating say another call I don't get a push. If I wait say 30 seconds and try again it works. This seems to be most apparent with my Call Q Setup. I have a primary call Q with ring back tone and if not answered in 10 seconds it sends the call off to a waiting call Q with background music and messages, frequently when the call gets to the 2nd call Q the push won't work to the iOS device and I was missing customer calls. v68.0.38 I see this in the logs right after the push that does not work, not sure if related. [9] 16:15:18.069 Message repetition, packet dropped Also some more, when it does not work. [7] 16:19:45.609 https:push-au.vodia.net:443: DNS A returned 170.64.177.131ⓘ [7] 16:19:45.609 https:push-au.vodia.net:443: Connect to 170.64.177.131ⓘ [9] 16:19:45.657 https:push-au.vodia.net:443: Send request (453 bytes)ⓘ POST / HTTP/1.1 Host: push-au.vodia.net Content-Type: application/json Content-Length: 356 {"code":"59QR36TQ4BEH","message":"{\"data\":{\"message\":\"{\\\"id\\\":\\\"564\\\"}\",\"forceStart\":\"1\"},\"to\":\"a@28724EF038CAF058F4016ACD24A098FB5F50E0237DD03CBAAB6F0D0E860FDA7A@8F6CD1617DC8CCFA1690E327E237EBD7072BB614E6E4A35E250AC8D304D12076\",\"priority\":\"high\"}","callid":"4686bd54@pbx","number":"XXXXXX6175","name":"call blast (08 XXX XXX)"} [9] 16:19:45.657 Initialize TLS connectionⓘ [9] 16:19:45.813 Received 145 bytesⓘ HTTP/1.1 404 Not Found Date: Tue, 06 Aug 2024 08:19:45 GMT Connection: keep-alive Keep-Alive: timeout=5 Transfer-Encoding: chunked [7] 16:19:45.813 /: Return code 404 (7 bytes)ⓘ Invalid [8] 16:19:45.813 /: Return headersⓘ Date: Tue, 06 Aug 2024 08:19:45 GMT Connection: keep-alive Keep-Alive: timeout=5 Transfer-Encoding: chunked

V 68.0.38 Previously at some point when a Q was using cell phone forking the Q would re-cycle dialling the end point's paired cell so if they missed it (or so I thought), they could try again on the next pass (this is using the press 1 option to connect), now the system only calls the extensions paired cell once, until it hits the global maximum ring duration setting and starts the process over again. Meaning the end user has to wait ages to get another attempt to answer, this behaviour has changed at some point, I think. I thought ok no problem I will use the After hearing ringback for (s) ... or If the caller already waited longer than ... to cycle it back to the same Q, this seems work once, then the call does not cycle the Q again. It does seem to preserve its position in the Q without re playing the initial greeting on the first cycle, which is fine. If there is no active registration on the extension, it works fine, multiple attempts to the cell. I am guessing, because when a phone is registered its waiting for a cancel request to come from that end point. Is there a way for it to accept the mobile cancel/timeout request and reprocess that leg?

If it's going to get fixed, can we get it fixed in all areas, so presentation is uniform and correct with spacing. The only ones I know of that don't space/present correctly are, Toll Free/Special Rate numbers, 1800 = (1800) XXX XXX 1300 = (1800) XXX XXX 13 = (13) XX XX Local Numbers without area code (8 digits) = XXXX XXXX All others visually format correctly. When adding a 1800/1300 DID to the PBX it will re format it with an extra 0, example adding +611800123123 ends up like this, which is wrong, might also be related to the issue happening with extra 0's.

On iOS if you answer a call do you have the transfer controls show? and then if you hold it and resume it no transfer controls? .. Not sure how basic testing when pushing updates does not pickup such rudimentary failures. ¯\_(ツ)_/¯

Lots of strange things happen with this version and app's. Deffo would not upgrade a production box. I have a list of stuff I have been collecting when testing, yet to make it known. My head would explode with support calls if I upgraded.

Do all the IP's look good of where audio is being streamed to?