VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
tculjaga at gmail.com
Guest
|
 Posted: Fri Oct 23, 2009 7:48 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
 |
|
| Quote: |
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>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.
|
bool FSH323Connection::OnReceivedProgress(const H323SignalPDU &pdu)
{
PTRACE(4, "mod_h323\t======>FSH323Connection::OnReceivedProgress");
m_txAudioOpened.Wait();
switch_channel_mark_pre_answered(m_fsChannel);
return true;
}
so for me the workaround for this was:
bool FSH323Connection::OnReceivedProgress(const H323SignalPDU &pdu)
{
PTRACE(4, "mod_h323\t======>FSH323Connection::OnReceivedProgress");
PTRACE(4, "mod_h323\t======>FSH323Connection::OnReceivedProgress - disabled pre_answer!!!!");
//m_txAudioOpened.Wait();
//switch_channel_mark_pre_answered(m_fsChannel);
return true;
} |
|
| Back to top |
|
 |
bottleman at icf.org.ru
Guest
|
| Posted: Fri Oct 23, 2009 8:06 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
On 2009-10-23 14:38 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:
TC>>
TC>> TC>check "H225_Setup_UUIE & H323SignalPDU::BuildSetup" within
TC>> src/h323pdu.cxx
TC>> TC>(H323plus)
TC>>
TC>> i think it can be implemented later, but, why it may be needed? can you
TC>> explain some
TC>> situation where it need?
TC>>
TC>>
TC>> TC>
TC>> TC>you should handle this and postpone pre_answer until you get an open LC.
TC>>
TC>> pre_answer is not complete at this time, i say it a some kinde of hack,
TC>> there is
TC>> another issues with it ans sofia in case proxy-media true.
TC>>
TC>>
TC>
TC>bool FSH323Connection::OnReceivedProgress(const H323SignalPDU &pdu)
TC>{
TC> PTRACE(4, "mod_h323\t======>FSH323Connection::OnReceivedProgress");
TC> m_txAudioOpened.Wait();
TC> switch_channel_mark_pre_answered(m_fsChannel);
TC> return true;
TC>}
TC>
TC>
TC>
TC>so for me the workaround for this was:
TC>
TC>
TC>
TC>
TC>bool FSH323Connection::OnReceivedProgress(const H323SignalPDU &pdu)
TC>{
TC> PTRACE(4, "mod_h323\t======>FSH323Connection::OnReceivedProgress");
TC>
TC> PTRACE(4, "mod_h323\t======>FSH323Connection::OnReceivedProgress -
TC>disabled pre_answer!!!!");
TC>
TC> //m_txAudioOpened.Wait();
TC> //switch_channel_mark_pre_answered(m_fsChannel);
TC> return true;
TC>}
TC>
in that chase wee are not hear anything going inband if receive progress ind from called h323 endpoint,
there will bee ringback, for exmaple mobule fone then it out of network. if you dont need
this make this changes until i fix it.
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 |
|
| Back to top |
|
|
tculjaga at gmail.com
Guest
|
| Posted: Fri Oct 23, 2009 8:23 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
| Quote: |
TC>
TC>bool FSH323Connection::OnReceivedProgress(const H323SignalPDU &pdu)
TC>{
TC> PTRACE(4, "mod_h323\t======>FSH323Connection::OnReceivedProgress");
TC>
TC> PTRACE(4, "mod_h323\t======>FSH323Connection::OnReceivedProgress -
TC>disabled pre_answer!!!!");
TC>
TC> //m_txAudioOpened.Wait();
TC> //switch_channel_mark_pre_answered(m_fsChannel);
TC> return true;
TC>}
TC>
in that chase wee are not hear anything going inband if receive progress ind from called h323 endpoint,
there will bee ringback, for exmaple mobule fone then it out of network. if you dont need
this make this changes until i fix it.
|
not true, because you have mediaWaitForConnect = false... the terminating endpoint can send media before H.225 connect message.... and this actually works well 
7.317880 10.4.62.89 -> 10.4.62.7 SIP/SDP Request: INVITE sip:00914392122@singtel, with session description
7.318319 10.4.62.7 -> 10.4.62.89 SIP Status: 100 Trying
7.331430 10.4.62.7 -> 10.4.62.89 SIP Status: 407 Proxy Authentication Required
7.339420 10.4.62.89 -> 10.4.62.7 SIP Request: ACK sip:00914392122@singtel
7.345078 10.4.62.89 -> 10.4.62.7 SIP/SDP Request: INVITE sip:00914392122@singtel, with session description
7.345378 10.4.62.7 -> 10.4.62.89 SIP Status: 100 Trying
7.387166 10.4.62.7 -> 10.4.4.254 H.225.0 CS: setup OpenLogicalChannel
7.388636 10.4.4.254 -> 10.4.62.7 H.225.0 CS: callProceeding
9.389852 10.4.4.254 -> 10.4.62.7 H.225.0 CS: progress
10.639897 10.4.4.254 -> 10.4.62.7 H.225.0 CS: alerting
10.651322 10.4.62.7 -> 10.4.62.89 SIP Status: 180 Ringing
10.653932 10.4.62.7 -> 10.4.198.113 H.245 terminalCapabilitySet
10.654565 10.4.62.7 -> 10.4.198.113 H.245 masterSlaveDetermination
10.659757 10.4.198.113 -> 10.4.62.7 H.245 terminalCapabilitySet
10.659814 10.4.198.113 -> 10.4.62.7 H.245 masterSlaveDetermination
10.660161 10.4.198.113 -> 10.4.62.7 H.245 terminalCapabilitySetAck
10.660238 10.4.198.113 -> 10.4.62.7 H.245 masterSlaveDeterminationAck
10.666028 10.4.62.7 -> 10.4.198.113 H.245 terminalCapabilitySetAck
10.670388 10.4.62.7 -> 10.4.198.113 H.245 masterSlaveDeterminationAck
10.674693 10.4.198.113 -> 10.4.62.7 H.245 openLogicalChannel (g711A)
10.682410 10.4.62.7 -> 10.4.62.7 RTP Unknown RTP version 1
#678: OLC found 10.4.62.7/10.4.198.113/129
10.683902 10.4.62.7 -> 10.4.198.113 H.245 openLogicalChannelAck
10.687378 10.4.62.7 -> 10.4.198.113 H.245 openLogicalChannel (g711A)
#723: OLC found 10.4.198.113/10.4.62.7/108
10.691579 10.4.198.113 -> 10.4.62.7 H.245 openLogicalChannelAck
10.778413 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=0, Time=24640
10.798476 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=1, Time=24800
10.818432 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=2, Time=24960
<-------------- snip ------------->
13.298358 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=126, Time=44800
13.318460 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=127, Time=44960
13.338405 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=128, Time=45120
13.358353 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=129, Time=45280
13.369984 10.4.4.254 -> 10.4.62.7 H.225.0 CS: connect
13.378381 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=130, Time=45440
13.382330 10.4.62.7 -> 10.4.62.89 SIP/SDP Status: 200 OK, with session description
13.388833 10.4.62.7 -> 10.4.62.7 RTP Unknown RTP version 3
13.389123 10.4.62.7 -> 10.4.62.7 RTP Unknown RTP version 3
13.396419 10.4.62.89 -> 10.4.62.7 SIP Request: ACK sip:00914392122@10.4.62.7:5060;transport=udp
13.398457 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=131, Time=45600
13.405954 10.4.62.89 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMU, SSRC=0xDEF4B36, Seq=27943, Time=991142687
13.418401 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=132, Time=45760
13.425864 10.4.62.89 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMU, SSRC=0xDEF4B36, Seq=27944, Time=991142847
13.438360 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=133, Time=45920
13.438570 10.4.62.7 -> 10.4.62.89 RTP PT=ITU-T G.711 PCMA, SSRC=0x172DD4B, Seq=46377, Time=640
13.446202 10.4.62.89 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0xDEF4B36, Seq=27945, Time=991143007
13.458320 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=134, Time=46080
13.458467 10.4.62.7 -> 10.4.62.89 RTP PT=ITU-T G.711 PCMA, SSRC=0x172DD4B, Seq=46378, Time=800
13.459008 10.4.62.7 -> 10.4.142.38 RTP PT=ITU-T G.711 PCMA, SSRC=0xB9D8D8, Seq=1379, Time=991143007
13.466010 10.4.62.89 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0xDEF4B36, Seq=27946, Time=991143167
13.478408 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=135, Time=46240
13.478470 10.4.62.7 -> 10.4.142.38 RTP PT=ITU-T G.711 PCMA, SSRC=0xB9D8D8, Seq=1380, Time=991143167
13.478749 10.4.62.7 -> 10.4.62.89 RTP PT=ITU-T G.711 PCMA, SSRC=0x172DD4B, Seq=46379, Time=960
<------------ snip -------------->
15.098561 10.4.62.7 -> 10.4.62.89 RTP PT=ITU-T G.711 PCMA, SSRC=0x172DD4B, Seq=46460, Time=13920
15.099011 10.4.62.7 -> 10.4.142.38 RTP PT=ITU-T G.711 PCMA, SSRC=0xB9D8D8, Seq=1461, Time=991156127
15.105847 10.4.62.89 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0xDEF4B36, Seq=28028, Time=991156287
15.118353 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=217, Time=59360
15.118434 10.4.62.7 -> 10.4.62.89 RTP PT=ITU-T G.711 PCMA, SSRC=0x172DD4B, Seq=46461, Time=14080
15.119540 10.4.62.7 -> 10.4.142.38 RTP PT=ITU-T G.711 PCMA, SSRC=0xB9D8D8, Seq=1462, Time=991156287
15.122951 10.4.198.113 -> 10.4.62.7 H.245 closeLogicalChannel
15.122986 10.4.198.113 -> 10.4.62.7 H.245 endSessionCommand
15.125003 10.4.62.7 -> 10.4.62.7 RTP Unknown RTP version 3
15.125257 10.4.62.7 -> 10.4.198.113 H.245 closeLogicalChannelAck
15.125857 10.4.62.89 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0xDEF4B36, Seq=28029, Time=991156447
15.127900 10.4.62.7 -> 10.4.198.113 H.245 endSessionCommand
15.128461 10.4.62.7 -> 10.4.4.254 H.225.0 CS: releaseComplete
15.138328 10.4.142.38 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0x1EC68E26, Seq=218, Time=59520
15.139550 10.4.62.7 -> 10.4.62.7 RTP Unknown RTP version 3
15.142189 10.4.62.7 -> 10.4.62.89 SIP Request: BYE sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]);transport=udp
15.145990 10.4.62.89 -> 10.4.62.7 RTP PT=ITU-T G.711 PCMA, SSRC=0xDEF4B36, Seq=28030, Time=991156607
15.146010 10.4.62.7 -> 10.4.62.89 ICMP Destination unreachable (Port unreachable)
15.150016 10.4.62.89 -> 10.4.62.7 SIP Status: 200 OK
so the real solution is to implement a check for CallProceeding , Progress and Facility message whether it has a faststart element included. It it is true than you might start pre_answer.
also, i don't see any handling of Call Proceeding ... what if there is a fastStart element in CallProceeding message? 
T.
T. |
|
| Back to top |
|
|
tculjaga at gmail.com
Guest
|
| Posted: Fri Oct 23, 2009 10:09 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
a solution to H323 endpoint => FS => SIP user no audio issue
is to disable a wait for tx Audio ... for case SWITCH_MESSAGE_INDICATE_ANSWER:{
//m_txAudioOpened.Wait();
case SWITCH_MESSAGE_INDICATE_ANSWER:{
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CONSOLE, "ANSWER: we got Answer event\n");
if (switch_channel_test_flag(channel, CF_OUTBOUND)) {
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CONSOLE, "ANSWER: we got Answer event - CF_OUTBOUND
\n");
return SWITCH_STATUS_FALSE;
}
AnsweringCall(H323Connection::AnswerCallNow);
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CONSOLE, "ANSWER: suppose the call is Answered Now\n");
PTRACE(4, "mod_h323\tMedia started on connection " << *this);
// test
//switch_channel_mark_answered(m_fsChannel);
m_rxAudioOpened.Wait();
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CONSOLE, "ANSWER: wait for m_rxAudioOpened\n");
//m_txAudioOpened.Wait();
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CONSOLE, "ANSWER: we disable wait for m_txAudioOpened\n");
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CONSOLE, "ANSWER: were waiting for rx/tx AudioOpen\n");
if (!switch_channel_test_flag(m_fsChannel, CF_EARLY_MEDIA)) {
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CONSOLE, "ANSWER: we have early media\n");
PTRACE(4, "mod_h323\t-------------------->switch_channel_mark_answered(m_fsChannel) " << *this);
switch_channel_mark_answered(m_fsChannel);
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CONSOLE, "ANSWER: answered in early Media\n");
}
break;
}
Now, I'm able to both originate and terminate cals with 2-way audio...
the signaling looks correct...
outgoing:
1369.425046 10.4.62.7 -> 10.4.62.89 SIP/SDP Request: INVITE sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]);transport=udp, with session description
1369.426255 10.4.62.7 -> 10.4.62.31 H.225.0 CS: alerting
1369.435950 10.4.62.89 -> 10.4.62.7 SIP Status: 100 Trying
1369.449065 10.4.62.89 -> 10.4.62.7 SIP Status: 180 Ringing
1369.605109 10.4.62.7 -> 10.4.62.31 H.225.0 CS: progress OpenLogicalChannel
1369.609788 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility terminalCapabilitySet
1369.610489 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility masterSlaveDetermination
1369.619071 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty terminalCapabilitySet
1369.620349 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty terminalCapabilitySetAck
1369.623215 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility terminalCapabilitySetAck
1369.625591 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty masterSlaveDeterminationAck
1369.628174 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility masterSlaveDeterminationAck
1370.966958 10.4.62.89 -> 10.4.62.7 SIP/SDP Status: 200 OK, with session description
1370.967431 10.4.62.7 -> 10.4.62.89 SIP Request: ACK sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]);transport=udp
1370.975172 10.4.62.7 -> 10.4.62.31 H.225.0 CS: connect
1372.354383 10.4.62.89 -> 10.4.62.7 SIP Request: BYE sip:mod_sofia@10.4.62.7:5060
1372.355147 10.4.62.7 -> 10.4.62.89 SIP Status: 200 OK
1372.392904 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: releaseComplete endSessionCommand
1372.397302 10.4.62.31 -> 10.4.62.7 H.225.0 CS: releaseComplete
incoming:
1502.817154 10.4.62.31 -> 10.4.62.7 H.225.0 CS: setup OpenLogicalChannel
1502.833732 10.4.62.7 -> 10.4.62.31 H.225.0 CS: callProceeding
1502.850909 10.4.62.7 -> 10.4.62.89 SIP/SDP Request: INVITE sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]);transport=udp, with session description
1502.851758 10.4.62.7 -> 10.4.62.31 H.225.0 CS: alerting
1502.861828 10.4.62.89 -> 10.4.62.7 SIP Status: 100 Trying
1502.875127 10.4.62.89 -> 10.4.62.7 SIP Status: 180 Ringing
1503.033258 10.4.62.7 -> 10.4.62.31 H.225.0 CS: progress OpenLogicalChannel
1503.037908 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility terminalCapabilitySet
1503.038608 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility masterSlaveDetermination
1503.050154 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty terminalCapabilitySet
1503.051381 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty terminalCapabilitySetAck
1503.054297 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility terminalCapabilitySetAck
1503.054917 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty masterSlaveDeterminationAck
1503.057933 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility masterSlaveDeterminationAck
1505.485493 10.4.62.89 -> 10.4.62.7 SIP/SDP Status: 200 OK, with session description
1505.486018 10.4.62.7 -> 10.4.62.89 SIP Request: ACK sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]);transport=udp
1505.493611 10.4.62.7 -> 10.4.62.31 H.225.0 CS: connect
1509.565959 10.4.62.89 -> 10.4.62.7 SIP Request: BYE sip:mod_sofia@10.4.62.7:5060
1509.566722 10.4.62.7 -> 10.4.62.89 SIP Status: 200 OK
1509.577435 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: releaseComplete endSessionCommand
1509.582066 10.4.62.31 -> 10.4.62.7 H.225.0 CS: releaseComplete
... i still need to check the CDRs as well but here we are |
|
| Back to top |
|
|
bottleman at icf.org.ru
Guest
|
| Posted: Fri Oct 23, 2009 10:31 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
On 2009-10-23 16:57 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:
i have question to developers about one proce in fs
src/switch_ivr_originate.c
static switch_status_t originate_on_consume_media_transmit(switch_core_session_t *session)
{
switch_channel_t *channel = switch_core_session_get_channel(session);
if (!switch_channel_test_flag(channel, CF_PROXY_MODE)) {
while (switch_channel_get_state(channel) == CS_CONSUME_MEDIA && !switch_channel_test_flag(chann
if (!switch_channel_media_ready(channel)) {
switch_yield(10000);
} else {
switch_ivr_sleep(session, 10, SWITCH_FALSE, NULL);
}
}
}
switch_channel_clear_state_handler(channel, &originate_state_handlers);
return SWITCH_STATUS_FALSE;
}
what exacly it do?
call scheme like this sip->fs->h323->gk->h323(on same fs)->fs(same too) and there i have no audio issues.
if bridge connect while it sleep i have audio, if it not sleep while bridge connect i have no audio.
TC>a solution to H323 endpoint => FS => SIP user no audio issue
TC>
TC>is to disable a wait for tx Audio ... for case
TC>SWITCH_MESSAGE_INDICATE_ANSWER:{
TC>
TC>//m_txAudioOpened.Wait();
TC>
TC>
TC> case SWITCH_MESSAGE_INDICATE_ANSWER:{
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: we got Answer event\n");
TC>
TC> if (switch_channel_test_flag(channel, CF_OUTBOUND))
TC>{
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: we got Answer event - CF_OUTBOUND
TC>\n");
TC> return SWITCH_STATUS_FALSE;
TC> }
TC> AnsweringCall(H323Connection::AnswerCallNow);
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: suppose the call is Answered Now\n");
TC> PTRACE(4, "mod_h323\tMedia started on connection "
TC><< *this);
TC>
TC> // test
TC> //switch_channel_mark_answered(m_fsChannel);
TC>
TC> m_rxAudioOpened.Wait();
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: wait for m_rxAudioOpened\n");
TC> //m_txAudioOpened.Wait();
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: we disable wait for m_txAudioOpened\n");
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: were waiting for rx/tx AudioOpen\n");
TC>
TC> if (!switch_channel_test_flag(m_fsChannel,
TC>CF_EARLY_MEDIA)) {
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: we have early media\n");
TC>
TC> PTRACE(4,
TC>"mod_h323\t-------------------->switch_channel_mark_answered(m_fsChannel) "
TC><< *this);
TC> switch_channel_mark_answered(m_fsChannel);
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: answered in early Media\n");
TC> }
TC> break;
TC> }
TC>
TC>
TC>Now, I'm able to both originate and terminate cals with 2-way audio...
TC>the signaling looks correct...
TC>
TC>
TC>
TC>outgoing:
TC>
TC>1369.425046 10.4.62.7 -> 10.4.62.89 SIP/SDP Request: INVITE
TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>;transport=udp, with session
TC>description
TC>1369.426255 10.4.62.7 -> 10.4.62.31 H.225.0 CS: alerting
TC>1369.435950 10.4.62.89 -> 10.4.62.7 SIP Status: 100 Trying
TC>1369.449065 10.4.62.89 -> 10.4.62.7 SIP Status: 180 Ringing
TC>1369.605109 10.4.62.7 -> 10.4.62.31 H.225.0 CS: progress
TC>OpenLogicalChannel
TC>1369.609788 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySet
TC>1369.610489 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDetermination
TC>1369.619071 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>terminalCapabilitySet
TC>1369.620349 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>terminalCapabilitySetAck
TC>1369.623215 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySetAck
TC>1369.625591 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>masterSlaveDeterminationAck
TC>1369.628174 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDeterminationAck
TC>1370.966958 10.4.62.89 -> 10.4.62.7 SIP/SDP Status: 200 OK, with
TC>session description
TC>1370.967431 10.4.62.7 -> 10.4.62.89 SIP Request: ACK
TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>;transport=udp
TC>1370.975172 10.4.62.7 -> 10.4.62.31 H.225.0 CS: connect
TC>1372.354383 10.4.62.89 -> 10.4.62.7 SIP Request: BYE
TC>sip:mod_sofia@10.4.62.7:5060
TC>1372.355147 10.4.62.7 -> 10.4.62.89 SIP Status: 200 OK
TC>1372.392904 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: releaseComplete
TC>endSessionCommand
TC>1372.397302 10.4.62.31 -> 10.4.62.7 H.225.0 CS: releaseComplete
TC>
TC>
TC>incoming:
TC>
TC>
TC>1502.817154 10.4.62.31 -> 10.4.62.7 H.225.0 CS: setup
TC>OpenLogicalChannel
TC>1502.833732 10.4.62.7 -> 10.4.62.31 H.225.0 CS: callProceeding
TC>1502.850909 10.4.62.7 -> 10.4.62.89 SIP/SDP Request: INVITE
TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>;transport=udp, with session
TC>description
TC>1502.851758 10.4.62.7 -> 10.4.62.31 H.225.0 CS: alerting
TC>1502.861828 10.4.62.89 -> 10.4.62.7 SIP Status: 100 Trying
TC>1502.875127 10.4.62.89 -> 10.4.62.7 SIP Status: 180 Ringing
TC>1503.033258 10.4.62.7 -> 10.4.62.31 H.225.0 CS: progress
TC>OpenLogicalChannel
TC>1503.037908 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySet
TC>1503.038608 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDetermination
TC>1503.050154 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>terminalCapabilitySet
TC>1503.051381 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>terminalCapabilitySetAck
TC>1503.054297 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySetAck
TC>1503.054917 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>masterSlaveDeterminationAck
TC>1503.057933 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDeterminationAck
TC>1505.485493 10.4.62.89 -> 10.4.62.7 SIP/SDP Status: 200 OK, with
TC>session description
TC>1505.486018 10.4.62.7 -> 10.4.62.89 SIP Request: ACK
TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89>;transport=udp
TC>1505.493611 10.4.62.7 -> 10.4.62.31 H.225.0 CS: connect
TC>1509.565959 10.4.62.89 -> 10.4.62.7 SIP Request: BYE
TC>sip:mod_sofia@10.4.62.7:5060
TC>1509.566722 10.4.62.7 -> 10.4.62.89 SIP Status: 200 OK
TC>1509.577435 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: releaseComplete
TC>endSessionCommand
TC>1509.582066 10.4.62.31 -> 10.4.62.7 H.225.0 CS: releaseComplete
TC>
TC>
TC>
TC>... i still need to check the CDRs as well but here we are
TC>
can you send a diff? in you call scheme call from h323 endpoint to fs is not have RAS?,
because i don't have no audio issues in transit from h323 to sip, but my calls a going
thorough GK and fs is regitered on them, my call scheme is h323ep-RAS->GK-RAS->fs.
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 |
|
| Back to top |
|
|
anthony.minessale at g...
Guest
|
| Posted: Fri Oct 23, 2009 10:48 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
if you were on trunk that line of code would be gone.
you really can't do development on 1.0.4 its 6 months old and it will cause you more trouble than you think when you eventually upgrade if you do not do it soon.
2009/10/23 Georgiewskiy Yuriy <bottleman@icf.org.ru (bottleman@icf.org.ru)>
| Quote: | On 2009-10-23 16:57 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:
i have question to developers about one proce in fs
src/switch_ivr_originate.c
static switch_status_t originate_on_consume_media_transmit(switch_core_session_t *session)
{
switch_channel_t *channel = switch_core_session_get_channel(session);
if (!switch_channel_test_flag(channel, CF_PROXY_MODE)) {
while (switch_channel_get_state(channel) == CS_CONSUME_MEDIA && !switch_channel_test_flag(chann
if (!switch_channel_media_ready(channel)) {
switch_yield(10000);
} else {
switch_ivr_sleep(session, 10, SWITCH_FALSE, NULL);
}
}
}
switch_channel_clear_state_handler(channel, &originate_state_handlers);
return SWITCH_STATUS_FALSE;
}
what exacly it do?
call scheme like this sip->fs->h323->gk->h323(on same fs)->fs(same too) and there i have no audio issues.
if bridge connect while it sleep i have audio, if it not sleep while bridge connect i have no audio.
TC>a solution to H323 endpoint => FS => SIP user no audio issue
TC>
TC>is to disable a wait for tx Audio ... for case
TC>SWITCH_MESSAGE_INDICATE_ANSWER:{
TC>
TC>//m_txAudioOpened.Wait();
TC>
TC>
TC> case SWITCH_MESSAGE_INDICATE_ANSWER:{
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: we got Answer event\n");
TC>
TC> if (switch_channel_test_flag(channel, CF_OUTBOUND))
TC>{
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: we got Answer event - CF_OUTBOUND
TC>\n");
TC> return SWITCH_STATUS_FALSE;
TC> }
TC> AnsweringCall(H323Connection::AnswerCallNow);
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: suppose the call is Answered Now\n");
TC> PTRACE(4, "mod_h323\tMedia started on connection "
TC><< *this);
TC>
TC> // test
TC> //switch_channel_mark_answered(m_fsChannel);
TC>
TC> m_rxAudioOpened.Wait();
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: wait for m_rxAudioOpened\n");
TC> //m_txAudioOpened.Wait();
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: we disable wait for m_txAudioOpened\n");
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: were waiting for rx/tx AudioOpen\n");
TC>
TC> if (!switch_channel_test_flag(m_fsChannel,
TC>CF_EARLY_MEDIA)) {
TC>
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: we have early media\n");
TC>
TC> PTRACE(4,
TC>"mod_h323\t-------------------->switch_channel_mark_answered(m_fsChannel) "
TC><< *this);
TC> switch_channel_mark_answered(m_fsChannel);
TC> switch_log_printf(SWITCH_CHANNEL_LOG,
TC>SWITCH_LOG_CONSOLE, "ANSWER: answered in early Media\n");
TC> }
TC> break;
TC> }
TC>
TC>
TC>Now, I'm able to both originate and terminate cals with 2-way audio...
TC>the signaling looks correct...
TC>
TC>
TC>
TC>outgoing:
TC>
TC>1369.425046 10.4.62.7 -> 10.4.62.89 SIP/SDP Request: INVITE
TC>sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]) <sip%3A1001@10.4.62.89 ([email]sip%253A1001@10.4.62.89[/email])>;transport=udp, with session
TC>description
TC>1369.426255 10.4.62.7 -> 10.4.62.31 H.225.0 CS: alerting
TC>1369.435950 10.4.62.89 -> 10.4.62.7 SIP Status: 100 Trying
TC>1369.449065 10.4.62.89 -> 10.4.62.7 SIP Status: 180 Ringing
TC>1369.605109 10.4.62.7 -> 10.4.62.31 H.225.0 CS: progress
TC>OpenLogicalChannel
TC>1369.609788 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySet
TC>1369.610489 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDetermination
TC>1369.619071 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>terminalCapabilitySet
TC>1369.620349 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>terminalCapabilitySetAck
TC>1369.623215 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySetAck
TC>1369.625591 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>masterSlaveDeterminationAck
TC>1369.628174 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDeterminationAck
TC>1370.966958 10.4.62.89 -> 10.4.62.7 SIP/SDP Status: 200 OK, with
TC>session description
TC>1370.967431 10.4.62.7 -> 10.4.62.89 SIP Request: ACK
TC>sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]) <sip%3A1001@10.4.62.89 ([email]sip%253A1001@10.4.62.89[/email])>;transport=udp
TC>1370.975172 10.4.62.7 -> 10.4.62.31 H.225.0 CS: connect
TC>1372.354383 10.4.62.89 -> 10.4.62.7 SIP Request: BYE
TC>sip:mod_sofia@10.4.62.7:5060
TC>1372.355147 10.4.62.7 -> 10.4.62.89 SIP Status: 200 OK
TC>1372.392904 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: releaseComplete
TC>endSessionCommand
TC>1372.397302 10.4.62.31 -> 10.4.62.7 H.225.0 CS: releaseComplete
TC>
TC>
TC>incoming:
TC>
TC>
TC>1502.817154 10.4.62.31 -> 10.4.62.7 H.225.0 CS: setup
TC>OpenLogicalChannel
TC>1502.833732 10.4.62.7 -> 10.4.62.31 H.225.0 CS: callProceeding
TC>1502.850909 10.4.62.7 -> 10.4.62.89 SIP/SDP Request: INVITE
TC>sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]) <sip%3A1001@10.4.62.89 ([email]sip%253A1001@10.4.62.89[/email])>;transport=udp, with session
TC>description
TC>1502.851758 10.4.62.7 -> 10.4.62.31 H.225.0 CS: alerting
TC>1502.861828 10.4.62.89 -> 10.4.62.7 SIP Status: 100 Trying
TC>1502.875127 10.4.62.89 -> 10.4.62.7 SIP Status: 180 Ringing
TC>1503.033258 10.4.62.7 -> 10.4.62.31 H.225.0 CS: progress
TC>OpenLogicalChannel
TC>1503.037908 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySet
TC>1503.038608 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDetermination
TC>1503.050154 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>terminalCapabilitySet
TC>1503.051381 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>terminalCapabilitySetAck
TC>1503.054297 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>terminalCapabilitySetAck
TC>1503.054917 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
TC>masterSlaveDeterminationAck
TC>1503.057933 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
TC>masterSlaveDeterminationAck
TC>1505.485493 10.4.62.89 -> 10.4.62.7 SIP/SDP Status: 200 OK, with
TC>session description
TC>1505.486018 10.4.62.7 -> 10.4.62.89 SIP Request: ACK
TC>sip:1001@10.4.62.89 ([email]sip%3A1001@10.4.62.89[/email]) <sip%3A1001@10.4.62.89 ([email]sip%253A1001@10.4.62.89[/email])>;transport=udp
TC>1505.493611 10.4.62.7 -> 10.4.62.31 H.225.0 CS: connect
TC>1509.565959 10.4.62.89 -> 10.4.62.7 SIP Request: BYE
TC>sip:mod_sofia@10.4.62.7:5060
TC>1509.566722 10.4.62.7 -> 10.4.62.89 SIP Status: 200 OK
TC>1509.577435 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: releaseComplete
TC>endSessionCommand
TC>1509.582066 10.4.62.31 -> 10.4.62.7 H.225.0 CS: releaseComplete
TC>
TC>
TC>
TC>... i still need to check the CDRs as well but here we are
TC>
can you send a diff? in you call scheme call from h323 endpoint to fs is not have RAS?,
because i don't have no audio issues in transit from h323 to sip, but my calls a going
thorough GK and fs is regitered on them, my call scheme is h323ep-RAS->GK-RAS->fs.
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 (GHhost@jabber.tula-ix.net.ru) JID: GHhost@jabber.tula-ix.net.ru (GHhost@jabber.tula-ix.net.ru)
YG129-RIPE YG129-RIPE
_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (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
|
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm
MSN:anthony_minessale@hotmail.com ([email]MSN%3Aanthony_minessale@hotmail.com[/email])
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com ([email]PAYPAL%3Aanthony.minessale@gmail.com[/email])
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org ([email]sip%3A888@conference.freeswitch.org[/email])
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org ([email]googletalk%3Aconf%2B888@conference.freeswitch.org[/email])
pstn:213-799-1400 |
|
| Back to top |
|
|
bottleman at icf.org.ru
Guest
|
| Posted: Fri Oct 23, 2009 11:06 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
On 2009-10-23 10:37 -0500, Anthony Minessale wrote freeswitch-users@lists.f...:
i have no way to install trunk at this time, i will go out of hospital about one week later, after
this i will can try it on trunk.
AM>if you were on trunk that line of code would be gone.
AM>you really can't do development on 1.0.4 its 6 months old and it will cause
AM>you more trouble than you think when you eventually upgrade if you do not do
AM>it soon.
AM>
AM>
AM>2009/10/23 Georgiewskiy Yuriy <bottleman@icf.org.ru>
AM>
AM>> On 2009-10-23 16:57 +0200, Tihomir Culjaga wrote
AM>> freeswitch-users@lists.fre...:
AM>>
AM>> i have question to developers about one proce in fs
AM>>
AM>> src/switch_ivr_originate.c
AM>>
AM>> static switch_status_t
AM>> originate_on_consume_media_transmit(switch_core_session_t *session)
AM>> {
AM>> switch_channel_t *channel = switch_core_session_get_channel(session);
AM>>
AM>> if (!switch_channel_test_flag(channel, CF_PROXY_MODE)) {
AM>> while (switch_channel_get_state(channel) == CS_CONSUME_MEDIA
AM>> && !switch_channel_test_flag(chann
AM>> if (!switch_channel_media_ready(channel)) {
AM>> switch_yield(10000);
AM>> } else {
AM>> switch_ivr_sleep(session, 10, SWITCH_FALSE,
AM>> NULL);
AM>> }
AM>> }
AM>> }
AM>>
AM>> switch_channel_clear_state_handler(channel,
AM>> &originate_state_handlers);
AM>>
AM>> return SWITCH_STATUS_FALSE;
AM>> }
AM>>
AM>> what exacly it do?
AM>>
AM>> call scheme like this sip->fs->h323->gk->h323(on same fs)->fs(same too) and
AM>> there i have no audio issues.
AM>> if bridge connect while it sleep i have audio, if it not sleep while bridge
AM>> connect i have no audio.
AM>>
AM>> TC>a solution to H323 endpoint => FS => SIP user no audio issue
AM>> TC>
AM>> TC>is to disable a wait for tx Audio ... for case
AM>> TC>SWITCH_MESSAGE_INDICATE_ANSWER:{
AM>> TC>
AM>> TC>//m_txAudioOpened.Wait();
AM>> TC>
AM>> TC>
AM>> TC> case SWITCH_MESSAGE_INDICATE_ANSWER:{
AM>> TC>
AM>> TC> switch_log_printf(SWITCH_CHANNEL_LOG,
AM>> TC>SWITCH_LOG_CONSOLE, "ANSWER: we got Answer event\n");
AM>> TC>
AM>> TC> if (switch_channel_test_flag(channel,
AM>> CF_OUTBOUND))
AM>> TC>{
AM>> TC>
AM>> TC> switch_log_printf(SWITCH_CHANNEL_LOG,
AM>> TC>SWITCH_LOG_CONSOLE, "ANSWER: we got Answer event - CF_OUTBOUND
AM>> TC>\n");
AM>> TC> return SWITCH_STATUS_FALSE;
AM>> TC> }
AM>> TC> AnsweringCall(H323Connection::AnswerCallNow);
AM>> TC>
AM>> TC> switch_log_printf(SWITCH_CHANNEL_LOG,
AM>> TC>SWITCH_LOG_CONSOLE, "ANSWER: suppose the call is Answered Now\n");
AM>> TC> PTRACE(4, "mod_h323\tMedia started on connection
AM>> "
AM>> TC><< *this);
AM>> TC>
AM>> TC> // test
AM>> TC> //switch_channel_mark_answered(m_fsChannel);
AM>> TC>
AM>> TC> m_rxAudioOpened.Wait();
AM>> TC> switch_log_printf(SWITCH_CHANNEL_LOG,
AM>> TC>SWITCH_LOG_CONSOLE, "ANSWER: wait for m_rxAudioOpened\n");
AM>> TC> //m_txAudioOpened.Wait();
AM>> TC> switch_log_printf(SWITCH_CHANNEL_LOG,
AM>> TC>SWITCH_LOG_CONSOLE, "ANSWER: we disable wait for m_txAudioOpened\n");
AM>> TC>
AM>> TC> switch_log_printf(SWITCH_CHANNEL_LOG,
AM>> TC>SWITCH_LOG_CONSOLE, "ANSWER: were waiting for rx/tx AudioOpen\n");
AM>> TC>
AM>> TC> if (!switch_channel_test_flag(m_fsChannel,
AM>> TC>CF_EARLY_MEDIA)) {
AM>> TC>
AM>> TC> switch_log_printf(SWITCH_CHANNEL_LOG,
AM>> TC>SWITCH_LOG_CONSOLE, "ANSWER: we have early media\n");
AM>> TC>
AM>> TC> PTRACE(4,
AM>> TC>"mod_h323\t-------------------->switch_channel_mark_answered(m_fsChannel)
AM>> "
AM>> TC><< *this);
AM>> TC>
AM>> switch_channel_mark_answered(m_fsChannel);
AM>> TC> switch_log_printf(SWITCH_CHANNEL_LOG,
AM>> TC>SWITCH_LOG_CONSOLE, "ANSWER: answered in early Media\n");
AM>> TC> }
AM>> TC> break;
AM>> TC> }
AM>> TC>
AM>> TC>
AM>> TC>Now, I'm able to both originate and terminate cals with 2-way audio...
AM>> TC>the signaling looks correct...
AM>> TC>
AM>> TC>
AM>> TC>
AM>> TC>outgoing:
AM>> TC>
AM>> TC>1369.425046 10.4.62.7 -> 10.4.62.89 SIP/SDP Request: INVITE
AM>> TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> <sip%3A1001@10.4.62.89<sip%253A1001@10.4.62.89>>;transport=udp,
AM>> with session
AM>> TC>description
AM>> TC>1369.426255 10.4.62.7 -> 10.4.62.31 H.225.0 CS: alerting
AM>> TC>1369.435950 10.4.62.89 -> 10.4.62.7 SIP Status: 100 Trying
AM>> TC>1369.449065 10.4.62.89 -> 10.4.62.7 SIP Status: 180 Ringing
AM>> TC>1369.605109 10.4.62.7 -> 10.4.62.31 H.225.0 CS: progress
AM>> TC>OpenLogicalChannel
AM>> TC>1369.609788 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
AM>> TC>terminalCapabilitySet
AM>> TC>1369.610489 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
AM>> TC>masterSlaveDetermination
AM>> TC>1369.619071 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
AM>> TC>terminalCapabilitySet
AM>> TC>1369.620349 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
AM>> TC>terminalCapabilitySetAck
AM>> TC>1369.623215 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
AM>> TC>terminalCapabilitySetAck
AM>> TC>1369.625591 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
AM>> TC>masterSlaveDeterminationAck
AM>> TC>1369.628174 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
AM>> TC>masterSlaveDeterminationAck
AM>> TC>1370.966958 10.4.62.89 -> 10.4.62.7 SIP/SDP Status: 200 OK, with
AM>> TC>session description
AM>> TC>1370.967431 10.4.62.7 -> 10.4.62.89 SIP Request: ACK
AM>> TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> <sip%3A1001@10.4.62.89<sip%253A1001@10.4.62.89>
AM>> >;transport=udp
AM>> TC>1370.975172 10.4.62.7 -> 10.4.62.31 H.225.0 CS: connect
AM>> TC>1372.354383 10.4.62.89 -> 10.4.62.7 SIP Request: BYE
AM>> TC>sip:mod_sofia@10.4.62.7:5060
AM>> TC>1372.355147 10.4.62.7 -> 10.4.62.89 SIP Status: 200 OK
AM>> TC>1372.392904 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS:
AM>> releaseComplete
AM>> TC>endSessionCommand
AM>> TC>1372.397302 10.4.62.31 -> 10.4.62.7 H.225.0 CS: releaseComplete
AM>> TC>
AM>> TC>
AM>> TC>incoming:
AM>> TC>
AM>> TC>
AM>> TC>1502.817154 10.4.62.31 -> 10.4.62.7 H.225.0 CS: setup
AM>> TC>OpenLogicalChannel
AM>> TC>1502.833732 10.4.62.7 -> 10.4.62.31 H.225.0 CS: callProceeding
AM>> TC>1502.850909 10.4.62.7 -> 10.4.62.89 SIP/SDP Request: INVITE
AM>> TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> <sip%3A1001@10.4.62.89<sip%253A1001@10.4.62.89>>;transport=udp,
AM>> with session
AM>> TC>description
AM>> TC>1502.851758 10.4.62.7 -> 10.4.62.31 H.225.0 CS: alerting
AM>> TC>1502.861828 10.4.62.89 -> 10.4.62.7 SIP Status: 100 Trying
AM>> TC>1502.875127 10.4.62.89 -> 10.4.62.7 SIP Status: 180 Ringing
AM>> TC>1503.033258 10.4.62.7 -> 10.4.62.31 H.225.0 CS: progress
AM>> TC>OpenLogicalChannel
AM>> TC>1503.037908 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
AM>> TC>terminalCapabilitySet
AM>> TC>1503.038608 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
AM>> TC>masterSlaveDetermination
AM>> TC>1503.050154 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
AM>> TC>terminalCapabilitySet
AM>> TC>1503.051381 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
AM>> TC>terminalCapabilitySetAck
AM>> TC>1503.054297 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
AM>> TC>terminalCapabilitySetAck
AM>> TC>1503.054917 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS: empty
AM>> TC>masterSlaveDeterminationAck
AM>> TC>1503.057933 10.4.62.31 -> 10.4.62.7 H.225.0/H.245 CS: facility
AM>> TC>masterSlaveDeterminationAck
AM>> TC>1505.485493 10.4.62.89 -> 10.4.62.7 SIP/SDP Status: 200 OK, with
AM>> TC>session description
AM>> TC>1505.486018 10.4.62.7 -> 10.4.62.89 SIP Request: ACK
AM>> TC>sip:1001@10.4.62.89 <sip%3A1001@10.4.62.89> <sip%3A1001@10.4.62.89<sip%253A1001@10.4.62.89>
AM>> >;transport=udp
AM>> TC>1505.493611 10.4.62.7 -> 10.4.62.31 H.225.0 CS: connect
AM>> TC>1509.565959 10.4.62.89 -> 10.4.62.7 SIP Request: BYE
AM>> TC>sip:mod_sofia@10.4.62.7:5060
AM>> TC>1509.566722 10.4.62.7 -> 10.4.62.89 SIP Status: 200 OK
AM>> TC>1509.577435 10.4.62.7 -> 10.4.62.31 H.225.0/H.245 CS:
AM>> releaseComplete
AM>> TC>endSessionCommand
AM>> TC>1509.582066 10.4.62.31 -> 10.4.62.7 H.225.0 CS: releaseComplete
AM>> TC>
AM>> TC>
AM>> TC>
AM>> TC>... i still need to check the CDRs as well but here we are
AM>> TC>
AM>>
AM>> can you send a diff? in you call scheme call from h323 endpoint to fs is
AM>> not have RAS?,
AM>> because i don't have no audio issues in transit from h323 to sip, but my
AM>> calls a going
AM>> thorough GK and fs is regitered on them, my call scheme is
AM>> h323ep-RAS->GK-RAS->fs.
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 |
|
| Back to top |
|
|
tculjaga at gmail.com
Guest
|
| Posted: Fri Oct 23, 2009 11:37 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
2009/10/23 Georgiewskiy Yuriy <bottleman@icf.org.ru (bottleman@icf.org.ru)>
| Quote: | On 2009-10-23 10:37 -0500, Anthony Minessale wrote freeswitch-users@lists.f...:
i have no way to install trunk at this time, i will go out of hospital about one week later, after
this i will can try it on trunk.
AM>if you were on trunk that line of code would be gone.
AM>you really can't do development on 1.0.4 its 6 months old and it will cause
AM>you more trouble than you think when you eventually upgrade if you do not do
|
uh... you are still in there ... damn sorry to hear that.
I know what the feeling is... i was in the same position a couple of months ago... anyhow at least i had plenty of time to do my private research.. hope it is the case with you as well.
so, if you have that time i can offer you my development server with trunk installed and all the hands on.
let me know...
BTW: it really doesn't have sense to develop on 1.0.4 ... the proof of concept was done. I'm able to place calls in both directions so, lets move to trunk now.
T. |
|
| Back to top |
|
|
bottleman at icf.org.ru
Guest
|
| Posted: Fri Oct 23, 2009 1:31 pm Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
On 2009-10-23 18:26 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:
TC>2009/10/23 Georgiewskiy Yuriy <bottleman@icf.org.ru>
TC>
TC>> On 2009-10-23 10:37 -0500, Anthony Minessale wrote
TC>> freeswitch-users@lists.f...:
TC>>
TC>> i have no way to install trunk at this time, i will go out of hospital
TC>> about one week later, after
TC>> this i will can try it on trunk.
TC>>
TC>> AM>if you were on trunk that line of code would be gone.
TC>> AM>you really can't do development on 1.0.4 its 6 months old and it will
TC>> cause
TC>> AM>you more trouble than you think when you eventually upgrade if you do
TC>> not do
TC>>
TC>
TC>uh... you are still in there ... damn sorry to hear that.
TC>I know what the feeling is... i was in the same position a couple of months
TC>ago... anyhow at least i had plenty of time to do my private research.. hope
TC>it is the case with you as well.
TC>
TC>so, if you have that time i can offer you my development server with trunk
TC>installed and all the hands on.
TC>
TC>
TC>let me know...
TC>
TC>BTW: it really doesn't have sense to develop on 1.0.4 ... the proof of
TC>concept was done. I'm able to place calls in both directions so, lets move
TC>to trunk now.
i have my own voip infrastructure on my work, and it's better for me to use it for tests,
and use my personal on work too, i have problem with various hardware and call making,
there is i have dialup connection and all what i can - make one call whit only g729 codec,
or receive one call, no more, it's is a bandwich limitation. from hardware i have only ip
phone artdio ipf2000 and one addpac gateway. also ssh sesssion is very slow.
P.S. people from russian community report what current version of module work fine on fs
trunk version.
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 |
|
| Back to top |
|
|
tculjaga at gmail.com
Guest
|
| Posted: Sat Oct 24, 2009 3:16 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
| Quote: | TC>BTW: it really doesn't have sense to develop on 1.0.4 ... the proof of
TC>concept was done. I'm able to place calls in both directions so, lets move
TC>to trunk now.
i have my own voip infrastructure on my work, and it's better for me to use it for tests,
and use my personal on work too, i have problem with various hardware and call making,
there is i have dialup connection and all what i can - make one call whit only g729 codec,
or receive one call, no more, it's is a bandwich limitation. from hardware i have only ip
phone artdio ipf2000 and one addpac gateway. also ssh sesssion is very slow.
|
I see... it is not the ideal development environment ... Indeed, a dialup is not a good thing... i guess your g729 is compressed to the maximum
| Quote: | P.S. people from russian community report what current version of module work fine on fs
trunk version.
|
that's strange that they report it working as "m_txAudioOpened" is never gonna be ready in pre_answer ... i had to comment it to make it working.
anyhow, i moved everything to trunk and will do some tests on Monday.
T |
|
| Back to top |
|
|
tculjaga at gmail.com
Guest
|
| Posted: Mon Oct 26, 2009 5:28 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
| Quote: |
| Quote: | P.S. people from russian community report what current version of module work fine on fs
trunk version.
|
that's strange that they report it working as "m_txAudioOpened" is never gonna be ready in pre_answer ... i had to comment it to make it working.
anyhow, i moved everything to trunk and will do some tests on Monday.
T
|
Hello Yuriy, I tried the trunk (FreeSWITCH Version 1.0.trunk (15216M)) and i'm getting some nice coredumps...
FS crashes when placing outgoing calls.
coredump on outbound call: FS log and backtrace http://pastebin.freeswitch.org/10834
FS crashes on incoming calls.
coredump on inbound call: FS log and backtrace http://pastebin.freeswitch.org/10835
FS crashes when i try to load mod_h323. I need 3-4 attempts to load it without a crash.
coredump on mod_h323 load: FS log and backtrace: http://pastebin.freeswitch.org/10833
FS crashes on shutdown procedure if mod_h323 was loaded previously.
coredump on mod_h323 load: FS log and backtrace: http://pastebin.freeswitch.org/10836
It is quite bad |
|
| Back to top |
|
|
bottleman at icf.org.ru
Guest
|
| Posted: Tue Oct 27, 2009 7:27 pm Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
On 2009-10-23 15:14 +0200, Tihomir Culjaga wrote freeswitch-users@lists.fre...:
TC>
TC> so the real solution is to implement a check for CallProceeding , Progress
TC>and Facility message whether it has a faststart element included. It it is
TC>true than you might start pre_answer.
TC>
TC>
TC>also, i don't see any handling of Call Proceeding ... what if there is a
TC>fastStart element in CallProceeding message?
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. MERA where sending fast start elements
in the Call proceeding and connect. The call proceeding where not valid and
causing the media to fail. Normally (although valid) EP's do not set Fast
Start in Call proceeding so the code was disabled to resolve the MERA issue.
if you wont read "bugs" file in mod_h323, there is explaned how to enable it.
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 |
|
| Back to top |
|
|
tculjaga at gmail.com
Guest
|
| Posted: Wed Oct 28, 2009 4:31 am Post subject: [Freeswitch-users] Fwd: mod_opal - call charged before H.225 |
|
|
| Quote: |
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.
| Quote: | 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.
| Quote: | 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...
| Quote: | 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 ----------->
|
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
