asterisk users - Oct 2006 - Callmanager 3.3(5) and Asterisk with ooh323

I have experience problems like this in a different scenario. It is
usually due to codec translation problem.

What is the default codec set on CCM for the IP Phone and the default
set in Asterisk? Make sure the defaults are the same. Try G.711

Michael

I have tried GSL and ulaw.  tried one at a time.  tried both and even tried g729
and g7231.  still same issue.  Unless i am thinking of something different


-----Original Message-----
From: asterisk-users-bounces@lists.digium.com on behalf of Michael Araba
Sent: Tue 10/24/2006 10:36 PM
To: asterisk-users@lists.digium.com
Subject: RE: [asterisk-users] Callmanager 3.3(5) and Asterisk with ooh323
 
I have experience problems like this in a different scenario. It is
usually due to codec translation problem.

What is the default codec set on CCM for the IP Phone and the default
set in Asterisk? Make sure the defaults are the same. Try G.711

Michael

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3137 bytes
Desc: not available
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20061024/9429e26c/attachment.bin

PJ Wrote:
> Did you apply correct "calling search space" on callmanager 
> gateway configuration page for incomming calls from asterisk
> to callmanager?  imho, oh323 is obsolete/unmaintained, I'm using
> original chan_h323 with callmanager 4.1 and it working fine 
> (including dtmf), ooh323 is probably perspektive and working also,
> but currently is not working dtmf between callmanager and asterisk
> (ooh323) see: http://bugs.digium.com/view.php?id=8191
> PJ
PJ is correct the the most likely cause of call failures from
Asterisk to CCM is an improper Calling Search Space on CCM.  It
could also be a case that the number format that Asterisk is
sending to CCM is not correct, if CCM expects four digit extensions
Asterisk should not send six digit extensions.
> Ward, Bill wrote:
> I started from scratch again. This time i went with oh323 instead 
> of ooh323.  I still get the same issue but this time it says call 
> refused by remote host.  It doesn't explain why though.  I can't 
> understand the CCM trace logs to see why it might be refusing the 
> connection.
On the DTMF issues with chan_ooh323, I've used the channel with
CCM 4.0, 4.1 and 5.0 with no issues.  At one point I tested all
of the DTMF methods ooH323 provides.  CCM definately works with
h245signal, and in the past has worked with q931keypad and 
h245alphanumeric.  Cisco's support of RFC2833 in CCM has not
been impressive.  It works OK as of CCM 5.0 with SIP, but still
not so solid with H323.

Dan

PJ Wrote:
> Dan, can you supply your ooh323.conf for me? I would like resolve my 
> issue with not recognizing dtmf by ooh323 from callmanager
> my ooh323 is quite simple, also on callmanager config page for gateway
> to asterisk is nothing special, no faststart, no mtp; ccm v4.1.3sr3a
There's nothing secret about it, but I think I can skip that if the
settings below are what you are using-
> [general]
> disallow=all
> allow=alaw
> ;faststart=no
> ;h245tunneling=no
> [ccm]
> type=peer
> ip=192.168.40.7
> port=1720
> ;dtmfmode=rfc2833
> ;dtmfmode=h245signal
> ;h245tunneling=no
> ;faststart=no
I tend to use type=friend since I want calls in both
directions.
>From the list above, you have not set the dtmfmode in [general],
which is where I set it, or in the peer.  The sample ooh323.conf
shows that the default is RFC2833, which does not work with CCM.
Either uncomment ;dtmfmode=h245signal in the peer, or uncomment it
and move it to [general].


> Dan Austin wrote:
>>
>> On the DTMF issues with chan_ooh323, I've used the channel with
>> CCM 4.0, 4.1 and 5.0 with no issues.  At one point I tested all
>> of the DTMF methods ooH323 provides.  CCM definately works with
>> h245signal, and in the past has worked with q931keypad and 
>> h245alphanumeric.  Cisco's support of RFC2833 in CCM has not
>> been impressive.  It works OK as of CCM 5.0 with SIP, but still
>> not so solid with H323.

Dan

> I rebooted my CCM server and now the routing is working fine.  
> After a TON of reading i think i figured out how to get the 
> tracelogs from CCM.  Here is where the error appears to occur:
<snip>

This is getting to be more of a CCM support issue than an 
Asterisk issue.  Contact me offlist and I'll try to help you
get past this hurdle.

To attempt to tie this back to Asterisk, the error you are
seeing it related to no MTP resources.  If you are using an
older version of chan_ooh323 (v0.4 I think, -addons 1.2.4-ish),
the channel did not support the Empty Terminal Capability set
which would cause CCM to leverage a MTP during hold or transfer
events, also during transcoding (if needed)

But in any case it is still a CCM issue, so let us discuss that
offline.

Dan

> Dan, do you use ooh323 from asterisk 1.2.x or 1.4 branch?
> PJ
Both(ish)  I've run it on 1.2, and have 1.4 in testing now.
The (ish) is my production servers are actually a very old
trunk checkout that is closer to 1.2 than 1.4.

Dan

Pavel wrote:
> seems that my issue with ooh323 not recognizing dtmf setting from peer
> definition is, that peer/user was not matched on incomming call from 
> callmanager to ooh323, because ooh323 matches user/peer according to 
> incomming h323id (what is "caller id name" from callmanager, i.e.
if
my
> user/friend is defined as [Pavel Jezek] and I'm calling from
callmanager
> phone with caller id name Pavel Jezek, ooh323 successfully matches
ooh323
> peer (or better say type=user or friend). this matching behaviour is 
> quite useless in examples, when I would like to call to ooh323 from
any 
> ip phone behind callmanager....
> so in my scenario, I put dtmf setting under [general] and it works,
> but, imho, will be better, if ooh323 wil match according IP adres of 
> incomming call, instead of incomming h323id
Yup.  This is a known issue.  I presented a patch to fallback to
matching
on IP address if no other match is made.

There is/was a discussion on the ooh323-dev list about this and someone
else posted the same basic patch, but to date it has not been 'adopted'.

> .... but, I have another issue - with caller id:
> when calling from asterisk to callmanager (using ooh323), caller id 
> number is not passed to ip phone behind callmanager (I only see caller
> id name, not caller id number) it's curious, because from
tcpdump/Wireshark
> analysis - caller id number is present, so maybe "calling
presentation" is
> wrong set?
> from Wireshark (when calling from asterisk line 324, this info is not 
> displayed on phone behind callmager):
> Calling party number: '324'
> .... ..01 = Screening indicator: User-provided, verified and passed
(0x01)
> .01. .... = Presentation indicator: Presentation restricted (0x01)

Not sure on this one.  I do not normally place calls from Asterisk to 
CCM, we use Asterisk exclusively for conferencing, so I focus on getting
CCM calls into Asterisk.

Dan