[Freeswitch-users] Fwd: mod_opal - call charged before H.225 connect

Tihomir Culjaga tculjaga at gmail.com
Wed Oct 28 02:24:25 PDT 2009


>
>
>
> 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 ----------->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20091028/26c33883/attachment-0002.html 


More information about the FreeSWITCH-users mailing list