VoIP Mailing List Archives

[martin at pattersong.c...]

I have an issue that I’m struggling to resolve. I’ve tried this out in
the vanilla config.

If a bridged destination in the default context:
<action application="bridge" data="user/1001@${domain_name}”/>

returns a 302 Moved Temporarily then the new destination is run
through the dialplan in the same default context and everything is
good. In the log:
[DEBUG] sofia.c:6971 Redirect: Transfering to 1003
[DEBUG] switch_ivr.c:2289 (sofia/internal/1000@192.168.1.226) State
Change CS_EXECUTE -> CS_ROUTING
[NOTICE] switch_ivr.c:2296 Transfer sofia/internal/1000@192.168.1.226
to XML[1003@default]

However I need to call multiple destinations at once. When separating
them with comma, I sometimes get “Only calling the first element in
the list in this mode”. Some destinations in my case may have multiple
registrations, so that’s not an option.

Instead I do enterprise dial with :_: which gets round that:

<action application="bridge"
data="user/1001@${domain_name}:_:user/1002@${domain_name}"/>

but it has the effect that if a destination returns 302 Moved
Temporarily (1002 forwards to 1003 here), then it doesn’t run through
the dialplan the same context, it goes to the public context and fails
because the destination (1003) is an extension in the default context.
The log looks like it’s handling the 302 as if it’s a new call:

[INFO] sofia.c:10462 sofia/internal/1000@192.168.1.226 receiving
invite from 192.168.1.226:5060 version: 1.10.7 -release-19-883d2cb662
64bit call-id: ee6cd84a-cca5-123a-d6a1-080027d0c8d3
[INFO] mod_dialplan_xml.c:639 Processing Extension 1000 <1000>->1003
in context public
EXECUTE [depth=0] sofia/internal/1000@192.168.1.226 deflect(1003)

I must be missing something in my understanding here – I don’t
understand why the behaviour is different, but more interestingly, is
there a way of getting the enterprise dial to process the 302s in the
same way as when dialling one destination?

Best wishes,

Martin.

Martin Paterson, Pattersong Music
Reduced orchestrations of G&S

_________________________________________________________________________

The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.

Join our online community to chat in real time https://signalwire.community

Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com

Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com

[brian at freeswitch.com]

You will want to set outbound_redirect_fatal=true, or the enterprise originate will follow the 302, you can safely ignore those if needed.

On Tue, Nov 30, 2021 at 12:09 PM Martin Paterson <martin@pattersong.co.uk (martin@pattersong.co.uk)> wrote:

[martin at pattersong.c...]

Thanks for your response, Brian. Actually I think I need the opposite of that option! I want FreeSWITCH to handle the 302s in the dialplan, but the problem is that when using :_: the redirect ends up in the public dialplan not the default dialplan (where the extensions are). When not using :_: the redirect works fine - the call goes through the default diaplan and finds the extension. However the option has led me to the FS code that handles this, so I shall take a look there.

Thanks,


Martin.
Martin Paterson, Pattersong Music
Reduced orchestrations of G&S








On Tue, 30 Nov 2021 at 18:24, Brian West <brian@freeswitch.com (brian@freeswitch.com)> wrote:

[brian at freeswitch.com]

You really can't use enterprise originate for that.  It requires a lot more thought, you can't exit the loops since each one is in its own threads, the only option is to ignore.

On Wed, Dec 1, 2021 at 10:51 AM Martin Paterson <martin@pattersong.co.uk (martin@pattersong.co.uk)> wrote:

[brian at freeswitch.com]

You aren't understanding that when you use enterprise originate it's like doing a parallel dial, each one stands alone, one does a 302, it will END them all.  Make sure manual redirect is setup, per confluence, and do a debug trace of it attempting this, I bet you can see why in that log.

On Wed, Dec 1, 2021 at 10:51 AM Martin Paterson <martin@pattersong.co.uk (martin@pattersong.co.uk)> wrote:

[martin at pattersong.c...]

Thanks for that Brian. Are you saying then that it is impossible to follow 302s when you do multiple outdials with enterprise originate, the only choices are ignore the 302 or follow but cancel the other outdials? But if that's how it is, then so be it. The 'Freeswitch IVR Originate' page implies the opposite though. Of enterprise originate it says:'This can be helpful when dealing with call forwarding. Without it, FreeSWITCH would drop the simultaneous dial and transfer to the forwarded extension. For example, I'm bridging to two SIP phones, 101 and 102, with "," between them. 101 redirects to some other URL. 102 will now stop ringing. With :_: it wouldn't'.


Anyhow my users really like the convenience of turning forwarding on and off by pressing a button on the (Snom) handset which chooses whether it returns 302 or not. So plan B is going to be to configure the Snoms to dial a code when hitting the button instead. The code then gets handled in the dialplan which remembers the setting. Then when a forwarded handset is subsequently dialed, logic in the dialplan can replace that with the forwarded number.
Martin Paterson, Pattersong Music
Reduced orchestrations of G&S










On Thu, 2 Dec 2021 at 01:42, Brian West <brian@freeswitch.com (brian@freeswitch.com)> wrote:

[brian at freeswitch.com]

You can also enable the Snom to do an HTTP request to enable/disable forwarding so its done server side too.

On Tue, Dec 7, 2021 at 7:52 AM Martin Paterson <martin@pattersong.co.uk (martin@pattersong.co.uk)> wrote: