VoIP Mailing List Archives

[brian at freeswitch.org]

AS per the email you and I exchanged we created the account and the
mod_h323 folder in endpoints....

/b

On Oct 22, 2009, at 9:34 AM, Georgiewskiy Yuriy wrote:

[bottleman at icf.org.ru]

On 2009-10-22 09:27 -0500, Anthony Minessale wrote freeswitch-users@lists.f...:

AM>crash protection has been completely removed from FreeSWITCH, I certianly
AM>hope you are working on this against SVN trunk?

i don't have trunk at this time, my current work is based on 1.0.4 version.

AM>Also you have been given an
AM>svn area and a jira category for this so you should move all the info from
AM>this thread to jira http://jira.freeswitch.org
AM>
AM>It's much easier to collaberate this kind of development when you have the
AM>code in SVN.
AM>
AM>
AM>2009/10/22 Georgiewskiy Yuriy <bottleman@icf.org.ru>
AM>
AM>> On 2009-10-22 16:04 +0200, Tihomir Culjaga wrote
AM>> freeswitch-users@lists.fre...:
AM>>
AM>> TC>On Thu, Oct 22, 2009 at 3:59 PM, Tihomir Culjaga <tculjaga@gmail.com>
AM>> wrote:
AM>> TC>
AM>> TC>>
AM>> TC>>> TC>Hi, here is the FS log without crash-protection:
AM>> TC>>> TC>http://pastebin.freeswitch.org/10796 and here is the backtrace:
AM>> TC>>> TC>http://pastebin.freeswitch.org/10797
AM>> TC>>>
AM>> TC>>> i fix this crash already, please download latest version from same
AM>> link
AM>> TC>>> as previous, recompile and try again.
AM>> TC>>>
AM>> TC>>>
AM>> TC>> outgoing works, I can place an end-to-end call ... except the RTP is
AM>> realy
AM>> TC>> delayed ... after approx 30 sec of conversation the audio is delayed
AM>> more
AM>> TC>> than 10 seconds.... but i have 2 way audio for outgoing calls:)
AM>> TC>>
AM>> TC>>
AM>> TC>one more thing ... it is H323 endpoint => SIP phone audio that is
AM>> delayed.
AM>> TC>SIP phone => H323 endpoint is ok!
AM>>
AM>> hm, i have such issue but in reverce direction now.
AM>>
AM>> TC>> Do you need some logs ?
AM>> TC>>
AM>> TC>>
AM>> TC>> Inbound cals still the same... i suppose you didn't have a chance
AM>> working
AM>> TC>> on that as well ...
AM>> TC>>
AM>> TC>> T.
AM>> TC>>
AM>> TC>
AM>>
AM>> C Õ×ÁÖÅÎÉÅÍ With Best Regards
AM>> çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
AM>> +7 4872 711666 +7 4872 711666
AM>> ÆÁËÓ +7 4872 711143 fax +7 4872 711143
AM>> ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
AM>> http://nkoort.ru http://nkoort.ru
AM>> JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
AM>> YG129-RIPE YG129-RIPE
AM>>
AM>> _______________________________________________
AM>> FreeSWITCH-users mailing list
AM>> FreeSWITCH-users@lists.freeswitch.org
AM>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
AM>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
AM>> http://www.freeswitch.org
AM>>
AM>>
AM>
AM>
AM>

C Õ×ÁÖÅÎÉÅÍ With Best Regards
çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
ÆÁËÓ +7 4872 711143 fax +7 4872 711143
ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
YG129-RIPE YG129-RIPE
_______________________________________________
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

[tculjaga at gmail.com]

[tculjaga at gmail.com]

2009/10/22 Georgiewskiy Yuriy <bottleman@icf.org.ru (bottleman@icf.org.ru)>

[bottleman at icf.org.ru]

On 2009-10-22 16:53 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:

finally i fix this rtp bug, check new wersion please.

