[asterisk-dev] Setting the context in a SIP channel

[Tilghman Lesher]

(I am on the -dev list.  There is absolutely no reason to copy me in
your reply.)

On Friday 27 January 2006 09:27, Marc Haisenko wrote:
> On Thursday 26 January 2006 18:39, Tilghman Lesher wrote:
> > On Thursday 26 January 2006 05:36, Marc Haisenko wrote:
> > > BUMP ! Could some Asterisk developer please post his opinion on
> > > this
> >
> > I think you misunderstand the purpose of the exten and context
> > fields in the sip_pvt structure.  ->exten is "who we are" not
> > "where we're going". "context" is "where we start" not "where we're
> > executing".
> >
> > If you could describe what you're trying to do and why you're
> > trying to do it that way, we may be able to detail a better coding
> > path.
>
> I'm doing lots of stuff Asterisk isn't prepared for and which already
> forced me to export a few private functions ;-)
>
> I'm writing a "forking dial". It's for dynamic roaming for dual mode
> WLAN/GSM phones. Such a phone may initiate a call via SIP/WLAN and
> when leaving the WLAN zone a handover to GSM must occur without the
> call interrupting.
>
> So I've written FDial, which is based on app_conference code (yes, we
> know about the GPL, yes, the source will be released). And it works
> quite well but there some still some minor beauty issues to resolve
> (but all features that we need already work).
>
> Imagine a graph like this:
>
>  GSM   WLAN
>     \ /
>      Y
>
>    outside
>
> Now when I do a call from WLAN to the outside I must at some point
> generate a new channel and call the GSM line. This one will take over
> the functionality of the original WLAN channel: it gets the same
> context, the same exten, the same priority. But in the sip_pvt
> structure the context is wrong.
>
> This means transfers don't work any more.
>
> So I wrote a patch that adds functions
> "ast_channel_set_{context,exten,priority}", and added to tech
> functions "set_context" and "set_exten". My "ast_channel_set_..."
> functions call the "set_context" and "set_exten" of a channel if
> present. I patched the SIP channel to provide these functions.
>
> In short: I've added functions that set the context and exten
> variables of both the channel and sip_pvt.
>
> Now transfers work again as expected.
>
> But I'd like to know how to do it better as I'm not sure whether this
> is the correct way to solve this problem.
>
> I had to do other dirty stuff (add a function
> "ast_blind_transfer_dtmf" that wraps "builtin_blindtransfer" so I can
> do blind transfers via DTMF) but I guess I better address one problem
> at a time on the list :-)
>
> Hope you understand my problem...

I think I understand, and I also think there's a better way to solve
your problem using existing code.  I think you should look into the
masquerade code in channel.c to essentially take over (or masquerade
into) another existing channel.

The masquerade code is currently used for things like remote pickup
(i.e. pickup a ringing line from a phone that is not ringing).  The same
concept applies to your situation, with the exception that you're
picking up a channel which in the answered state, instead of in the
ringing state.

Another approach used to be in the bristuff package, as app_pickup.c.
It apparently is no longer distributed with bristuff, probably because
it conflicts with the builtin directed pickup application, but it can
still be found.  The exact application within that source is called
Steal.

-- 
Tilghman