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

[Marc Haisenko]

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...
C'ya,
	Marc

-- 
Marc Haisenko
Comdasys AG

Rüdesheimer Straße 7
D-80686 München
Tel:   +49 (0)89 - 548 43 33 0
Fax:   +49 (0)89 - 548 43 33 29
e-mail: haisenko at comdasys.com
http://www.comdasys.com