TC>>
TC>> TC>
TC>> TC>Do you need some logs ?
TC>>
TC>> try disable medai-proxy, there is issue with rtp now then medai-proxy or
TC>> transcoding enabled.
TC>>
TC>>
TC>Outbound calls:
TC>
TC>disabled rtp proxy and it is still the same issue ... audio delay H323 =>
TC>SIP endpoint.
TC>
TC>
TC>
TC>
TC>
TC>
TC>Inbound calls:
TC>
TC>This is the extension i use to register my Avaya SIP phone to FS.
TC>
TC>
TC><include>
TC> <user id="1001">
TC> <params>
TC> <param name="password" value="$${default_password}"/>
TC> <param name="vm-password" value="1001"/>
TC> </params>
TC> <variables>
TC> <variable name="toll_allow" value="domestic,international,local"/>
TC> <variable name="accountcode" value="1001"/>
TC> <variable name="user_context" value="default"/>
TC> <variable name="effective_caller_id_name" value="Extension 1001"/>
TC> <variable name="effective_caller_id_number" value="1001"/>
TC> <variable name="outbound_caller_id_name"
TC>value="$${outbound_caller_name}"/>
TC> <variable name="outbound_caller_id_number"
TC>value="$${outbound_caller_id}"/>
TC> <variable name="callgroup" value="techsupport"/>
TC> </variables>
TC> </user>
TC></include>
TC>
TC>
TC>This is my h323.conf.xml
TC>
TC>
TC><configuration name="h323.conf" description="H323 Endpoints">
TC> <settings>
TC> <param name="trace-level" value="4"/>
TC> <param name="context" value="default"/>
TC> <param name="dialplan" value="XML"/>
TC> <param name="codec-prefs" value="PCMU,PCMA,GSM,G729,G726"/>
TC> <param name="gk-address" value=""/> <!-- empty to disable, "*" to
TC>search LAN -->
TC> <param name="gk-identifer" value=""/> <!-- optional name of gk -->
TC> <param name="gk-interface" value=""/> <!-- optional listener interface
TC>name -->
TC> </settings>
TC> <listeners>
TC> <listener name="default">
TC> <param name="h323-ip" value="10.4.62.7"/>
TC> <param name="h323-port" value="1720"/>
TC> </listener>
TC> </listeners>
TC></configuration>
TC>
TC>I'm using default context and an inbound call looks for a registered user in
TC>default context where 1001 user is registered to.
TC>
TC>
TC>
TC>here is the log for an outgoing call:
TC>http://pastebin.freeswitch.org/10799and here is a tshark output:
TC>http://pastebin.freeswitch.org/10800
TC>
TC>
TC>there are 2 thing that are not working here:
TC>
TC>
TC>1. no audio at all!
TC>2. hangup from SIP User side doesn't release the H323 leg
TC>
TC>
TC>
TC>
TC>
TC>
TC>
TC>
TC>
TC>
TC>
TC>two points for your reference in the logs:
TC>
TC>
TC>1. Here, SIP User disconnected the SIP leg, but nothing was triggered in
TC>mod_h323 ... as the callback function "on_hangup" (in mod_h323.cpp) was
TC>never triggered!
TC>
TC>freeswitch@subZero>
TC>freeswitch@subZero>
TC>freeswitch@subZero> recv 371 bytes from udp/[10.4.62.89]:5060 at
TC>14:39:36.714521:
TC> ------------------------------------------------------------------------
TC> BYE sip:mod_sofia@10.4.62.7:5060 SIP/2.0
TC> From: <sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>
TC>;transport=udp>;tag=-22166b474ae08abf-7_T10.4.62.89
TC> To: sip:1001282166@10.4.62.7 <sip%3A1001282166@10.4.62.7>
TC>;tag=Qpc53NZ2cZc1N
TC> Call-ID: 8aa825c6-39bb-122d-bb89-00110a5be1f0
TC> CSeq: 127 BYE
TC> Via: SIP/2.0/UDP
TC>10.4.62.89;branch=z9hG4bK-7e5dc720_442d0f8-2d8bf1174f235bec_B
TC> Content-Length: 0
TC> Max-Forwards: 70
TC> Supported: replaces
TC>
TC> ------------------------------------------------------------------------
TC>2009-10-22 16:39:36.714604 [NOTICE] sofia.c:322 Hangup sofia/internal/
TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> [CS_CONSUME_MEDIA]
TC>[NORMAL_CLEARING]
TC>2009-10-22 16:39:36.714604 [DEBUG] switch_channel.c:1683 Send signal
TC>sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> [KILL]
TC>2009-10-22 16:39:36.714604 [DEBUG] switch_core_session.c:932 Send signal
TC>sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> [BREAK]
TC>send 520 bytes to udp/[10.4.62.89]:5060 at 14:39:36.715258:
TC> ------------------------------------------------------------------------
TC> SIP/2.0 200 OK
TC> Via: SIP/2.0/UDP
TC>10.4.62.89;branch=z9hG4bK-7e5dc720_442d0f8-2d8bf1174f235bec_B
TC> From: <sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>
TC>;transport=udp>;tag=-22166b474ae08abf-7_T10.4.62.89
TC> To: sip:1001282166@10.4.62.7 <sip%3A1001282166@10.4.62.7>
TC>;tag=Qpc53NZ2cZc1N
TC> Call-ID: 8aa825c6-39bb-122d-bb89-00110a5be1f0
TC> CSeq: 127 BYE
TC> User-Agent: FreeSWITCH-mod_sofia/1.0.4-exported
TC> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
TC>NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH
TC> Supported: timer, precondition, path, replaces
TC> Content-Length: 0
TC>
TC> ------------------------------------------------------------------------
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:503
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) State
TC>CONSUME_MEDIA going to sleep
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:398
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) Running State
TC>Change CS_HANGUP
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:434
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) State HANGUP
TC>2009-10-22 16:39:36.721097 [DEBUG] mod_sofia.c:338 Channel sofia/internal/
TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> hanging up, cause:
TC>NORMAL_CLEARING
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:46
TC>sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> Standard HANGUP,
TC>cause: NORMAL_CLEARING
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:434
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) State HANGUP
TC>going to sleep
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:476
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) State Change
TC>CS_HANGUP -> CS_REPORTING
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_session.c:932 Send signal
TC>sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> [BREAK]
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:398
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) Running State
TC>Change CS_REPORTING
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:612
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) State REPORTING
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:53
TC>sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> Standard
TC>REPORTING, cause: NORMAL_CLEARING
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:612
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) State REPORTING
TC>going to sleep
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_state_machine.c:411
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) State Change
TC>CS_REPORTING -> CS_DESTROY
TC>2009-10-22 16:39:36.721097 [DEBUG] switch_core_session.c:1068 Session 10
TC>(sofia/internal/sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>) Locked, Waiting
TC>on external entities
TC>
TC>freeswitch@subZero>
TC>
TC>
TC>
TC>
TC>
TC>2. switch_ivr_originate.c complains => 2009-10-22 16:39:41.630243 [ERR]
TC>switch_ivr_originate.c:1510 Cannot create outgoing channel of type [user]
TC>cause: [NORMAL_CLEARING]
TC>
TC>
TC>freeswitch@subZero>
TC>freeswitch@subZero>
TC>freeswitch@subZero> 2009-10-22 16:39:41.630243 [DEBUG] h323pdu.cxx:609
TC>Receiving PDU [ip$10.4.62.7:1720/ip$10.4.62.31:16013] :
TC> {
TC> q931pdu = {
TC> protocolDiscriminator = 8
TC> callReference = 23
TC> from = originator
TC> messageType = ReleaseComplete
TC> IE: Cause - Normal ca
TC>ll clearing = {
TC> 80 90 ..
TC> }
TC> IE: User-User = {
TC> 25 80 06 00 08 91 4a 00 04 11 00 11 00 96 40 1f %.....J.......@.
TC> 4e be 4f 11 de 80 76 ae 99 96 03 ba ff 10 80 01 N.O.
TC>..v.........
TC> ...
TC> }
TC> }
TC> h225pdu = {
TC> h323_uu_pdu = {
TC> h323_message_body = releaseComplete {
TC> protocolIdentifier = 0.0.8.2250.0.4
TC> callIdentifier = {
TC> guid = 16 octets {
TC> 96 40
TC> 1f 4e be 4f 11 de 80 76 ae 99 96 03 ba ff .@.N.O...v......
TC> }
TC> }
TC> }
TC> h245Tunneling = true
TC> }
TC> }
TC> }
TC>2009-10-22 16:39:41.630243 [DEBUG] h323.cxx:1292 Handling PDU:
TC>ReleaseComplete callRef=23
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_h323.cpp:745
TC>======>FSH323Connection::OnReceivedReleaseComplete cause = Normal call
TC>clearing value = 16
TC>2009-10-22 16:39:41.630243 [NOTICE] mod_h323.cpp:749 Hangup h323/1001
TC>[CS_EXECUTE] [NORMAL_CLEARING]
TC>2009-10-22 16:39:41.630243 [DEBUG] switch_channel.c:1683 Send signal
TC>h323/1001 [KILL]
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_h323.cpp:840
TC>======>FSH323Connection::kill_channel FSH323Connection
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_h323.cpp:841 Kill 1 on connection
TC>FSH323Connection
TC>2009-10-22 16:39:41.630243 [DEBUG] switch_core_session.c:630 Send signal
TC>h323/1001 [BREAK]
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_h323.cpp:840
TC>======>FSH323Connection::kill_channel FSH323Connection
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_h323.cpp:841 Kill 3 on connection
TC>FSH323Connection
TC>2009-10-22 16:39:41.630243 [DEBUG] switch_ivr_originate.c:2138 Originate
TC>Resulted in Error Cause: 16 [NORMAL_CLEARING]
TC>2009-10-22 16:39:41.630243 [ERR] switch_ivr_originate.c:1510 Cannot create
TC>outgoing channel of type [user] cause: [NORMAL_CLEARING]
TC>2009-10-22 16:39:41.630243 [DEBUG] switch_ivr_originate.c:2138 Originate
TC>Resulted in Error Cause: 16 [NORMAL_CLEARING]
TC>2009-10-22 16:39:41.630243 [INFO] mod_dptools.c:2093 Originate Failed.
TC>Cause: NORMAL_CLEARING
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_dptools.c:2120 Continue on fail
TC>[true]: Cause: NORMAL_CLEARING
TC>2009-10-22 16:39:41.630243 [DEBUG] switch_core_state_machine.c:491
TC>(h323/1001) State EXECUTE going to sleep
TC>2009-10-22 16:39:41.630243 [DEBUG] switch_core_state_machine.c:398
TC>(h323/1001) Running State Change CS_HANGUP
TC>2009-10-22 16:39:41.630243 [DEBUG] switch_core_state_machine.c:434
TC>(h323/1001) State HANGUP
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_h323.cpp:1454 ======>switch_status_t
TC>on_hangup
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_h323.cpp:1459 ----->
TC>2009-10-22 16:39:41.630243 [DEBUG] h323pdu.cxx:1272 Call End Reason Normal
TC>call clearing
TC>2009-10-22 16:39:41.630243 [DEBUG] h323ep.cxx:2694 Clearing connection ip$
TC>10.4.62.31:16013/23 reason=EndedByRemoteUser
TC>2009-10-22 16:39:41.630243 [DEBUG] h323.cxx:1034 Call end reason for ip$
TC>10.4.62.31:16013/23 set to EndedByRemoteUser
TC>2009-10-22 16:39:41.630243 [DEBUG] h323.cxx:1052 Sending release complete
TC>PDU: callRef=23
TC>2009-10-22 16:39:41.630243 [DEBUG] mod_h323.cpp:764
TC>======>FSH323Connection::OnSendReleaseComplete cause = Normal call clearing
TC>value = 16
TC>2009-10-22 16:39:41.630243 [DEBUG] h323pdu.cxx:609 Sending PDU
TC>[(noaddr)/(noaddr)] :
TC> command endSessionCommand disconnect <<null>>
TC>2009-10-22 16:39:41.630243 [DEBUG] h323pdu.cxx:609 Sending PDU [ip$
TC>10.4.62.7:1720/ip$10.4.62.31:16013] :
TC>

