Hi again, I have found in the posts something intersting. I think it is the solutuion I look for. Please see below --------------------------------------------------------------------- Benni, Thanks for your contribution and ofcourse for nice words. I agree with you, and your changes are perfectly in sync with the rest of the code. So I will just copy paste them. Thanks for that. For, faststart in alerting message we need to do two things: 1. Remove the faststart response code from ooAcceptCall function in ooq931.c and make it a separate function. 2. Call this function in both ooSendAlerting and ooAcceptCall functions. 3. Probabely we will need a flag, to make sure that we don't start channels again while sending faststart response through connect. I have created tasks on sourceforge website (http://sourceforge.net/projects/ooh323c/) to keep track of things. If anyone else has any suggestions, want to report bugs, post them on list as well as sourceforge site. -Vishal ------------------------------------------------------------------ I think if we have such a function and call it after sending ALERTING message it will open the RTP channels for receiving the in-bnad anouncements. Avin, is Vishal your colleage? Can he help with this function?
Thank you! BR mortex >-------- Оригинално писмо -------- >От: "Avin Patel" <[EMAIL PROTECTED]> >Относно: RE: RE: [ooh323c-devel] ooh323 q931 signalling problem >До: "ooh323c" <ooh323c-devel@lists.sourceforge.net> >Изпратено на: Четвъвтък, 2006, Юни 8 01:05:19 EEST >---------------------------------- > >Hi Mortex, > >> >Does your question is ooh323c should check Progress-Indicator? or >> >Did you mean ooh323c to generate ALERTING message with Q.931 Progress >> >Indicator Element? >> >> I mean, ooh3232 to send Alerting message with Q.931 Progress >> Indicator Element (PI = 3 or PI=8) and opens the RTP channel >> before sending CONNECT message, i.e to cut-throuh the voice path >> on both directions and proxy the in-band announcemnts from PSTN side. >> > >I guess you have mentioned in your last email, that you already have a >patch. >Than we all be happy. > >Here I think there is two case: >1. Adding PI bit in Q.931 header with ALERTING message for indicating >rining, busy, .... That you have patch for. > >2. ooh323c to send ALERTING message, to reception of ALERTING from other >end(PSTN), > I will check this to make sure that ooh323c responds on >asterisk-alerting event, not ooh323c timer based. > >> >I guess, ALERTING means ringtone stage, There is no fake >> ringtone/Alerting. >> >Or you can says fake, if other end phone ringer is not working ;) >> >> Yes, good joke :) What I say is that when I call to PSTN (H323 GW >> -> ASTERISK+SANGOMA -> PSTN) my GW plays ringback tone >> immediately but after 10 sec. the PSTN side rings. This is >> because the H323 GW doesn't receive the PI indicator in the Q.931 >> ALERTING message and thinks it should generate local ring-back >> tone but not to wait to receive it from the PSTN side as it >> should be. In order to solve this, i think, ooh323 should send >> PI=8 and cut-through the audio path until the call is connected. >> >> >Here: >> >GnuGK <------- [ ooh323c - asterisk core - SANGOMA FXO(PSTN interface)] >> ><---- PSTN >> > >> >So in Asterisk internal dealing (PSTN to H.323 conversion): >> >Sangoma indicates to Asterisk Core (ringing). >> >Asterisk Core generates ALERTING event for ooh323c, ooh323c >> sents ALERTING >> >to GnuGK. Do you want PI bit here? >> >> No, I talk about the situation when the call from VoiP side is >> terminated on PSTN network. Please see the above explanation. >> >Yes, I have mentioned the ALERTING sequence. As the PSTN has to inform >alerting to gnugk. > >> >If you want to do more than fast start by saying early media. >> Than you have >> >to play with non-established channels. >> > >> >> With "early media" I mean completion of the bearer transmission >> path of a voice call before the call is answered (connected). >> >> Waiting for youe comments. >> > >When you use fast start, all proposed channels are ready to communicate. But >you don't know which channel to use, till the codec negotiation ends. >Clearing up codec negotiation before CONNECT, is depends on both end point >negotiation taktics, rather than one (I think). >So it will be, Not always works way. >So I don't know, this you can utilize in early media ? > >If you have something else in mind, please provide exact sequence of >operations and as much possible details. >Than we can see where we can incorporate this. > >I think other way is both end point know what codec to use, so use the >proposed RTP channel for known codec. I think that would be easy. > >Regards, >Avin Patel >Objective Systems, Inc. > > > > ----------------------------------------------------------------- http://www.sportni.bg/worldcup/ - Германия 2006 - Световното първенство по футбол наближава! _______________________________________________ ooh323c-devel mailing list ooh323c-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ooh323c-devel
