On 10/24/05, Olle E. Johansson <[EMAIL PROTECTED]> wrote: > Steve Davies wrote: > > On 10/21/05, Steve Davies <[EMAIL PROTECTED]> 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 _______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