C Õ×ÁÖÅÎÉÅÍ With Best Regards
çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
ÆÁËÓ +7 4872 711143 fax +7 4872 711143
ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
YG129-RIPE YG129-RIPE
_______________________________________________
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

[tculjaga at gmail.com]

2009/10/22 Georgiewskiy Yuriy <bottleman@icf.org.ru (bottleman@icf.org.ru)>

[bottleman at icf.org.ru]

On 2009-10-22 21:44 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:

TC>2009/10/22 Georgiewskiy Yuriy <bottleman@icf.org.ru>
TC>
TC>> On 2009-10-22 16:53 +0200, Tihomir Culjaga wrote
TC>> freeswitch-users@lists.fre...:
TC>>
TC>> finally i fix this rtp bug, check new wersion please.
TC>>
TC>>
TC>if course i can do that, but tomorrow morning ... i'm not in the office
TC>anymore.
TC>BTW: can we please move the tickets to jira?
TC>
TC>
TC>it is gonna be easier to track.
TC>
TC>Tomorrow i will test on 1.0.4 but please lets move to trunk.

i make it a bit later, to move tickets to jira and source to svn i
need some time to undertand how this system is works, especially jira.

C Õ×ÁÖÅÎÉÅÍ With Best Regards
çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
ÆÁËÓ +7 4872 711143 fax +7 4872 711143
ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
YG129-RIPE YG129-RIPE
_______________________________________________
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

