[Freeswitch-users] internal versus external calls

[Bote Man]

Yes, if by "internal" it means internal to your own FreeSWITCH installation
which you control. Then you can set a variable early in the dialplan that
indicates that this is an internal call. In fact, there might be an example
of this in the vanilla configuration files already.

If you need to test for this variable in the same pass through the dialplan
and not in later processing you should use the "inline" attribute so that it
takes effect immediately during the evaluation phase and not later during
the dialplan execution phase.

Otherwise, you could probably devise some clever means to detect the source
of calls by Caller*ID number or inbound carrier or profile as Stanislav
points out; there is a lot of flexibility available.

Bote


> -----Original Message-----
> From: Stanislav Sinyagin
> Sent: Tuesday, 24 March, 2015 09:15
> Subject: Re: [Freeswitch-users] internal versus external calls
> 
> they would normally come into different dialplan contexts, like
> "public" and "default", and there you can distinguish them and define
> the rules.
> 
> 
> On Tue, Mar 24, 2015 at 1:52 PM, Szeto, Steven <steven.szeto at mitel.com>
> wrote:
> > Hi Everyone,
> >
> > When an incoming call comes through via SIP to Freeswitch, is there a
way
> to
> > identify the call as an internal versus external call?
> >
> > An internal call would be from a device hosted by a PBX.
> >
> > An external call would be from the public network (e.g. a cell phone
call
> > that has been transited through a PBX to Freeswitch.
> >
> > Regards,
> > Steve
> >
> > This e-mail (including any attachments) is for the sole use of the
intended
> > recipient(s) and may contain information that is confidential and/or
> > protected by legal privilege. Any unauthorized review, use, copy,
disclosure
> > or distribution of this e-mail is strictly prohibited. If you are not
the
> > intended recipient, please notify Mitel immediately and destroy all
copies
> > of this e-mail.  Mitel does not accept any liability for breach of
security,
> > error or virus that may result from the transmission of this message.
> >