Hello,
I can use directed call pickup using pickup application (between sip,
iax, skinny cals),
but unable to pickup call that is ringing on phone behind h323 gateway
(using original h323 channel in asterisk), is this even suported?
thx
PJ
exten => _*7.,1,Pickup(${EXTEN:2})
console log, when trying o pickup ringing line 324 (h323), from skinny
phone (953)
-- Executing Pickup("SCCP/953-00000004", "324") in new
stack
== Spawn extension (default, *7324, 1) exited non-zero on
'SCCP/953-00000004'
-- SCCP: Asterisk request to hangup channel SCCP/953-00000004
Pavel Jezek wrote:> Hello, > I can use directed call pickup using pickup application (between sip, > iax, skinny cals), > but unable to pickup call that is ringing on phone behind h323 gateway > (using original h323 channel in asterisk), is this even suported? > thx > PJ > > > > exten => _*7.,1,Pickup(${EXTEN:2}) > > > console log, when trying o pickup ringing line 324 (h323), from skinny > phone (953) > > > -- Executing Pickup("SCCP/953-00000004", "324") in new stack > == Spawn extension (default, *7324, 1) exited non-zero on > 'SCCP/953-00000004' > -- SCCP: Asterisk request to hangup channel SCCP/953-00000004 > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-usersThe directed pickup application needs a CDR record on the channel, so be sure that the H323 channel driver is creating one. You may need to set amaflags to have it happen. I remember this being found before by someone else, and that being there way to make it work. Joshua Colp
Pavel Jezek wrote:> Hello, > I can use directed call pickup using pickup application (between sip, > iax, skinny cals), > but unable to pickup call that is ringing on phone behind h323 gateway > (using original h323 channel in asterisk), is this even suported?I am going to say its not currently supported. If you provide me (offlist) some info on how to support it, I will find the time to attempt an implementation. Turn on H.323 debug and see what you get. Jeremy McNamara
Jeremy McNamara wrote:> Digium paid for ooh323, for whatever reasons that is beyond me, but it> has proven to be no better than any H.323 channel driver, so I hopethey> got their money back.Better is subjective in this case. There's no doubt that chan_ooh323 has some warts. On the other hand it has NO external library requirements, and works out of the box with Cisco's Call Manager. One could argue that Call Manager is crap. Fine, that doesn't change the fact some of us are stuck with it. Chan_h323 did not work with CCM, and a query/bug report was dismissed, basically stating that Cisco was F'd up and the channel would not be updated to work with it unless funded. (fair, but not helpful) Chan_oh323 worked with CCM, but suffered from the external library requirements. Chan_ooh323 just worked. The code is, to a infrequent programmer, easy to read, extend and fix bugs. So for me chan_ooh323 is a 'better' H.323 channel driver. Dan
On 04/06/06 04:41 Dan Austin said the following:> Chan_ooh323 just worked. The code is, to a infrequent programmer, > easy to read, extend and fix bugs.Dinesh wrote:> ok, i'm not getting into a my H323 is better than yours argument, but > we've been struggling to get OOH323 working with OHPHONE. symptoms are > that calls from SIP <--> OhPhone work fine, but when OhPhone callsSIP,> the call is hungup the moment the SIP phone answers. any clues why ?I did not intend to get that ball rolling. Each of the H.323 channels have at least one area that they work better than the others. The key is to find out which one works better for your needs. As to your problem, I have nothing specific, but I suspect codec/bearer capability issues, which is one area of weakness in ooh323. We only use it for trunking to CCM and have no H.323 clients. I have had excellent results with running a debug build of chan_ooh323 and submitting the logs to the ooh323 developer list. Dan
> Dan Austin wrote:>> Chan_h323 did not work with CCM, and a query/bug report wasdismissed,>> basically stating that Cisco was F'd up and the channel would not be >> updated to work with it unless funded. (fair, but not helpful)> chan_h323 most certainly does work with CCM. I have customers using > it all day (and night) long.OK, so I should have said the last time I tried to use it. The problem was one-way audio, and when I asked if it was a known issue, or there were any work arounds I was told it was a known issue and the work around was to not use CCM. I do not recall seeing a note that the issue had been addressed and I did the only thing I could at the time, which was to look elsewhere for H.323. Again I am not trying to knock any of the H.323 channels. They each have their strengths and the system administrator should use the one that works best for them. And in case it is not perfectly clear, I appreciate your efforts on both the H.323 and SCCP channels. Dan
Dan Austin wrote:>Again I am not trying to knock any of the H.323 channels. They >each have their strengths and the system administrator should use >the one that works best for them. > >The one thing nobody ever realizes is there there is very very limited interoperability in H.323. It is not any one particular channel drivers fault, it is the underlying H.323 stack and the recommendation passed down from the ITU - Which is not a specification, hence the problems everyone has with H.323. There was too much left open for interpretation. Again, everyone, stop blaming any one particular channel driver in Asterisk and start blaming H.323 itself. If for some crazy reason you still must run H.323, then you will always run into problems, no matter what H.323-based gear or software you utilize. Jeremy McNamara