[tculjaga at gmail.com]

[tculjaga at gmail.com]

btw you are back with an old issue:


static const char modulename[] = "h323";
static const char* h323_formats[] = {
    "G.711-ALaw-64k", "PCMU",
    "G.711-uLaw-64k", "PCMA",
    "GSM-06.10", "GSM",
    "MS-GSM", "msgsm",
    "SpeexNarrow", "speex",

[bottleman at icf.org.ru]

On 2009-10-23 10:16 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:

TC>> TC>
TC>> TC>it is gonna be easier to track.
TC>> TC>
TC>> TC>Tomorrow i will test on 1.0.4 but please lets move to trunk.
TC>>
TC>> i make it a bit later, to move tickets to jira and source to svn i
TC>> need some time to undertand how this system is works, especially jira.
TC>>
TC>>
TC>audio issue is better now
TC>
TC>however i have a few questions:
TC>
TC>1. can we control codec framing size via config file setting (e.g. PCMA:20,
TC>PCMU:20)?

at this time i think no, there is a number issues in codec part now.

TC>2. can we control tunneling via config file setting?

at this time no, i implement it later.

TC>3. can we control mediaWaitForConnect flag within setup message via config
TC>file setting?

what is mediaWaitForConnect flag, may be another trmin in h323?

TC>Now, when i can test more and place outgoing calls to different equipment, i
TC>found that there is an issue when we get h.225 progress without a fastStart
TC>element.
TC>
TC>Here is a tshark:
TC>
TC> 5.242526 10.4.62.7 -> 10.4.4.254 H.225.0 CS: setup OpenLogicalChannel
TC>
TC> 5.243982 10.4.4.254 -> 10.4.62.7 H.225.0 CS: callProceeding
TC> 10.512617 10.4.4.254 -> 10.4.62.7 H.225.0 CS: progress
TC> 10.983697 10.4.4.254 -> 10.4.62.7 H.225.0 CS: alerting
TC> 20.002796 10.4.4.254 -> 10.4.62.7 H.225.0 CS: connect
TC> 20.002981 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySet
TC> 20.003210 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDetermination
TC> 31.472362 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: releaseComplete
TC>endSessionCommand
TC>
TC>
TC>the terminating GW didn't include a faststart element within a returning
TC>h.225 message we didn't match the capabilities (framing of them) in our
TC>setup (and you are waiting an open LC to start pre_answer).... so now, the
TC>terminator is waiting for the originator to start exchanging TCS/MSD. As
TC>tunneling is true, this should be done using h.225 Facility messages.
TC>
TC>
TC>your behavior should be like this:
TC>
TC> 5.242526 10.4.62.7 -> 10.4.4.254 H.225.0 CS: setup
TC>OpenLogicalChannel g711A with 30 ms
TC> 5.243982 10.4.4.254 -> 10.4.62.7 H.225.0 CS: callProceeding
TC> 10.512617 10.4.4.254 -> 10.4.62.7 H.225.0 CS: progress
TC>
TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS: facility
TC>terminalCapabilitySet
TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS: facility
TC>masterSlaveDetermination
TC>
TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySet
TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDetermination
TC>
TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySetAck
TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDeterminationAck
TC>
TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS: facility
TC>terminalCapabilitySetAck
TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS: facility
TC>masterSlaveDeterminationAck
TC>
TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS: facility
TC>openlogicalchannel (g711A)
TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>openlogicalchannel (g711A)
TC>
TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS: facility
TC>openlogicalchannelAck
TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>openlogicalchannelAck
TC>
TC> <now you can start pre_answer!>
TC>
TC> 10.983697 10.4.4.254 -> 10.4.62.7 H.225.0 CS: alerting
TC>...

may bee, while i in hospital i have a very limited ways for testing,
especially for inbound calls throuce h323. i find one issues in signaling
part in h323plus, src/h323.cxx grep "Very Frustrating - S.H." try uncomment
fast start handling there, may be it help.

C Õ×ÁÖÅÎÉÅÍ With Best Regards
çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
ÆÁËÓ +7 4872 711143 fax +7 4872 711143
ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
YG129-RIPE YG129-RIPE
_______________________________________________
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

[bottleman at icf.org.ru]

On 2009-10-23 10:44 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:

TC>btw you are back with an old issue:
TC>
TC>
TC>static const char modulename[] = "h323";
TC>static const char* h323_formats[] = {
TC> "G.711-ALaw-64k", "PCMU",
TC> "G.711-uLaw-64k", "PCMA",
TC> "GSM-06.10", "GSM",
TC> "MS-GSM", "msgsm",
TC> "SpeexNarrow", "speex",

there is a isues with codecs, it is not enoth to put it there to work,
at this time work only PCMU PCMA GSM and G729.


C Õ×ÁÖÅÎÉÅÍ With Best Regards
çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
ÆÁËÓ +7 4872 711143 fax +7 4872 711143
ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
YG129-RIPE YG129-RIPE
_______________________________________________
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

[tculjaga at gmail.com]

i meant you switched PCMA and PCMU...

T.

2009/10/23 Georgiewskiy Yuriy <bottleman@icf.org.ru (bottleman@icf.org.ru)>

[bottleman at icf.org.ru]

On 2009-10-23 13:22 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:

my bad, thx.

TC>i meant you switched PCMA and PCMU...
TC>
TC>T.
TC>
TC>2009/10/23 Georgiewskiy Yuriy <bottleman@icf.org.ru>
TC>
TC>> On 2009-10-23 10:16 +0200, Tihomir Culjaga wrote
TC>> freeswitch-users@lists.fre...:
TC>>
TC>> TC>> TC>
TC>> TC>> TC>it is gonna be easier to track.
TC>> TC>> TC>
TC>> TC>> TC>Tomorrow i will test on 1.0.4 but please lets move to trunk.
TC>> TC>>
TC>> TC>> i make it a bit later, to move tickets to jira and source to svn i
TC>> TC>> need some time to undertand how this system is works, especially jira.
TC>> TC>>
TC>> TC>>
TC>> TC>audio issue is better now
TC>> TC>
TC>> TC>however i have a few questions:
TC>> TC>
TC>> TC>1. can we control codec framing size via config file setting (e.g.
TC>> PCMA:20,
TC>> TC>PCMU:20)?
TC>>
TC>> at this time i think no, there is a number issues in codec part now.
TC>>
TC>> TC>2. can we control tunneling via config file setting?
TC>>
TC>> at this time no, i implement it later.
TC>>
TC>> TC>3. can we control mediaWaitForConnect flag within setup message via
TC>> config
TC>> TC>file setting?
TC>>
TC>> what is mediaWaitForConnect flag, may be another trmin in h323?
TC>>
TC>> TC>Now, when i can test more and place outgoing calls to different
TC>> equipment, i
TC>> TC>found that there is an issue when we get h.225 progress without a
TC>> fastStart
TC>> TC>element.
TC>> TC>
TC>> TC>Here is a tshark:
TC>> TC>
TC>> TC> 5.242526 10.4.62.7 -> 10.4.4.254 H.225.0 CS: setup
TC>> OpenLogicalChannel
TC>> TC>
TC>> TC> 5.243982 10.4.4.254 -> 10.4.62.7 H.225.0 CS: callProceeding
TC>> TC> 10.512617 10.4.4.254 -> 10.4.62.7 H.225.0 CS: progress
TC>> TC> 10.983697 10.4.4.254 -> 10.4.62.7 H.225.0 CS: alerting
TC>> TC> 20.002796 10.4.4.254 -> 10.4.62.7 H.225.0 CS: connect
TC>> TC> 20.002981 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>> TC>terminalCapabilitySet
TC>> TC> 20.003210 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>> TC>masterSlaveDetermination
TC>> TC> 31.472362 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS:
TC>> releaseComplete
TC>> TC>endSessionCommand
TC>> TC>
TC>> TC>
TC>> TC>the terminating GW didn't include a faststart element within a
TC>> returning
TC>> TC>h.225 message we didn't match the capabilities (framing of them) in our
TC>> TC>setup (and you are waiting an open LC to start pre_answer).... so now,
TC>> the
TC>> TC>terminator is waiting for the originator to start exchanging TCS/MSD. As
TC>> TC>tunneling is true, this should be done using h.225 Facility messages.
TC>> TC>
TC>> TC>
TC>> TC>your behavior should be like this:
TC>> TC>
TC>> TC> 5.242526 10.4.62.7 -> 10.4.4.254 H.225.0 CS: setup
TC>> TC>OpenLogicalChannel g711A with 30 ms
TC>> TC> 5.243982 10.4.4.254 -> 10.4.62.7 H.225.0 CS: callProceeding
TC>> TC> 10.512617 10.4.4.254 -> 10.4.62.7 H.225.0 CS: progress
TC>> TC>
TC>> TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS:
TC>> facility
TC>> TC>terminalCapabilitySet
TC>> TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS:
TC>> facility
TC>> TC>masterSlaveDetermination
TC>> TC>
TC>> TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS:
TC>> facility
TC>> TC>terminalCapabilitySet
TC>> TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS:
TC>> facility
TC>> TC>masterSlaveDetermination
TC>> TC>
TC>> TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS:
TC>> facility
TC>> TC>terminalCapabilitySetAck
TC>> TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS:
TC>> facility
TC>> TC>masterSlaveDeterminationAck
TC>> TC>
TC>> TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS:
TC>> facility
TC>> TC>terminalCapabilitySetAck
TC>> TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS:
TC>> facility
TC>> TC>masterSlaveDeterminationAck
TC>> TC>
TC>> TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS:
TC>> facility
TC>> TC>openlogicalchannel (g711A)
TC>> TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS:
TC>> facility
TC>> TC>openlogicalchannel (g711A)
TC>> TC>
TC>> TC> 10.4.62.7 -> 10.4.4.254 H.225.0/H.245 CS:
TC>> facility
TC>> TC>openlogicalchannelAck
TC>> TC> 10.4.4.254 -> 10.4.62.7 H.225.0/H.245 CS:
TC>> facility
TC>> TC>openlogicalchannelAck
TC>> TC>
TC>> TC> <now you can start pre_answer!>
TC>> TC>
TC>> TC> 10.983697 10.4.4.254 -> 10.4.62.7 H.225.0 CS: alerting
TC>> TC>...
TC>>
TC>> may bee, while i in hospital i have a very limited ways for testing,
TC>> especially for inbound calls throuce h323. i find one issues in signaling
TC>> part in h323plus, src/h323.cxx grep "Very Frustrating - S.H." try uncomment
TC>> fast start handling there, may be it help.
TC>>
TC>> C Õ×ÁÖÅÎÉÅÍ With Best Regards
TC>> çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
TC>> +7 4872 711666 +7 4872 711666
TC>> ÆÁËÓ +7 4872 711143 fax +7 4872 711143
TC>> ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
TC>> http://nkoort.ru http://nkoort.ru
TC>> JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
TC>> YG129-RIPE YG129-RIPE
TC>>
TC>> _______________________________________________
TC>> FreeSWITCH-users mailing list
TC>> FreeSWITCH-users@lists.freeswitch.org
TC>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
TC>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
TC>> http://www.freeswitch.org
TC>>
TC>>
TC>

C Õ×ÁÖÅÎÉÅÍ With Best Regards
çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
ÆÁËÓ +7 4872 711143 fax +7 4872 711143
ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
YG129-RIPE YG129-RIPE
_______________________________________________
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

[tculjaga at gmail.com]

[bottleman at icf.org.ru]

On 2009-10-23 13:52 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:

TC>>
TC>> TC>3. can we control mediaWaitForConnect flag within setup message via
TC>> config
TC>> TC>file setting?
TC>>
TC>> what is mediaWaitForConnect flag, may be another trmin in h323?
TC>>
TC>>
TC>>
TC>If the calling endpoint sets the mediaWaitForConnect element to TRUE in the
TC>Setup message, then
TC>the called endpoint shall not send any media until after the Connect message
TC>is sent.
TC>The calling endpoint may begin transmitting media (according to the channels
TC>opened) immediately
TC>upon receiving a Q.931 message containing fastStart. Thus, the called
TC>endpoint must be prepared to
TC>immediately receive media on the channels it accepted in the Q.931 message
TC>containing fastStart.
TC>Note that national requirements may prohibit calling endpoints from
TC>transmitting media prior to
TC>receipt of a Connect message; it is the responsibility of the endpoint to
TC>comply with applicable
TC>requirements.
TC>
TC>
TC>check "H225_Setup_UUIE & H323SignalPDU::BuildSetup" within src/h323pdu.cxx
TC>(H323plus)

i think it can be implemented later, but, why it may be needed? can you explain some
situation where it need?

TC>> TC>...
TC>>
TC>> may bee, while i in hospital i have a very limited ways for testing,
TC>> especially for inbound calls throuce h323. i find one issues in signaling
TC>> part in h323plus, src/h323.cxx grep "Very Frustrating - S.H." try uncomment
TC>> fast start handling there, may be it help.
TC>>
TC>>
TC>I'm not sure it is gonna help. This is only for CallProceeding having a
TC>faststart element... What i have is a progress message without a faststart
TC>element but with h245 address... it should go to StartControlChannel but i
TC>think it is stuck since you call pre_answer before it actually opens a LC.
TC>
TC>
TC>PBoolean H323Connection::OnReceivedProgress(const H323SignalPDU & pdu)
TC>{
TC> if (pdu.m_h323_uu_pdu.m_h323_message_body.GetTag() !=
TC>H225_H323_UU_PDU_h323_message_body::e_progress)
TC> return FALSE;
TC> const H225_Progress_UUIE & progress =
TC>pdu.m_h323_uu_pdu.m_h323_message_body;
TC>
TC> SetRemoteVersions(progress.m_protocolIdentifier);
TC> SetRemotePartyInfo(pdu);
TC> SetRemoteApplication(progress.m_destinationInfo);
TC>
TC> // Check for fastStart data and start fast
TC> if (progress.HasOptionalField(H225_Progress_UUIE::e_fastStart))
TC> HandleFastStartAcknowledge(progress.m_fastStart);
TC>
TC> // Check that it has the H.245 channel connection info
TC> if (progress.HasOptionalField(H225_Progress_UUIE::e_h245Address))
TC> return StartControlChannel(progress.m_h245Address);
TC>
TC> return TRUE;
TC>}
TC>
TC>
TC>
TC>you should handle this and postpone pre_answer until you get an open LC.

pre_answer is not complete at this time, i say it a some kinde of hack, there is
another issues with it ans sofia in case proxy-media true.

C Õ×ÁÖÅÎÉÅÍ With Best Regards
çÅÏÒÇÉÅ×ÓËÉÊ àÒÉÊ. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
ÆÁËÓ +7 4872 711143 fax +7 4872 711143
ëÏÍÐÁÎÉÑ ïïï "áÊ ôÉ óÅÒ×ÉÓ" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: GHhost@jabber.tula-ix.net.ru JID: GHhost@jabber.tula-ix.net.ru
YG129-RIPE YG129-RIPE
_______________________________________________
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