Discussion:
Basic questions, h323 to SIP
Rob Koliha
15 years ago
Permalink
Hi All,

I am currently attempting to setup Yate as an h323<->SIP gateway/proxy to connect an Avaya h323 system to a Digium Switchvox (asterisk based) system. I've followed along with the instructions that are on the site and can get the SIP connection up, but I'm unable to establish an h323 connection (using Ekiga or PacPhone for testing). The call is "terminated by the gatekeeper" in Ekiga, and I get a GK Protocol error in PacPhone.

The goal is:
Avaya <-> Yate <-> Digium Switchvox (Asterisk based)

I'm familiar with SIP providers, but this situation is a little more unique and I'm not as familiar with h323 as SIP. While I would love the dialed extension to come through on the other side, I will settle for blindly dumping all incoming traffic to a certain extension if required.


So this brings me to some questions:

1. Do I need to setup SIP peering between Yate <-> Digium and Yate <-> Avaya?

2. If this is just passing h323 to SIP with no peering, can I authenticate as a SIP extension sip:user:pw-UehmLrBSHD/2beSI07/***@public.gmane.org in the regexroute.conf file (what about the other way around?)?

Ie: ${module}^h323$=sip/sip:user:password-***@public.gmane.org


I will be happy to post configs, but originally I did a fresh install and modified the entires that were indicated in the docs - when that didn't work I cleared the configs indicated in the h323<->sip doc and copied/pasted the file contents straight from the docs (same results either way). I've setup a SIP peer without issue to the digium, but I'm unable to get any further with passing an h323 call to the trunk or to the SIP server directly.


Thanks in advance,
Rob Koliha
Paul Chitescu
15 years ago
Permalink
Hi, Rob.

The per call authentication is not supported but you can create a SIP account
with authentication but no registration.

To do that with accfile.conf create a section that has no registrar set:

[sip_peer]
protocol=sip
username=USER
password=PASS
;outbound=a.b.c.d:port
;domain=example.com

Route the call using the account name:

${module}^h323$=sip/sip:number-***@public.gmane.org;line=sip_peer

You may need to set the outbound proxy address if it's not xxx.xxx.xxx.xxx.

If set, the "domain" setting in accfile.conf applies if the route does not
contain an @ character.

Example:

[sip_peer]
protocol=sip
username=foo
password=bar
outbound=10.1.2.3
domain=example.net

... =sip/number;line=sip_peer

The INVITE will be To: <sip:number-***@public.gmane.org> and will be sent to 10.1.2.3
port 5060 (default SIP port). If challenged it will authenticate with user
"foo" and password "bar".

Paul
Post by Rob Koliha
Hi All,
I am currently attempting to setup Yate as an h323<->SIP gateway/proxy to
connect an Avaya h323 system to a Digium Switchvox (asterisk based) system.
I've followed along with the instructions that are on the site and can get the
SIP connection up, but I'm unable to establish an h323 connection (using Ekiga
or PacPhone for testing). The call is "terminated by the gatekeeper" in
Ekiga, and I get a GK Protocol error in PacPhone.
Post by Rob Koliha
Avaya <-> Yate <-> Digium Switchvox (Asterisk based)
I'm familiar with SIP providers, but this situation is a little more unique
and I'm not as familiar with h323 as SIP. While I would love the dialed
extension to come through on the other side, I will settle for blindly dumping
all incoming traffic to a certain extension if required.
Post by Rob Koliha
1. Do I need to setup SIP peering between Yate <-> Digium and Yate <-> Avaya?
2. If this is just passing h323 to SIP with no peering, can I authenticate
as a SIP extension sip:user:pw-UehmLrBSHD/2beSI07/***@public.gmane.org in the regexroute.conf file
(what about the other way around?)?
Post by Rob Koliha
I will be happy to post configs, but originally I did a fresh install and
modified the entires that were indicated in the docs - when that didn't work I
cleared the configs indicated in the h323<->sip doc and copied/pasted the file
contents straight from the docs (same results either way). I've setup a SIP
peer without issue to the digium, but I'm unable to get any further with
passing an h323 call to the trunk or to the SIP server directly.
Post by Rob Koliha
Thanks in advance,
Rob Koliha
G.Jacobsen
15 years ago
Permalink
some hints for yate yrtpchan:When yate is sitting behind a SS7 or ISDN gateway it may receive no audioduring call setup on calls originating from the gateway. However many SIP entities expect audio from the originating side already during the call setup phase. If they do not receive the audio they also do not send audio, e.g. ringback - or they may even terminate the call.If RTP timeout is enabled in yate and there is a chance that its upstream entities do not send audio duing call setupThe rtp timeout should be set higher than the maximum time required for call setup otherwise yate may terminate the call before it can connect. Contrary to the documentation timeout seems to be INT data type and looks as if it can be set higher than 60000 (60 seconds)Also drillhole should be enabled so that downstream entities receive audio already during call setup from yateand in turn send ringback. Drillhole can fake such rtp when no rtp is coming from upstream to yate, e.g. the gateway.
Rob Koliha
15 years ago
Permalink
Hi Paul,

Thanks very much for your help. I made the configuration changes you suggested and after some more troubleshooting, I still seem to be running into the same issues. I thought that it could be a connectivity/firewall/routing issue, so I also attempted to get this going with the windows version of Yate on a machine that is in the same subnet as the digium pbx (with the same results). I figured that using the windows version at minimum would help to eliminate the possibility of my versions of pwlib, openh323, or something else relating to my linux server as the culprit(s) for this problem.

I have also tried removing the rules in the regexroute.conf file to allow me to register to yate with an h323 client to do basic internal testing (self to self or self or self to test numbers). That's not working either, same symptoms with PacPhone -- GK Transport Error (or when dialing from Ekiga - "Gatekeeper Cleared the Call"). I can register without issue via SIP. I'm a novice at h323 and Yate is new to me, but based on the behavior it seems like the establishing the h323 connection is the main issue - not the routing or the SIP side. It's listening on 1720 at least, but I'm not seeing much more :)

If I attempt to make a SIP connection when running Yate as ./yate -vvvvv I see on the console: <sip:INFO> Received 324 bytes SIP message from ip.address:3344. If I attempt an h323 connection, the console doesn't display any messages whatsoever. I have debug logging turned up to 9 for h323, is there somewhere it dumps the logs to on the system?

The routing looks like it's working great from SIP -> H323:
<cdrbuild:INFO> Got message 'call.route' for untracked id 'sip/2'
<INFO> Routing call to 'test' in context 'default' via 'h323/test-***@public.gmane.org' in 254 usec
<sip:NOTE> Formats for 'audio' changed to 'mulaw' [0xf1dcd0]


All .conf files were removed during this round of testing except: accfile.conf, h323chan.conf, regexroute.conf, regfile.conf, yate.conf, and ysipchan.conf. There are empty lines between the [ ] sections, I've just not included them with this message to make it easier on the eyes.


accfile.conf
------------
[digium_trunk]
protocol=sip
username=304
password=12345
outbound=10.x.x.x
domain=10.x.x.x

(domain is the same as the outbound ip, this is also what is used on the switchvox)


h323chan.conf
-------------
[general]
external_rtp=yes
passtrough_rtp=yes ; mis-spelled per the guide on the website
[codecs]
default=no
mulaw=on
alaw=on
g723=on
g729=on
[ep]
faststart=on

regexroute.conf
---------------
[default]
${rtp_forward}possible=;rtp_forward=yes
${formats}^\([^,]*\)=;formats=\1
${module}^sip$=h323/${called}@10.0.0.3
${module}^h323$=sip/sip:${called};line=digium_trunk
.*=-;error=forbidden;reason=Protocol not allowed

(also tried: "${module}^h323$=sip/sip:221;line=digium_trunk")

regfile.conf
------------
[test]
password=12345
[digium]
password=12345

yate.conf
---------
[localsym]
h323chan.yate=yes
[debug]
h323=level 9
sip=level 9

ysipchan.conf
-------------
[codecs]
default=off
mulaw=yes
alaw=yes
g723=yes


Configuration from the Digium box
----------------------------------
SIP Provider Name: Trunk (internal reference only)
Account ID: digium
Password: 12345
Hostname/IP: 10.x.x.x (Yate Server)
Callback Extension: 802
Default Fax Extension: 399
DTMF Mode: RFC2833

[advanced options]
Host Type: Peer (other option is provider)
Host is a Switchvox: No
Treat system's user like local users: No
Jabber Hostname: [blank, not used]
Apply incoming call rules to provider: Yes
Supports changing Caller ID: No
SIP Port: 5060
SIP Expiry: 120
Proxy Host: 10.x.x.x (Yate Server)
Auth User: digium
Always Trust this Provider: Yes
Qualify Hosts: No
Include user=phone in SIP: No
Use local address in from header: No
Audio Codecs: ULAW, ALAW, G729
(also have (disabled) g722, g726, speex, gsm, adpcm, lpc10)
Video Codecs: H263, H263+, H264
Enable Jitterbuffer: Never
Allow Reinvite: Never (have tried "always" and "always, using the update method")
Voicepulse Connect DID Workaround: No

There is also a fax settings section, but I don't think it's relevant to this issue.



Thanks again for your help!
--
Rob Koliha
Development and Infrastructure Services
AVG Technologies USA, Inc.



-----Original Message-----
From: Paul Chitescu [mailto:paulc-uHKunLg9Q/***@public.gmane.org]
Sent: Thursday, July 29, 2010 7:13 AM
To: yate-uHKunLg9Q/***@public.gmane.org
Cc: Rob Koliha
Subject: Re: [yate] Basic questions, h323 to SIP

Hi, Rob.

The per call authentication is not supported but you can create a SIP account
with authentication but no registration.

To do that with accfile.conf create a section that has no registrar set:

[sip_peer]
protocol=sip
username=USER
password=PASS
;outbound=a.b.c.d:port
;domain=example.com

Route the call using the account name:

${module}^h323$=sip/sip:number-***@public.gmane.org;line=sip_peer

You may need to set the outbound proxy address if it's not xxx.xxx.xxx.xxx.

If set, the "domain" setting in accfile.conf applies if the route does not
contain an @ character.

Example:

[sip_peer]
protocol=sip
username=foo
password=bar
outbound=10.1.2.3
domain=example.net

... =sip/number;line=sip_peer

The INVITE will be To: <sip:number-***@public.gmane.org> and will be sent to 10.1.2.3
port 5060 (default SIP port). If challenged it will authenticate with user
"foo" and password "bar".

Paul
Paul Chitescu
15 years ago
Permalink
Rob,

Do you see any H.323 related message in the logs? Do the H.323 calls from Yate
work (SIP->H.323)?

Try netstat -ntlp (as root) - does it show Yate listening on port 1720? You
said something about that but I'm not absolutely sure.

If Yate listens on that port you may have a firewall blocking the incoming TCP
connections. H.323 uses many connections (both TCP and UDP) in both directions
for each call so I suggest allowing all ports in both directions and
selectively blocking only the known services you want to protect.

You can reduce the number of connections by setting h245tunneling=yes in
section [ep] of h323chan.conf - of course if the other party supports it too.

Tunneling is also required if the connecting client is behind a NAT - although
that configuration is not really supported and you may run into voice trouble.

Paul
Post by Rob Koliha
Hi Paul,
Thanks very much for your help. I made the configuration changes you
suggested and after some more troubleshooting, I still seem to be running into
the same issues. I thought that it could be a connectivity/firewall/routing
issue, so I also attempted to get this going with the windows version of Yate
on a machine that is in the same subnet as the digium pbx (with the same
results). I figured that using the windows version at minimum would help to
eliminate the possibility of my versions of pwlib, openh323, or something else
relating to my linux server as the culprit(s) for this problem.
Post by Rob Koliha
I have also tried removing the rules in the regexroute.conf file to allow me
to register to yate with an h323 client to do basic internal testing (self to
self or self or self to test numbers). That's not working either, same
symptoms with PacPhone -- GK Transport Error (or when dialing from Ekiga -
"Gatekeeper Cleared the Call"). I can register without issue via SIP. I'm a
novice at h323 and Yate is new to me, but based on the behavior it seems like
the establishing the h323 connection is the main issue - not the routing or
the SIP side. It's listening on 1720 at least, but I'm not seeing much more
:)
Post by Rob Koliha
If I attempt to make a SIP connection when running Yate as ./yate -vvvvv I
see on the console: <sip:INFO> Received 324 bytes SIP message from
ip.address:3344. If I attempt an h323 connection, the console doesn't display
any messages whatsoever. I have debug logging turned up to 9 for h323, is
there somewhere it dumps the logs to on the system?
Post by Rob Koliha
<cdrbuild:INFO> Got message 'call.route' for untracked id 'sip/2'
in 254 usec
Post by Rob Koliha
<sip:NOTE> Formats for 'audio' changed to 'mulaw' [0xf1dcd0]
accfile.conf, h323chan.conf, regexroute.conf, regfile.conf, yate.conf, and
ysipchan.conf. There are empty lines between the [ ] sections, I've just not
included them with this message to make it easier on the eyes.
Post by Rob Koliha
[...]
Rob Koliha
15 years ago
Permalink
Sorry meant to cc to the list, this info/troubleshooting may come in handy for someone else :)

--
Rob Koliha
Development and Infrastructure Services
AVG Technologies USA, Inc.


-----Original Message-----
From: Rob Koliha
Sent: Thursday, July 29, 2010 3:34 PM
To: 'Paul Chitescu'
Subject: RE: [yate] Basic questions, h323 to SIP

Great suggestion - it doesn't appear to be listening, and it doesn't look like there is anything with h323 in the filename in /usr/local/lib/yate/*

[***@www ~]# netstat -nlp | grep yate
tcp 0 0 127.0.0.1:5038 0.0.0.0:* LISTEN 12330/yate
udp 0 0 0.0.0.0:5060 0.0.0.0:* 12330/yate
udp 0 0 0.0.0.0:4569 0.0.0.0:* 12330/yate

[***@www yate]# cd /usr/local/lib/yate/
[***@www yate]# ls -amlR | grep h323
[***@www yate]#

If I look in the folder I extracted the original distribution in I see "h323chan.cpp", but it doesn't look like it was compiled (no corresponding h323chan.yate file like the others). Others that are missing the .yate files are amrnbcodec.cpp, faxchan.cpp and gsmcodec.cpp. So I re-ran config. I know from reading through some of the make files that if pwlib/openh323 are not there it will do some funky stuff.

checking for Pwlib in /usr/local... installed 1.10.3 RTTI: none
checking for OpenH323 in /usr/local... no

So I ran: make distclean
Then I ran ./configure --with-openh323=/root/openh323_v1_18_0/

It found OpenH323, and now shows this when Yate starts:
Loaded module H.323 - based on OpenH323-1.18.0

Netstat now shows:
tcp 0 0 127.0.0.1:5038 0.0.0.0:* LISTEN 1993/yate
tcp 0 0 0.0.0.0:1720 0.0.0.0:* LISTEN 1993/yate
udp 0 0 0.0.0.0:5060 0.0.0.0:* 1993/yate
udp 0 0 0.0.0.0:4569 0.0.0.0:* 1993/yate
udp 0 0 0.0.0.0:2427 0.0.0.0:* 1993/yate



I'm still getting "The Gatekeeper Cleared the Call" from Ekiga when I attempt to dial, and nothing is logged relating to h323 in the log. I do see the <sip:INFO> entries if I attempt to make a SIP connection though. I added the h245tunneling=yes to see if that helped, ran into the same results. I also did a simple telnet test to port 1720, I can connect locally from the linux machine and from the test workstation I'm using Ekiga on.

There is no firewall enabled on the linux machine, and I received the same results (relating to h323) when using the pre-compiled windows version of Yate on a machine connected to the same switch the digium pbx is (to eliminate NAT or firewalls as a cause).

Any other ideas?


Thanks again!
--
Rob Koliha
Development and Infrastructure Services
AVG Technologies USA, Inc.


-----Original Message-----
From: Paul Chitescu [mailto:paulc-uHKunLg9Q/***@public.gmane.org]
Sent: Thursday, July 29, 2010 2:15 PM
To: yate-uHKunLg9Q/***@public.gmane.org
Cc: Rob Koliha
Subject: Re: [yate] Basic questions, h323 to SIP

Rob,

Do you see any H.323 related message in the logs? Do the H.323 calls from Yate
work (SIP->H.323)?

Try netstat -ntlp (as root) - does it show Yate listening on port 1720? You
said something about that but I'm not absolutely sure.

If Yate listens on that port you may have a firewall blocking the incoming TCP
connections. H.323 uses many connections (both TCP and UDP) in both directions
for each call so I suggest allowing all ports in both directions and
selectively blocking only the known services you want to protect.

You can reduce the number of connections by setting h245tunneling=yes in
section [ep] of h323chan.conf - of course if the other party supports it too.

Tunneling is also required if the connecting client is behind a NAT - although
that configuration is not really supported and you may run into voice trouble.

Paul
Post by Rob Koliha
Hi Paul,
Thanks very much for your help. I made the configuration changes you
suggested and after some more troubleshooting, I still seem to be running into
the same issues. I thought that it could be a connectivity/firewall/routing
issue, so I also attempted to get this going with the windows version of Yate
on a machine that is in the same subnet as the digium pbx (with the same
results). I figured that using the windows version at minimum would help to
eliminate the possibility of my versions of pwlib, openh323, or something else
relating to my linux server as the culprit(s) for this problem.
Post by Rob Koliha
I have also tried removing the rules in the regexroute.conf file to allow me
to register to yate with an h323 client to do basic internal testing (self to
self or self or self to test numbers). That's not working either, same
symptoms with PacPhone -- GK Transport Error (or when dialing from Ekiga -
"Gatekeeper Cleared the Call"). I can register without issue via SIP. I'm a
novice at h323 and Yate is new to me, but based on the behavior it seems like
the establishing the h323 connection is the main issue - not the routing or
the SIP side. It's listening on 1720 at least, but I'm not seeing much more
:)
Post by Rob Koliha
If I attempt to make a SIP connection when running Yate as ./yate -vvvvv I
see on the console: <sip:INFO> Received 324 bytes SIP message from
ip.address:3344. If I attempt an h323 connection, the console doesn't display
any messages whatsoever. I have debug logging turned up to 9 for h323, is
there somewhere it dumps the logs to on the system?
Post by Rob Koliha
<cdrbuild:INFO> Got message 'call.route' for untracked id 'sip/2'
in 254 usec
Post by Rob Koliha
<sip:NOTE> Formats for 'audio' changed to 'mulaw' [0xf1dcd0]
accfile.conf, h323chan.conf, regexroute.conf, regfile.conf, yate.conf, and
ysipchan.conf. There are empty lines between the [ ] sections, I've just not
included them with this message to make it easier on the eyes.
Post by Rob Koliha
[...]
Rob Koliha
15 years ago
Permalink
To help eliminate issues related to libraries, etc, I moved back to a windows based machine and the windows based version, connected to the pbx with a basic gig-e switch. I did a full install instead of a server only install then copied the conf files over from my linux box. The Yate client rocks - the logging was extremely useful (and something the other freebie h323 clients didn't have). The Yate client worked fine going locally on the Windows Yate server and it worked fine from other systems on the LAN. I'm going to just keep it on a windows vm for the time being :)

I think a big part of my problem has to be NAT. There is a public and private network segment here, I was putting Yate on a server on the public segment and my pbx was on the private segment. The router config is quite odd and lots of two way NAT'ing is involved, even opening up all ports between the two boxes didn't do the trick.

Now comes the fun part, tying in an Avaya box from the Czech Republic :)


Thanks for all your help Paul, your suggestions were very useful and helped me work through this issue.
--
Rob Koliha
Development and Infrastructure Services
AVG Technologies USA, Inc.


-----Original Message-----
From: Rob Koliha [mailto:Rob.Koliha-***@public.gmane.org]
Sent: Thursday, July 29, 2010 3:36 PM
To: yate-uHKunLg9Q/***@public.gmane.org
Subject: RE: [yate] Basic questions, h323 to SIP

Sorry meant to cc to the list, this info/troubleshooting may come in handy for someone else :)

--
Rob Koliha
Development and Infrastructure Services
AVG Technologies USA, Inc.


-----Original Message-----
From: Rob Koliha
Sent: Thursday, July 29, 2010 3:34 PM
To: 'Paul Chitescu'
Subject: RE: [yate] Basic questions, h323 to SIP

Great suggestion - it doesn't appear to be listening, and it doesn't look like there is anything with h323 in the filename in /usr/local/lib/yate/*

[***@www ~]# netstat -nlp | grep yate
tcp 0 0 127.0.0.1:5038 0.0.0.0:* LISTEN 12330/yate
udp 0 0 0.0.0.0:5060 0.0.0.0:* 12330/yate
udp 0 0 0.0.0.0:4569 0.0.0.0:* 12330/yate

[***@www yate]# cd /usr/local/lib/yate/
[***@www yate]# ls -amlR | grep h323
[***@www yate]#

If I look in the folder I extracted the original distribution in I see "h323chan.cpp", but it doesn't look like it was compiled (no corresponding h323chan.yate file like the others). Others that are missing the .yate files are amrnbcodec.cpp, faxchan.cpp and gsmcodec.cpp. So I re-ran config. I know from reading through some of the make files that if pwlib/openh323 are not there it will do some funky stuff.

checking for Pwlib in /usr/local... installed 1.10.3 RTTI: none
checking for OpenH323 in /usr/local... no

So I ran: make distclean
Then I ran ./configure --with-openh323=/root/openh323_v1_18_0/

It found OpenH323, and now shows this when Yate starts:
Loaded module H.323 - based on OpenH323-1.18.0

Netstat now shows:
tcp 0 0 127.0.0.1:5038 0.0.0.0:* LISTEN 1993/yate
tcp 0 0 0.0.0.0:1720 0.0.0.0:* LISTEN 1993/yate
udp 0 0 0.0.0.0:5060 0.0.0.0:* 1993/yate
udp 0 0 0.0.0.0:4569 0.0.0.0:* 1993/yate
udp 0 0 0.0.0.0:2427 0.0.0.0:* 1993/yate



I'm still getting "The Gatekeeper Cleared the Call" from Ekiga when I attempt to dial, and nothing is logged relating to h323 in the log. I do see the <sip:INFO> entries if I attempt to make a SIP connection though. I added the h245tunneling=yes to see if that helped, ran into the same results. I also did a simple telnet test to port 1720, I can connect locally from the linux machine and from the test workstation I'm using Ekiga on.

There is no firewall enabled on the linux machine, and I received the same results (relating to h323) when using the pre-compiled windows version of Yate on a machine connected to the same switch the digium pbx is (to eliminate NAT or firewalls as a cause).

Any other ideas?


Thanks again!
--
Rob Koliha
Development and Infrastructure Services
AVG Technologies USA, Inc.


-----Original Message-----
From: Paul Chitescu [mailto:paulc-uHKunLg9Q/***@public.gmane.org]
Sent: Thursday, July 29, 2010 2:15 PM
To: yate-uHKunLg9Q/***@public.gmane.org
Cc: Rob Koliha
Subject: Re: [yate] Basic questions, h323 to SIP

Rob,

Do you see any H.323 related message in the logs? Do the H.323 calls from Yate
work (SIP->H.323)?

Try netstat -ntlp (as root) - does it show Yate listening on port 1720? You
said something about that but I'm not absolutely sure.

If Yate listens on that port you may have a firewall blocking the incoming TCP
connections. H.323 uses many connections (both TCP and UDP) in both directions
for each call so I suggest allowing all ports in both directions and
selectively blocking only the known services you want to protect.

You can reduce the number of connections by setting h245tunneling=yes in
section [ep] of h323chan.conf - of course if the other party supports it too.

Tunneling is also required if the connecting client is behind a NAT - although
that configuration is not really supported and you may run into voice trouble.

Paul
Post by Rob Koliha
Hi Paul,
Thanks very much for your help. I made the configuration changes you
suggested and after some more troubleshooting, I still seem to be running into
the same issues. I thought that it could be a connectivity/firewall/routing
issue, so I also attempted to get this going with the windows version of Yate
on a machine that is in the same subnet as the digium pbx (with the same
results). I figured that using the windows version at minimum would help to
eliminate the possibility of my versions of pwlib, openh323, or something else
relating to my linux server as the culprit(s) for this problem.
Post by Rob Koliha
I have also tried removing the rules in the regexroute.conf file to allow me
to register to yate with an h323 client to do basic internal testing (self to
self or self or self to test numbers). That's not working either, same
symptoms with PacPhone -- GK Transport Error (or when dialing from Ekiga -
"Gatekeeper Cleared the Call"). I can register without issue via SIP. I'm a
novice at h323 and Yate is new to me, but based on the behavior it seems like
the establishing the h323 connection is the main issue - not the routing or
the SIP side. It's listening on 1720 at least, but I'm not seeing much more
:)
Post by Rob Koliha
If I attempt to make a SIP connection when running Yate as ./yate -vvvvv I
see on the console: <sip:INFO> Received 324 bytes SIP message from
ip.address:3344. If I attempt an h323 connection, the console doesn't display
any messages whatsoever. I have debug logging turned up to 9 for h323, is
there somewhere it dumps the logs to on the system?
Post by Rob Koliha
<cdrbuild:INFO> Got message 'call.route' for untracked id 'sip/2'
in 254 usec
Post by Rob Koliha
<sip:NOTE> Formats for 'audio' changed to 'mulaw' [0xf1dcd0]
accfile.conf, h323chan.conf, regexroute.conf, regfile.conf, yate.conf, and
ysipchan.conf. There are empty lines between the [ ] sections, I've just not
included them with this message to make it easier on the eyes.
Post by Rob Koliha
[...]
Loading...