[Asterisk-Users] Re: Custom handling of SIP 302 redirect?

[Steve Davies]

On 10/24/05, Olle E. Johansson <oej at edvina.net> wrote:
> Steve Davies wrote:
> > On 10/21/05, Steve Davies <davies147 at gmail.com> wrote:
> >
> >>I have noticed that when a SIP redirect is sent back to Asterisk by a
> >>SIP peer, that Asterisk will (quite appropriately) do a
> >>Dial(LOCAL/redirect-number) in the context of the original callee.
> >>
> >>It also forks the CDR, which is excellent. Sadly, under these
> >>circumstances, I need to alter the caller-ID to be a valid value, set
> >>the 'src' to be the correct extension no., and set the accountcode to
> >>something recognisable as an outbound call by that user.
> >
> > I have managed to get part-way through this problem... It seems that
> > ACCOUNTCODE persists across the dial, so I can set that to a
> > meaningful value most of the time, and use the data later for billing,
> > sadly this is only a small (20 character) field, so I can only
> > transfer a limited amount of data.
> >
> > Other fields such as userdata do not persist, and variables that are
> > set in the dialplan do not stay in-scope either. Can anyone suggest
> > another mechanism for passing data across?
> >
> > Perhaps this should be raised as a feature-request such that the
> > caller-ID field is populated from the SIP client that sends the
> > redirect? Looking at the source I expected this to happen already, but
> > it is a fairly complex interaction.
> >
> Just so you don't have to comment on your own comment to your own
> mail... :-)

:-) The thought is much appreciated.

> It should go through the dialplan. What we could do is to set a variable
> so you could catch it being a call forward in the dial plan so you could
> treat it any way you want.
>
> Another question is the context. We have the normal context, the
> transfer context, the subscription context - do we need to add another
> context or can we reuse one of these for forwards? I would suspect that
> using the transfer context with a flag for call forwarding
> (CALLFORWARD=yes) would work.

I agree that the transfer context, falling back to the subscription
context of the callee would make sense. I like the CALLFORWARD=yes
idea, although it might be useful to extend this so it would add
CALLFORWARDBY=SIP/phone1 and CALLFORWARDEXTEN=nnn where nnn is the
value of $EXTEN when the redirect occurred.

Of course all of this could be done manually if variables stayed
in-scope through the redirect.

Thanks again,
Steve