> > > > Handling of fastStart in CallProceeding is commented out in h323plus > library, > this is exploration from h323plus developers about this: > > > Yes that should be mera. > > The problem is that Callproceeding does not always come from the remote it > may be generated by the gatekeeper.
this is a feature .. called force_callproceeding. It means MERA will send a provisional CallProceeding in order not to timeout on calls that don't respond with that message on time. If this message contains a faststart element it is certanly a bug and it has to be reported to them. > MERA where sending fast start elements > in the Call proceeding and connect. The call proceeding where not valid and > causing the media to fail. well if there is a correct faststart element within a connect message (or alerting or facility or progress), the originator should adjust the media resources accordingly. Here what could went wrong is just the media before the next faststart element in the row. > Normally (although valid) EP's do not set Fast > Start in Call proceeding so the code was disabled to resolve the MERA > issue. > > well, this is unlikely as fast start element can be included in call proceeding message. The developer's task is to determine whether a call proceeding message is to be trusted or not. Also, provisional call proceeding messages don't have faststart element included! There are equipment (Cisco PGW / HSI) that are sending call proceeding with faststart element and h245Controll (OLC + TCS/MSD) that has to be treated correctly. Unfortunately, just disabling handling of callproceeding faststart element is not a real option... > if you wont read "bugs" file in mod_h323, there is explaned how to enable > it. > of course i can enable it during build time but this will not solve interop issues later we can encounter... Do you maybe have some sniffs/traces of the wrong call proceeding message ? ...anyhow this is the expected behaviour when a GK/Proxy sends a provisional Call Proceding to the terminator and later it receives the real Call Proceeding carring faststart and h245Controll element within. Entities in the signalling path shall also use the Facility message or the Progress message to convey any new information (such as Q.931 information elements, CallProceeding-UUIE fields, tunnelled non-H.323 protocols, and encapsulated H.245 messages) received in a Call Proceeding message to the other endpoint if the entity has already sent a Call Proceeding message. This will allow the entity, for example, to transmit the fastStart element to facilitate proper establishment of a Fast Connect call and/or a Progress Indicator to indicate the presence of in-band tones and announcements. When using the Facility message to carrying such information extracted from the Call Proceeding message, the reason in the Facility should be set to forwardedElements. in other words: ORIG GK TERM ------------------------------------------------------------------------------------------------------------- Setup OLC => Call proceeding (prov) <= Setup OLC => Call proceeding (OLC+TCS/MSD) <= Facility (OLC+TCS/MSD) <= <----------- normal call establishment scenario follows ----------->
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org