[Home]

Summary:ASTERISK-08128: [patch] H.323 creates channels with nativeformats having MSbit set, which leads to ast_translator_best_choice() chosing it
Reporter:Guillaume Knispel (gknispel_proformatique)Labels:
Date Opened:2006-11-13 20:12:25.000-0600Date Closed:2007-01-22 10:24:58.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_h323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 02_H323_format_capabilities.diff
Description:H.323 sometimes creates channels with nativeformat having MSbit set, which leads to ast_translator_best_choice() chosing it (for exemple when bridging one with a Local channel) and returning a negative value. This leads to WARNING like :

Nov 13 17:05:52 WARNING[10992]: channel.c:2571 ast_request: No translator path exists for channel type local (native -1) to -2033652

And communications not bridging.

The solution is quite obvious and the attached patch inspired by chan_h323 of branch 1.4 will solve the problem.

I wrote and send this patch for Asterisk 1.2 because I'm working on this version for a client, because it could be useful for other people, and because if any 1.2 minor revision is released one day it could probably go into.

The patch is basicaly s/~0/GLOBAL_CAPABILITY/ with GLOBAL_CAPABILITY coming from the 1.4 branch and believe me or not but I tested it intensively (well, as part of other tests I must admit... :)


****** ADDITIONAL INFORMATION ******

The configuration used to illustrate the problem is quite strange because I wanted to make calls going through H.323 between two Asterisk to do tests related to other modifications I'm doing. I used a local channels to check how a dialplan variable generate by an incoming h.323 call would be transfered in an outgoing h.323 call through an intermediate local channel (i removed this aspect from the dialplans I give bellow).

So it involves two Asterisk and a GateKeeper.

One Asterisk (A) is at 192.168.0.165, the other one at 192.168.0.174 (B), and the GateKeeper is on the same computer the first Asterisk is : 192.168.0.165

Using the configuration bellow, a H.323 phone (SJphone) using the 500 account is calling an sip phone (Thomson 2030) using the 250 extension to go through Asterisk B and then Asterisk A (with an H.323 channel between the two Asterisks). The problem described above occur most of the time, but it happens that sometimes right after launching Asterisk it doesn't happen. I didn't investigate why. Doing calls again should reproduce the problem.

Put a breakpoint in ast_request to see what happens then.

Asterisk (B)
------------

extensions.conf:

[outgoing]
exten => _50X,1,Dial(H323/${EXTEN})
exten => _55X,1,Dial(SIP/${EXTEN})
exten => _3XX,1,Dial(H323/${EXTEN})

[routing]
exten => _5XX,1,Dial(local/${EXTEN}@outgoing)
exten => _2XX,1,Dial(local/$[100+${EXTEN}]@outgoing)
exten => _7XX,1,Dial(local/$[${EXTEN}-200]@outgoing)
exten => 999,1,Answer()
exten => 999,n,Echo()
exten => 999,n,Hangup()

[from-sip]
include => routing

[from-h323]
include => routing

sip.conf:

[general]
port = 5060
bindaddr = 0.0.0.0
srvlookup = no
allow = all
language = fr
context = from-sip
nat = no
qualify = yes
disallow = all
allow = alaw
allow = ulaw

[550]
type = friend
secret = passwd
host = dynamic
mailbox = 550
callerid = Test 550 <550>
callgroup = 1
pickupgroup = 1

h323.conf :

[general]
port = 1720
bindaddr = 192.168.0.174
disallow = all
allow = alaw
allow = ulaw
gatekeeper = 192.168.0.165
secret = thx1138
context = from-h323

[aster2]
type = h323
prefix = 2
secret = thx1138

[aster5]
type = h323
prefix = 5
secret = thx1138

[aster7]
type = h323
prefix = 7
secret = thx1138


Asterisk (A)
------------

extension.conf:

[outgoing]
exten => _10X,1,Dial(H323/${EXTEN})
exten => _15X,1,Dial(SIP/${EXTEN})
exten => _7XX,1,Dial(H323/${EXTEN})

[routing]
exten => _1XX,1,Dial(local/${EXTEN}@outgoing)
exten => _6XX,1,Dial(local/$[100+${EXTEN}]@outgoing)
exten => _3XX,1,Dial(local/$[${EXTEN}-200]@outgoing)
exten => 999,1,Answer()
exten => 999,n,Echo()
exten => 999,n,Hangup()

[from-sip]
include => routing

[from-h323]
include => routing


h323.conf :

[general]
port = 1720
bindaddr = 192.168.0.165
disallow = all
allow = alaw
allow = ulaw
gatekeeper = 192.168.0.165
secret = thx1138
context = from-h323

[aster1]
type = h323
prefix = 1
secret = thx1138

[aster3]
type = h323
prefix = 3
secret = thx1138

[aster6]
type = h323
prefix = 6
secret = thx1138

[aster9]
type = h323
prefix = 9
secret = thx1138


sip.conf:

[general]
port = 5060
bindaddr = 0.0.0.0
srvlookup = no
allow = all
language = fr
context = from-sip
nat = no
qualify = yes
disallow = all
allow = alaw
allow = ulaw

[150]
type = friend
secret = passwd
host = dynamic
mailbox = 150
callerid = Test 150 <150>
callgroup = 1
pickupgroup = 1


GnuGK :
-------

[Gatekeeper::Main]
Fourtytwo=42
Name=OpenH323GK

[RasSrv::GWPrefixes]
aster1=1
aster2=2
aster3=3
aster4=4
aster5=5
aster6=6
aster7=7
aster8=8
aster9=9

[RoutingPolicy]
default=internal

[GkStatus::Auth]
rule=password
admin=ZmFNmMqN+2A=

[RasSrv::RRQAuth]
aster2=sigip:192.168.0.174:1720
aster5=sigip:192.168.0.174:1720
aster7=sigip:192.168.0.174:1720

[Gatekeeper::Auth]
AliasAuth=optional;RRQ
SimplePasswordAuth=sufficient;RRQ

[SimplePasswordAuth]
aster1=RsnqhyDXq/0=
aster2=gg3DYGxQbNo=
aster3=YzGESYn8kCY=
aster4=vGnkivG50V0=
aster5=Y5/PILc51eI=
aster6=RbF6YHP9zXw=
aster7=AS8c935l54s=
aster8=CkYRT4WjyQ0=
aster9=Qlgf5M+u46M=
100=vmfiT53Gw+w=
500=yAVblgMCbQ0=
Comments:By: Paul Cadach (pcadach) 2006-11-13 23:57:44.000-0600

One more reason to switch to 1.4 - to not backport all 1000+1 changes made in chan_h323 to be (mostly) working for 1.4...
By: Guillaume Knispel (gknispel_proformatique) 2006-11-14 04:12:32.000-0600

Yeah, I got the point.

The fact is I would switch to 1.4 (and I will in the future) if I could but right now I _have_ to backports some changes to have something that works under some conditions.

So the code is here, I think maybe this could be useful for somebody.

Forget me and just close my stuff with WON'T FIX if you don't want to hear about 1.2 anymore. Don't worry, I'll send patchs for 1.4 soon :)
By: Guillaume Knispel (gknispel_proformatique) 2006-11-23 07:23:03.000-0600

To be clear about it, like in the 0008337 issue, I add that this issue doesn't exist in the 1.4 branch.
By: Joshua C. Colp (jcolp) 2007-01-22 10:24:57.000-0600

This is minor enough that I don't mind... so fixed in 1.2 as of revision 51359.