Brian Dunne

If you aren't reliant on SmartPBX's many provisioning features, you can set up callflows pointing to the user's devices for each of the preferred extensions rather than pointing one callflow at the user. So attach both devices to the same user, then create callflows that go Device -> Voicemail (or whatever) for each extension. If you rely heavily on SmartPBX controlling all your provisioning, or you don't have access to the Callflows app, you might be stuck with the constraints that SmartPBX imposes (so that it can do all that neat provisioning stuff).

If you check accounts/{accountId}/cdrs/legs/{cdr-id} for a given call, you'll see the individual legs of the call. For a call that goes to a Ring All group, you'll see the attempts to each member device. The hangup_cause for each Ring All leg will be "LOSE RACE", except for the leg that answered the call. One kind of hack that we've used to sort out which ring group delivered a particular call is the "Prepend Caller ID" feature in Calllflows. Basically, after the user selects a menu option that determines whether the call is routed to a given ring group, but before we deliver the call to that ring group, we insert one of these Prepend objects to modify the original caller's CallerID based on the function of that destination ring group: The resulting CDR interaction will show the user's normal callerID on the initial leg, and will have TOGO-ORDER prepended on all ring group legs and beyond.

To point you in the right direction, you'll want to manipulate the `enabled` property of the Time of Day Rule: https://docs.2600hz.com/dev/applications/crossbar/doc/temporal_rules/

Hi all, Anyone have any luck getting these phones configured against Kazoo? I've got the 78xx registered and placing outbound calls, but the phone responds to any incoming SIP messages (e.g. BYEs) with 404s after the call sets up. The 69xx isn't registering, and that's probably a more fundamental issue with my XML config. I was hoping it would be basically the same as the 78xx config, but it looks like there are some difference in how they select user@realm from the config options. Documentation on these things is close to nonexistent.

Just to clarify the behavior for others who might have considered other solutions to this: 1) Setting the time_window_stop value earlier than the time_window_start value (i.e. open from 9am-2am) causes that rule to be ignored, or treated as inactive. The API probably shouldn't allow users to do this, just as it protects them from #2. 2) The API will not allow you to set the time_window_stop value higher than 86400 (which is 24 * 3600), so there's no way to say "we're open from 1100-2530 on Fridays". Currently it looks like we'll have to hack around this using additional rules (e.g. Friday 0900-2400, Saturday 0000-0200, Saturday 0900-2400).

That's a nice work-around. Trouble is, we are trying to put together a generic TOD set that can be templated and applied to all of our client sub-accounts. Our hope was that we could have one rule for each day, allowing our customers to tweak those hours as needed. If we have to add/remove sets in order to accommodate these wrap-arounds, that makes our setup a lot more complicated.

Hi all, We've got some clients whose regular business hours might extend to midnight or beyond. If I try to enter anything later than 23:55 via the Monster UI, I get a validation error that the end time is earlier than the start time. However, the API will let me submit a time_window_stop of 0:00 or 01:00 without complaint. I know we could do a separate rule to account for a Friday->Saturday wrap by creating a Saturday 0:00-2:00 rule, for example, but not being able to set the Friday rule to stop at midnight means there's at least a 5-minute gap during which the rule can't be active if configured via Monster UI. Anyone know how the actual time of day calculation is performed if, for example, my TOD rule is active every Friday from 1100 to 0200? And if that works as one would expect, maybe the Monster UI validator needs an update to allow wrap-around time spans.

This may be one of those opportunities to help your customer by telling them what not to do. I can't imagine spending 12 minutes listening to a list of food items to find out whether my local restaurant offers pork lo mein or just chicken, beef, and shrimp. I'm sure there's a way to rewrite/restructure this solution so that it's more end user-friendly (for example, splitting it up into logical subsections accessible via a top-level menu). 12 minutes is punishing for the end users as well as the person who has to do the recording in a single take.

No issues for us on the hosted side. Are you having issues calling locally (ext-to-ext)? That could rule out your SIP trunking provider, which is where I'd point the finger if calls not requiring the PSTN are working fine. Could also be a regional ISP/backbone hit, though there's nothing obvious on downdetector.net like the Level 3/Comcast fiber cut a couple weeks back.