[Asterisk-Users] # Transfer context problem

[John Fortman]

Setup:
Asterisk with chan_h323 (chan_iax was connecting the two clients directly, dropping asterisk out of the picture)
Clients are two pentium class computers on the same network with ohphone installed.
The idea is simply to have one client call into asterisk (a client calling from outside) to be
answered by an operator then transferred to a different extension.

Extensions.conf:
    [default]
    include => parkedcalls
    ...
    exten => s,2,Dial(${ARG2}|20|tT)  ; ARG2 = H323/192.168.1.55

The caller dials in.
The operator answers.
The operator dials #
Asterisk plays "transfer"    (so far, no problems)

The operator dials an extension 
Asterisk replies "sorry, that is not a valid extension.  Please try again."
The message in asterisk -vvvc is "unknown extension 'X' in context ' ' " 
or something to that effect.

What I've found is the following:

line 668 of chan_h323.c (cvs from Tuesday 08/19/2003 around 11:45am)
    strncpy( ch->context, i->context, sizeof( ch->context )-1 );

i is struct oh323_pvt that was generated shortly beforehand by oh323_alloc() with 
no reference in the function to ->context.  THere doesn't even appear be a search
to compare the requested IP address with an H323 user so the context is left blank!

Therefore, the operator cannot transfer because he is out of context in asterisk.

There appears to be a similar problem with chan_iax because I can dial to an IAX client
from an H323 client through asterisk and have the same problem.  (IAX client to IAX client
cannot dial # to return to asterisk.  Asterisk hangs up the connection after linking the two
clients.)

My question is:  Have I setup extensions.conf wrong or is this really a bug in Asterisk?
This has been bothering me for about four weeks now and I cannot fix this correctly.
I have faked it by changing:
    strncpy( ch->context, i->context, sizeof( ch->context )-1 );
to 
    strncpy( ch->context, "default", sizeof( ch->context )-1 );
which works to test the transfer function but is no where near a good fix.

Thank you,
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20030819/dabe5555/attachment.htm