[asterisk-users] Variables sip redirects and call forward

C F shmaltz at gmail.com
Sun Aug 6 20:47:09 MST 2006


I was thinking about it but didn't have a chance to test it. This is
an answer for my question marked as #2:
2. Is there any way to detect in the DP that an extension is called
from a redirect (any variables)?
After some testing it appears that the only time this variable is
populated is when there is a 302.
There are times when one wants to implement their own CFWD dialplan
(not making much use of 302 or Zap callforwarding) the reason being
that with your own you can also allow for remote callforwarding. In
which case the most logical way is to use Local channels as it takes
care of the billing and the like that is already defined in the
dialplan and there is no need to define it again. When using your own
CFWD you can also define thru the DP matching where they can forward
calls to, while with 302s it's not so easy, although the follwoing
should work:
GotoIf($[${LEN(${RDNIS}>0]?whatever,${EXTEN},1) so that you can have
validation at
whatever.
I myself implement such callforwarding in my DPs and therefore have a
lot of times where I use the local channles, it is therefore not
possible to know if it's (the local channel) from a 302 or my own
callforwarding (which with RDNIS I do know), unless I can get Macros
to keep variables after it's out of the macro, that way I can set a
variable when using my own callforwarding, and if it's missing I will
know it's a 302.
I also implement local channels (sometimes) when using queues like this:
member = Local/123 at context
Which brings us back to question #3:
> > 3. While playing around with this problem I tried setting a variable
> > in the macro that calls the queue using both _VARNAME and __VARNAME
> > and I was not able to see it anywhere outside the macro that is,
> > neither was I able to see any of the setvar=VARNAME from sip.conf for
> > sip/3 in any of the extensions created thru the 302 from sip/3, I also
> > tried _VARNAME and __VARNAME, is there a workaround to either have the
> > var from the macro show up everywhere the member it calls end up? or
> > to have a sip acconts setvar show up even on the channel created from
> > the 302?
> >
If I can get a var set in a macro to show up in the local channel
created from that macros call to app_queue that calls chan_local, then
the problem looks to be solved. But so far I havn't been able to do
that. And RDNIS is not populated in this case.
So to sum up, I use chan_local in the following:
1. Custom call forwarding, which does not populate a proper RDINS, and
I could or should be able to set my own var that are readable in the
DP to distinguish that it's my local channel created thru my custom
CFWD.
2. 302s which does populate a proper RDNIS and is distinguished just
by the RDNIS.
3. Local channels created by app_queue that I know that RDINS is NOT
populated, and I know that variables don't last across it, they are
only distinguishable by the fact that it's a channel of the type
Local.
So RDNIS will sure help.


On 8/6/06, Eric ManxPower Wieling <eric at fnords.org> wrote:
> Check that status of:
>
> ${RDNIS} and/or ${CALLERID(rdnis)}) in
> /path/to/src/asterisk/docs/README.variables
>
>
> C F wrote:
> > First my little Sunday story.
> > A client of mine with a big factory calls me up that he is trying to
> > call in to his place because the fire alarm went off. He is dialing
> > the extension I gave him that will call all the extensions (and worked
> > before) but after 2 rings he gets a message: The subscriber you are
> > trying to reach is unavailable (probly from T-Mobile or Cingular). So
> > I tell him immediately just keep calling back until someone picked up,
> > I realized that someone must have forwarded their extension (using
> > local sip forward) to their cell phone, and their cell phone is out of
> > reach. Sure enough a few hours later when I had a chance to log into
> > the box, I did my test call and there it was in the CLI calling blah
> > blah thanks to sip blah at 192.168.24.247 blah blah.
> > After working with this for around half an hour I just ended up
> > disabling local forward using the .cfg files from cisco.
> > So here is my question, is there anyway to determine thru variables
> > that a phone call is forwarded thru a sip redirect (I think its 302
> > moved temp)?
> > Here is my setup:
> > exten 123 calls a macro that takes a few arguments one of them is the
> > name of the queue,
> > the macro in turn calls the Queue, the queue has:
> > member =sip/1
> > member = sip/2
> > member = sip/3
> > In my case sip/3 was forwarded to an outside number.
> > so app_queue just followed the sip moved.
> > Here are my questions:
> > 1. Is there any way to have app_queue ignore redirects?
> > 2. Is there any way to detect in the DP that an extension is called
> > from a redirect (any varialbes)?
> > 3. While playing around with this problem I tried setting a variable
> > in the macro that calls the queue using both _VARNAME and __VARNAME
> > and I was not able to see it anywhere outside the macro that is,
> > neither was I able to see any of the setvar=VARNAME from sip.conf for
> > sip/3 in any of the extensions created thru the 302 from sip/3, I also
> > tried _VARNAME and __VARNAME, is there a workaround to either have the
> > var from the macro show up everywhere the member it calls end up? or
> > to have a sip acconts setvar show up even on the channel created from
> > the 302?
> >
> > Thank you all.
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-users mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-users
> >
>
>
> --
> Now accepting new clients in Birmingham, Atlanta, Huntsville,
> Chattanooga, and Montgomery.
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>



More information about the asterisk-users mailing list