hello guys, i configured FS HA and looks like its trying to recover the call .. but the re-INVITE fails due to "wrong/missed" codec capability. freeswitch@internal> freeswitch@internal> sofia profile external siptrace on Enabled sip debugging on external freeswitch@internal> sofia profile internal siptrace on Enabled sip debugging on internal freeswitch@internal> freeswitch@internal> freeswitch@internal> freeswitch@internal> sofia recover Recovered 1 call(s) 2011-01-24 21:32:31.667404 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] freeswitch@internal> 2011-01-24 21:32:31.667404 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:32.726402 [NOTICE] switch_channel.c:669 New Channel sofia/external/385914392122@195.88.212.39[808b0a98-8928-4ca2-a320-8e026ba94018] *2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2354 Set Codec sofia/external/385914392122@195.88.212.39 PCMA/8000 20 ms 160 samples* 2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2594 AUDIO RTP [sofia/external/385914392122@195.88.212.39] 195.88.212.30 port 20092 -> 195.88.212.39 port 17750 codec: 8 ms: 20 2011-01-24 21:32:32.726402 [DEBUG] switch_rtp.c:1182 Starting timer [soft] 160 bytes per 20ms 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send payload to 101 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf receive payload to 101 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2790 Set comfort noise payload to 13 2011-01-24 21:32:32.779414 [DEBUG] sofia_glue.c:4246 (sofia/external/ 385914392122@195.88.212.39) State Change CS_NEW -> CS_INIT 2011-01-24 21:32:32.779414 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122@195.88.212.39 [BREAK] 2011-01-24 21:32:32.779414 [NOTICE] sofia_glue.c:4249 Resurrecting fallen channel sofia/external/385914392122@195.88.212.39 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122@195.88.212.39) Running State Change CS_INIT 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:338 (sofia/external/385914392122@195.88.212.39) State INIT 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:83 sofia/external/ 385914392122@195.88.212.39 SOFIA INIT 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:114 (sofia/external/ 385914392122@195.88.212.39) State Change CS_INIT -> CS_EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122@195.88.212.39 [BREAK] 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:338 (sofia/external/385914392122@195.88.212.39) State INIT going to sleep 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122@195.88.212.39) Running State Change CS_EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:348 (sofia/external/385914392122@195.88.212.39) State EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:226 sofia/external/ 385914392122@195.88.212.39 SOFIA EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:157 sofia/external/385914392122@195.88.212.39 Standard EXECUTE EXECUTE sofia/external/385914392122@195.88.212.39 set(playback_delimiter=!) send 1029 bytes to udp/[195.88.212.39]:62342 at 20:32:32.781241: ------------------------------------------------------------------------ INVITE sip:385914392122@195.88.212.39 <sip%3A385914392122@195.88.212.39>SIP/2.0 Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j Route: <sip:385914392122@195.88.212.39:62342;lr> Max-Forwards: 69 From: <sip:38518880050@195.88.212.30 <sip%3A38518880050@195.88.212.30>
;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122@195.88.212.39> ;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1@195.88.212.39 CSeq: 7614512 INVITE Contact: <sip:385914392122@195.88.212.30:5080> User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 168 X-FS-Support: update_display Remote-Party-ID: "38518880050" <sip:38518880050@195.88.212.30<sip%3A38518880050@195.88.212.30> ;party=calling;screen=yes;privacy=off
v=0 o=FreeSWITCH 1295881060 1295881062 IN IP4 195.88.212.30 s=FreeSWITCH c=IN IP4 195.88.212.30 t=0 0* m=audio 20092 RTP/AVP 0 13* * a=rtpmap:13 CN/8000* a=ptime:20 ------------------------------------------------------------------------ 2011-01-24 21:32:32.781430 [DEBUG] sofia.c:4153 Channel sofia/external/ 385914392122@195.88.212.39 entering state [calling][0] recv 496 bytes from udp/[195.88.212.39]:5060 at 20:32:32.784077: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j From: <sip:38518880050@195.88.212.30 <sip%3A38518880050@195.88.212.30>
;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122@195.88.212.39> ;tag=C4B0BE6C-1B8 Date: Mon, 24 Jan 2011 19:22:34 GMT Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1@195.88.212.39 Server: Cisco-SIPGateway/IOS-12.x CSeq: 7614512 INVITE Allow-Events: telephone-event Remote-Party-ID: <sip:385914392122@195.88.212.39<sip%3A385914392122@195.88.212.39> ;party=called;screen=yes;privacy=off Content-Length: 0
------------------------------------------------------------------------ recv 376 bytes from udp/[195.88.212.39]:5060 at 20:32:32.784195: ------------------------------------------------------------------------ SIP/2.0 488 Not Acceptable Media Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j From: <sip:38518880050@195.88.212.30 <sip%3A38518880050@195.88.212.30>
;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122@195.88.212.39> ;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1@195.88.212.39 Warning: 304 195.88.212.39 "Media Type(s) Unavailable" CSeq: 7614512 INVITE Content-Length: 0
------------------------------------------------------------------------ send 395 bytes to udp/[195.88.212.39]:62342 at 20:32:32.784303: ------------------------------------------------------------------------ ACK sip:385914392122@195.88.212.39 <sip%3A385914392122@195.88.212.39>SIP/2.0 Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j Route: <sip:385914392122@195.88.212.39:62342;lr> Max-Forwards: 69 From: <sip:38518880050@195.88.212.30 <sip%3A38518880050@195.88.212.30>
;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122@195.88.212.39> ;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1@195.88.212.39 CSeq: 7614512 ACK Content-Length: 0
------------------------------------------------------------------------ 2011-01-24 21:32:32.784397 [DEBUG] sofia.c:4153 Channel sofia/external/ 385914392122@195.88.212.39 entering state [terminated][488] 2011-01-24 21:32:32.784397 [NOTICE] sofia.c:4789 Hangup sofia/external/ 385914392122@195.88.212.39 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] 2011-01-24 21:32:32.784397 [DEBUG] switch_channel.c:2102 Send signal sofia/external/385914392122@195.88.212.39 [KILL] 2011-01-24 21:32:32.784397 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122@195.88.212.39 [BREAK] 2011-01-24 21:32:32.852411 [DEBUG] mod_dptools.c:816 sofia/external/ 385914392122@195.88.212.39 SET [playback_delimiter]=[!] 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:348 (sofia/external/385914392122@195.88.212.39) State EXECUTE going to sleep 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122@195.88.212.39) Running State Change CS_HANGUP 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:499 (sofia/external/385914392122@195.88.212.39) State HANGUP 2011-01-24 21:32:32.861414 [DEBUG] mod_sofia.c:408 sofia/external/ 385914392122@195.88.212.39 Overriding SIP cause 488 with 488 from the other leg 2011-01-24 21:32:32.861414 [DEBUG] mod_sofia.c:414 Channel sofia/external/ 385914392122@195.88.212.39 hanging up, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:46 sofia/external/385914392122@195.88.212.39 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:499 (sofia/external/385914392122@195.88.212.39) State HANGUP going to sleep 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:333 (sofia/external/385914392122@195.88.212.39) State Change CS_HANGUP -> CS_REPORTING 2011-01-24 21:32:32.863454 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122@195.88.212.39 [BREAK] 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122@195.88.212.39) Running State Change CS_REPORTING 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:590 (sofia/external/385914392122@195.88.212.39) State REPORTING 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:53 sofia/external/385914392122@195.88.212.39 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:590 (sofia/external/385914392122@195.88.212.39) State REPORTING going to sleep 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:327 (sofia/external/385914392122@195.88.212.39) State Change CS_REPORTING -> CS_DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122@195.88.212.39 [BREAK] 2011-01-24 21:32:32.864328 [DEBUG] switch_core_session.c:1164 Session 1 (sofia/external/385914392122@195.88.212.39) Locked, Waiting on external entities 2011-01-24 21:32:32.864328 [NOTICE] switch_core_session.c:1182 Session 1 (sofia/external/385914392122@195.88.212.39) Ended 2011-01-24 21:32:32.864328 [NOTICE] switch_core_session.c:1184 Close Channel sofia/external/385914392122@195.88.212.39 [CS_DESTROY] 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:428 (sofia/external/385914392122@195.88.212.39) Running State Change CS_DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:439 (sofia/external/385914392122@195.88.212.39) State DESTROY 2011-01-24 21:32:32.864328 [DEBUG] mod_sofia.c:341 sofia/external/ 385914392122@195.88.212.39 SOFIA DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:60 sofia/external/385914392122@195.88.212.39 Standard DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:439 (sofia/external/385914392122@195.88.212.39) State DESTROY going to sleep freeswitch@internal> freeswitch@internal> freeswitch@internal> 2011-01-24 21:32:51.813359 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:51.813359 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:52.810408 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:52.810408 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:53.817405 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:53.817405 [INFO] switch_odbc.c:210 The connection has been re-established recv 432 bytes from udp/[195.88.212.39]:62342 at 20:33:06.045642: ------------------------------------------------------------------------ BYE sip:385914392122@195.88.212.30:5080 SIP/2.0 Via: SIP/2.0/UDP 195.88.212.39:5060;branch=z9hG4bK240FA From: <sip:385914392122@195.88.212.39 <sip%3A385914392122@195.88.212.39>
;tag=C4B0BE6C-1B8 To: <sip:38518880050@195.88.212.30 <sip%3A38518880050@195.88.212.30> ;tag=DFejDg1B59y9r Date: Mon, 24 Jan 2011 19:22:34 GMT Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1@195.88.212.39 User-Agent: Cisco-SIPGateway/IOS-12.x Max-Forwards: 70 Timestamp: 1295896987 CSeq: 102 BYE Content-Length: 0
------------------------------------------------------------------------ send 522 bytes to udp/[195.88.212.39]:5060 at 20:33:06.045858: ------------------------------------------------------------------------ SIP/2.0 481 Call Does Not Exist Via: SIP/2.0/UDP 195.88.212.39:5060;branch=z9hG4bK240FA From: <sip:385914392122@195.88.212.39 <sip%3A385914392122@195.88.212.39>
;tag=C4B0BE6C-1B8 To: <sip:38518880050@195.88.212.30 <sip%3A38518880050@195.88.212.30> ;tag=DFejDg1B59y9r Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1@195.88.212.39 CSeq: 102 BYE Timestamp: 1295896987 0.000191 User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Length: 0
------------------------------------------------------------------------ freeswitch@internal> freeswitch@internal> my codec settings in vars.conf <X-PRE-PROCESS cmd="set" data="global_codec_prefs=PCMA,GSM"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMA,GSM"/> my codec settings in sip_profiles/* <param name="inbound-codec-prefs" value="$${global_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${global_codec_prefs}"/> now, where the is FS picking up the codec list for the re-INVITE after "sofia recover" from the debug: 2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2354 Set Codec sofia/external/385914392122@195.88.212.39 PCMA/8000 20 ms 160 samples i can see sofia knows what codec is being used, but somehow its not sending it in re-INVITE. BTW: yea, i know, i know .. the version is a bit outdated but we can still make it working .. :)
What makes you think that fails? It has ULAW and CN in the codec list! Sounds like you need the verbose sdp... set the global variable "verbose_sdp=true" /b On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote:
i configured FS HA and looks like its trying to recover the call .. but the re-INVITE fails due to "wrong/missed" codec capability.
Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA? Steve on iPhone On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote:
What makes you think that fails? It has ULAW and CN in the codec list! Sounds like you need the verbose sdp... set the global variable "verbose_sdp=true"
/b
On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote:
i configured FS HA and looks like its trying to recover the call .. but the re-INVITE fails due to "wrong/missed" codec capability.
_______________________________________________ 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
yap, i do have PCMA ... and the debug shows it correctly :=) i will try to see what it does with verbose. Post new debug tomorrow. ty. On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com> wrote:
Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA?
Steve on iPhone
On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote:
What makes you think that fails? It has ULAW and CN in the codec list! Sounds like you need the verbose sdp... set the global variable "verbose_sdp=true"
/b
On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote:
i configured FS HA and looks like its trying to recover the call .. but
the re-INVITE fails due to "wrong/missed" codec capability.
_______________________________________________ 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
_______________________________________________ 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
Here is the debug: http://pastebin.freeswitch.org/15133 i have set verbose_sdp=true in vars.xml as. <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/> but not much to be seen of the verbose thing in the debug... Still, FS is sending a re-INVITE with wrong SDP. The call to be recovered is using ALAW... and ULAW is not supported. FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected due to incompatible SDP. Where does FS get the information for the SDP in re-INVITE message? please advice, T. On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga <tculjaga@gmail.com>wrote:
yap, i do have PCMA ... and the debug shows it correctly :=)
i will try to see what it does with verbose. Post new debug tomorrow.
ty.
On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com> wrote:
Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA?
Steve on iPhone
On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote:
What makes you think that fails? It has ULAW and CN in the codec list! Sounds like you need the verbose sdp... set the global variable "verbose_sdp=true"
/b
On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote:
i configured FS HA and looks like its trying to recover the call .. but
the re-INVITE fails due to "wrong/missed" codec capability.
_______________________________________________ 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
_______________________________________________ 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
Are you using two machines for the HA? do both have the same configs? -Avi On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Here is the debug: http://pastebin.freeswitch.org/15133
i have set verbose_sdp=true in vars.xml as. <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/>
but not much to be seen of the verbose thing in the debug...
Still, FS is sending a re-INVITE with wrong SDP. The call to be recovered is using ALAW... and ULAW is not supported. FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected due to incompatible SDP.
Where does FS get the information for the SDP in re-INVITE message?
please advice, T.
On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, i do have PCMA ... and the debug shows it correctly :=)
i will try to see what it does with verbose. Post new debug tomorrow.
ty.
On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com> wrote:
Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA?
Steve on iPhone
On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote:
What makes you think that fails? It has ULAW and CN in the codec list! Sounds like you need the verbose sdp... set the global variable "verbose_sdp=true"
/b
On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote:
i configured FS HA and looks like its trying to recover the call .. but the re-INVITE fails due to "wrong/missed" codec capability.
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
yap, both using the same config can you advice where is FS getting the SDP info for the re-INVITE ? On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote:
Are you using two machines for the HA? do both have the same configs? -Avi
On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Here is the debug: http://pastebin.freeswitch.org/15133
i have set verbose_sdp=true in vars.xml as. <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/>
but not much to be seen of the verbose thing in the debug...
Still, FS is sending a re-INVITE with wrong SDP. The call to be recovered is using ALAW... and ULAW is not supported. FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected due to incompatible SDP.
Where does FS get the information for the SDP in re-INVITE message?
please advice, T.
On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, i do have PCMA ... and the debug shows it correctly :=)
i will try to see what it does with verbose. Post new debug tomorrow.
ty.
On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com>
wrote:
Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA?
Steve on iPhone
On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote:
What makes you think that fails? It has ULAW and CN in the codec
list!
Sounds like you need the verbose sdp... set the global variable "verbose_sdp=true"
/b
On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote:
i configured FS HA and looks like its trying to recover the call .. but the re-INVITE fails due to "wrong/missed" codec capability.
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
There is an xml_cdr snapshot in sip_recovery sql table that contains the data used for the recovery. Also based on your logs, you are not using latest git. I would try that first before anything else. On Tue, Jan 25, 2011 at 7:24 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, both using the same config
can you advice where is FS getting the SDP info for the re-INVITE ?
On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote:
Are you using two machines for the HA? do both have the same configs? -Avi
On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Here is the debug: http://pastebin.freeswitch.org/15133
i have set verbose_sdp=true in vars.xml as. <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/>
but not much to be seen of the verbose thing in the debug...
Still, FS is sending a re-INVITE with wrong SDP. The call to be recovered is using ALAW... and ULAW is not supported. FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected due to incompatible SDP.
Where does FS get the information for the SDP in re-INVITE message?
please advice, T.
On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, i do have PCMA ... and the debug shows it correctly :=)
i will try to see what it does with verbose. Post new debug tomorrow.
ty.
On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com> wrote:
Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA?
Steve on iPhone
On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote:
What makes you think that fails? It has ULAW and CN in the codec list! Sounds like you need the verbose sdp... set the global variable "verbose_sdp=true"
/b
On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote:
> > > i configured FS HA and looks like its trying to recover the call .. > but the re-INVITE fails due to "wrong/missed" codec capability.
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- 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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
hello Anthony, ya, i was afraid of that... this means moving all my modules & patches to the latest git... radius cdr interface odbc cdr interface within mod_xml_cdr <= i can share this as a patch... if you are interested. mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios and some small stuff i made within mod_commands... anyhow this was on the road. anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database) so what really happens is the FS on 2nd node just getting sessions from sip_recovery from sofia_glue_recover: i see you are selecting sip_recovery table. select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d so, what do you do afterward? on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ? thanks for your help, Tihomir. On Wed, Jan 26, 2011 at 1:12 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
There is an xml_cdr snapshot in sip_recovery sql table that contains the data used for the recovery. Also based on your logs, you are not using latest git. I would try that first before anything else.
On Tue, Jan 25, 2011 at 7:24 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, both using the same config
can you advice where is FS getting the SDP info for the re-INVITE ?
On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote:
Are you using two machines for the HA? do both have the same configs? -Avi
On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Here is the debug: http://pastebin.freeswitch.org/15133
i have set verbose_sdp=true in vars.xml as. <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/>
but not much to be seen of the verbose thing in the debug...
Still, FS is sending a re-INVITE with wrong SDP. The call to be recovered is using ALAW... and ULAW is not supported. FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is
rejected
due to incompatible SDP.
Where does FS get the information for the SDP in re-INVITE message?
please advice, T.
On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga <tculjaga@gmail.com
wrote:
yap, i do have PCMA ... and the debug shows it correctly :=)
i will try to see what it does with verbose. Post new debug tomorrow.
ty.
On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com> wrote:
Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA?
Steve on iPhone
On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote:
> What makes you think that fails? It has ULAW and CN in the codec > list! > Sounds like you need the verbose sdp... set the global variable > "verbose_sdp=true" > > /b > > On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote: > >> >> >> i configured FS HA and looks like its trying to recover the call
..
>> but the re-INVITE fails due to "wrong/missed" codec capability. > > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
The sip recovery table should have a LOT more data than that, all stuffed into a single column. Do you have track calls on in all the involved profiles? I suppose it really wouldn't be here otherwise. e.g. my sip_recovery table has this in the metadata field for a "simple" MOH call. Does yours? <cdr> <channel_data> <state>CS_EXECUTE</state> <direction>inbound</direction> <state_number>4</state_number> <flags>0=1;1=1;3=1;35=1;41=1;51=1</flags> <caps>1=1;2=1;3=1;4=1;5=1</caps> </channel_data> <variables> <direction>inbound</direction> <uuid>6cda8922-2943-11e0-b622-639ef8e43974</uuid> <sip_local_network_addr>178.79.147.47</sip_local_network_addr> <sip_network_ip>79.176.185.32</sip_network_ip> <sip_network_port>5072</sip_network_port> <sip_received_ip>79.176.yyy.32</sip_received_ip> <sip_received_port>5072</sip_received_port> <sip_via_protocol>udp</sip_via_protocol> <sip_authorized>true</sip_authorized> <sip_number_alias>1000</sip_number_alias> <sip_auth_username>1000</sip_auth_username> <sip_auth_realm>sip-ha.yyy.com</sip_auth_realm> <number_alias>1000</number_alias> <user_name>1000</user_name> <domain_name>sip.yyy.com</domain_name> <record_stereo>true</record_stereo> <default_areacode>208</default_areacode> <transfer_fallback_extension>operator</transfer_fallback_extension> <accountcode>1000</accountcode> <user_context>default</user_context> <effective_caller_id_name>Avi%20Marcus</effective_caller_id_name> <effective_caller_id_number>12013554419</effective_caller_id_number> <outbound_caller_id_name>Avi%20Marcus</outbound_caller_id_name> <outbound_caller_id_number>12013554419</outbound_caller_id_number> <nibble_account>1000</nibble_account> <sip_from_user>1000</sip_from_user> <sip_from_uri>1000%40sip-ha.yyy.com</sip_from_uri> <sip_from_host>sip-ha.yyy.com</sip_from_host> <sip_from_user_stripped>1000</sip_from_user_stripped> <sofia_profile_name>internal</sofia_profile_name> <sip_Remote-Party-ID>%3Csip%3A1000%40sip-ha.yyy.com %3E%3Bscreen%3Dyes%3Bparty%3Dcalling</sip_Remote-Party-ID> <sip_cid_type>rpid</sip_cid_type> <sip_full_via>SIP/2.0/UDP%20192.168.1.5%3A5072%3Bbranch%3Dz9hG4bK-329da816%3Brport%3D5072%3Breceived%3D79.176.185.32</sip_full_via> <sip_req_user>*9664</sip_req_user> <sip_req_uri>*9664%40sip-ha.yyy.com</sip_req_uri> <sip_req_host>sip-ha.yyy.com</sip_req_host> <sip_to_user>*9664</sip_to_user> <sip_to_uri>*9664%40sip-ha.yyy.com</sip_to_uri> <sip_to_host>sip-ha.yyy.com</sip_to_host> <sip_contact_user>1000</sip_contact_user> <sip_contact_port>5072</sip_contact_port> <sip_contact_uri>1000%4079.176.yyy.32%3A5072</sip_contact_uri> <sip_contact_host>79.176.yyy.32</sip_contact_host> <channel_name>sofia/internal/1000%40sip-ha.yyy.com</channel_name> <sip_user_agent>Linksys/SPA2102-5.2.10</sip_user_agent> <sip_via_host>192.168.1.5</sip_via_host> <sip_via_port>5072</sip_via_port> <sip_via_rport>5072</sip_via_rport> <max_forwards>70</max_forwards> <presence_id>1000%40sip-ha.yyy.com</presence_id> <switch_r_sdp>v%3D0%0D%0Ao%3D-%2033038436%2033038436%20IN%20IP4%2079.176.185.32%0D%0As%3D-%0D%0Ac%3DIN%20IP4%2079.176.185.32%0D%0At%3D0%200%0D%0Am%3Daudio%2016422%20RTP/AVP%2018%200%202%204%208%2096%2097%2098%20100%20101%0D%0Aa%3Drtpmap%3A18%20G729/8000%0D%0Aa%3Drtpmap%3A0%20PCMU/8000%0D%0Aa%3Drtpmap%3A2%20G726-32/8000%0D%0Aa%3Drtpmap%3A4%20G723/8000%0D%0Aa%3Drtpmap%3A8%20PCMA/8000%0D%0Aa%3Drtpmap%3A96%20G726-40/8000%0D%0Aa%3Drtpmap%3A97%20G726-24/8000%0D%0Aa%3Drtpmap%3A98%20G726-16/8000%0D%0Aa%3Drtpmap%3A100%20NSE/8000%0D%0Aa%3Dfmtp%3A100%20192-193%0D%0Aa%3Drtpmap%3A101%20telephone-event/8000%0D%0Aa%3Dfmtp%3A101%200-15%0D%0Aa%3Dptime%3A20%0D%0A</switch_r_sdp> <ep_codec_string>PCMU%408000h%4020i%4064000b,PCMA%408000h%4020i%4064000b</ep_codec_string> <nibble_current_balance>0.000000</nibble_current_balance> <RFC2822_DATE>Wed,%2026%20Jan%202011%2013%3A57%3A18%20%2B0200</RFC2822_DATE> <zrtp_secure_media>true</zrtp_secure_media> <sip_use_codec_name>PCMU</sip_use_codec_name> <sip_use_codec_rate>8000</sip_use_codec_rate> <sip_use_codec_ptime>20</sip_use_codec_ptime> <read_codec>PCMU</read_codec> <read_rate>8000</read_rate> <write_codec>PCMU</write_codec> <write_rate>8000</write_rate> <local_media_ip>178.79.yyy.47</local_media_ip> <local_media_port>19600</local_media_port> <sip_use_pt>0</sip_use_pt> <rtp_use_ssrc>922702377</rtp_use_ssrc> <remote_media_ip>79.176.185.32</remote_media_ip> <remote_media_port>16422</remote_media_port> <sip_local_sdp_str>v%3D0%0Ao%3DFreeSWITCH%201296023438%201296023439%20IN%20IP4%20178.79.147.47%0As%3DFreeSWITCH%0Ac%3DIN%20IP4%20178.79.147.47%0At%3D0%200%0Am%3Daudio%2019600%20RTP/AVP%200%20101%0Aa%3Drtpmap%3A0%20PCMU/8000%0Aa%3Drtpmap%3A101%20telephone-event/8000%0Aa%3Dfmtp%3A101%200-16%0Aa%3DsilenceSupp%3Aoff%20-%20-%20-%20-%0Aa%3Dptime%3A20%0Aa%3Dsendrecv%0A</sip_local_sdp_str> <endpoint_disposition>ANSWER</endpoint_disposition> <sip_to_tag>vgcH82ctg6QaD</sip_to_tag> <sip_from_tag>9241a2573e4f702o0</sip_from_tag> <sip_cseq>102</sip_cseq> <sip_call_id>17217721-3d90de36%40192.168.1.5</sip_call_id> <sip_full_from>%3Csip%3A1000%40sip-ha.yyy.com %3E%3Btag%3D9241a2573e4f702o0</sip_full_from> <sip_full_to>%3Csip%3A*9664%40sip-ha.yyy.com %3E%3Btag%3DvgcH82ctg6QaD</sip_full_to> <playback_seconds>2</playback_seconds> <playback_ms>2000</playback_ms> <playback_samples>16000</playback_samples> <current_application_data>local_stream%3A//moh</current_application_data> <current_application>playback</current_application> </variables> <app_log> <application app_name="hash" app_data="insert/sip.yyy.com-spymap/1000/6cda8922-2943-11e0-b622-639ef8e43974"></application> <application app_name="hash" app_data="insert/sip.yyy.com-last_dial/1000/*9664"></application> <application app_name="hash" app_data="insert/sip.yyy.com-last_dial/global/6cda8922-2943-11e0-b622-639ef8e43974"></application> <application app_name="set" app_data="RFC2822_DATE=Wed, 26 Jan 2011 13:57:18 +0200"></application> <application app_name="set" app_data="zrtp_secure_media=true"></application> <application app_name="answer" app_data=""></application> <application app_name="playback" app_data="silence_stream://2000"></application> <application app_name="execute_extension" app_data="is_zrtp_secure XML features"></application> <application app_name="eval" app_data="not_secure"></application> <application app_name="playback" app_data="local_stream://moh"></application> </app_log> <callflow dialplan="XML" profile_index="1"> <extension name="global" number="*9664"> <application app_name="hash" app_data="insert/${domain_name}-spymap/${caller_id_number}/${uuid}"></application> <application app_name="hash" app_data="insert/${domain_name}-last_dial/${caller_id_number}/${destination_number}"></application> <application app_name="hash" app_data="insert/${domain_name}-last_dial/global/${uuid}"></application> <application app_name="set" app_data="RFC2822_DATE=${strftime(%a, %d %b %Y %T %z)}"></application> <application app_name="set" app_data="zrtp_secure_media=true"></application> <application app_name="answer" app_data=""></application> <application app_name="playback" app_data="silence_stream://2000"></application> <application app_name="execute_extension" app_data="is_zrtp_secure XML features"></application> <application app_name="playback" app_data="local_stream://moh"></application> <sub_extensions> <extension name="is_zrtp_secure" number="is_zrtp_secure" dialplan="XML"> <application app_name="eval" app_data="not_secure"></application> </extension> </sub_extensions> </extension> <caller_profile> <username>1000</username> <dialplan>XML</dialplan> <caller_id_name>1000</caller_id_name> <ani>1000</ani> <aniii></aniii> <caller_id_number>1000</caller_id_number> <network_addr>79.176.yyy.32</network_addr> <rdnis></rdnis> <destination_number>*9664</destination_number> <uuid>6cda8922-2943-11e0-b622-639ef8e43974</uuid> <source>mod_sofia</source> <context>default</context> <chan_name>sofia/internal/1000@sip-ha.yyy.com</chan_name> </caller_profile> <times> <created_time>1296043038692089</created_time> <profile_created_time>1296043038692089</profile_created_time> <progress_time>0</progress_time> <progress_media_time>1296043038708572</progress_media_time> <answered_time>1296043038708572</answered_time> <hangup_time>0</hangup_time> <resurrect_time>0</resurrect_time> <transfer_time>0</transfer_time> </times> </callflow> </cdr> On Wed, Jan 26, 2011 at 12:53 PM, Tihomir Culjaga <tculjaga@gmail.com>wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
dam, your metadata is awesome ... now i see the difference. i do have track calls enabled on both profiles (internal & external) and i have odbc configured as well. but my version is: freeswitch@cxss01> version FreeSWITCH Version 1.0.6 (svn-exported) freeswitch@cxss01> how can i make sure it is because of the version ? freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> sofia profile external start 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 debug [0] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-trace [no] *2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 track-calls [true]* 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rfc2833-pt [101] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-port [5080] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dialplan [XML] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 context [public] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dtmf-duration [70] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:3279 Duration out of bounds, using default of 2000! 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dtmf-type [inband] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 inbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 outbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 hold-music [local_stream://moh] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-timer-name [soft] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 local-network-acl [localnet.auto] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 manage-presence [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 inbound-codec-negotiation [generous] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 nonce-ttl [60] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 auth-calls [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-ip [195.88.212.30] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-ip [195.88.212.30] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 ext-rtp-ip [auto-nat] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 ext-sip-ip [auto-nat] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-timeout-sec [300] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-hold-timeout-sec [1800] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-bind-params [transport=tls] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-sip-port [5081] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-cert-dir [/usr/local/freeswitch/conf/ssl] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-version [tlsv1] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 odbc-dsn [COREFSdrv:adminfs:4F0s8wj] 2011-01-26 13:14:11.423588 [NOTICE] sofia_reg.c:2451 Added gateway ' example.com' to profile 'external' 2011-01-26 13:14:11.423588 [NOTICE] sofia.c:3535 Connecting ODBC Profile external [sofia_reg_external] 2011-01-26 13:14:11.424818 [DEBUG] sofia.c:1317 Creating agent for external 2011-01-26 13:14:11.438512 [INFO] sofia_glue.c:4569 Connected ODBC DSN: COREFSdrv 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1353 Created agent for external 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1389 Set params for external 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1412 Activated db for external 2011-01-26 13:14:11.460603 [DEBUG] sofia.c:1439 Starting thread for external external started successfully freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> sofia profile internal start 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 debug [0] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-trace [no] *2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 track-calls [true]* 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 log-auth-failures [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 context [public] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rfc2833-pt [101] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-port [5060] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dialplan [XML] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dtmf-duration [70] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:3279 Duration out of bounds, using default of 2000! 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 outbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-timer-name [soft] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-ip [195.88.212.30] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-ip [195.88.212.30] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 hold-music [local_stream://moh] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 apply-nat-acl [nat.auto] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 apply-inbound-acl [domains] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 local-network-acl [localnet.auto] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dtmf-type [inband] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 record-path [/usr/local/freeswitch/recordings] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 record-template [${caller_id_number}.${target_domain}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 manage-presence [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-codec-negotiation [generous] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls [false] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-bind-params [transport=tls] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-sip-port [5061] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-cert-dir [/usr/local/freeswitch/conf/ssl] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-version [tlsv1] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 odbc-dsn [COREFSdrv:adminfs:4F0s8wj] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-late-negotiation [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 nonce-ttl [60] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 auth-calls [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-reg-force-matching-username [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 auth-all-packets [false] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 ext-rtp-ip [auto-nat] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 ext-sip-ip [auto-nat] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-timeout-sec [300] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-hold-timeout-sec [1800] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-register-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-subscription-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-register-db-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 challenge-realm [auto_from] 2011-01-26 13:14:16.440442 [NOTICE] sofia_reg.c:2451 Added gateway 'hr-sbc01' to profile 'internal' 2011-01-26 13:14:16.441444 [NOTICE] sofia_reg.c:2451 Added gateway 'hr-sbc02' to profile 'internal' 2011-01-26 13:14:16.441444 [NOTICE] sofia.c:2040 Adding Alias [195.88.212.31] for profile [internal] 2011-01-26 13:14:16.441444 [NOTICE] sofia.c:3535 Connecting ODBC Profile internal [sofia_reg_internal] 2011-01-26 13:14:16.441444 [DEBUG] sofia.c:1317 Creating agent for internal 2011-01-26 13:14:16.455326 [INFO] sofia_glue.c:4569 Connected ODBC DSN: COREFSdrv 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1353 Created agent for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1389 Set params for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1412 Activated db for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1439 Starting thread for internal internal started successfully i do have track-calls enabled on the sip profiles. and yes, FS is quite outdated: freeswitch@cxss01> version FreeSWITCH Version 1.0.6 (svn-exported) freeswitch@cxss01> On Wed, Jan 26, 2011 at 1:00 PM, Avi Marcus <avi@avimarcus.net> wrote:
The sip recovery table should have a LOT more data than that, all stuffed into a single column. Do you have track calls on in all the involved profiles? I suppose it really wouldn't be here otherwise.
e.g. my sip_recovery table has this in the metadata field for a "simple" MOH call. Does yours?
<cdr> <channel_data> <state>CS_EXECUTE</state> <direction>inbound</direction> <state_number>4</state_number> <flags>0=1;1=1;3=1;35=1;41=1;51=1</flags> <caps>1=1;2=1;3=1;4=1;5=1</caps> </channel_data> <variables> <direction>inbound</direction> <uuid>6cda8922-2943-11e0-b622-639ef8e43974</uuid> <sip_local_network_addr>178.79.147.47</sip_local_network_addr> <sip_network_ip>79.176.185.32</sip_network_ip> <sip_network_port>5072</sip_network_port> <sip_received_ip>79.176.yyy.32</sip_received_ip> <sip_received_port>5072</sip_received_port> <sip_via_protocol>udp</sip_via_protocol> <sip_authorized>true</sip_authorized> <sip_number_alias>1000</sip_number_alias> <sip_auth_username>1000</sip_auth_username> <sip_auth_realm>sip-ha.yyy.com</sip_auth_realm> <number_alias>1000</number_alias> <user_name>1000</user_name> <domain_name>sip.yyy.com</domain_name> <record_stereo>true</record_stereo> <default_areacode>208</default_areacode> <transfer_fallback_extension>operator</transfer_fallback_extension> <accountcode>1000</accountcode> <user_context>default</user_context> <effective_caller_id_name>Avi%20Marcus</effective_caller_id_name> <effective_caller_id_number>12013554419</effective_caller_id_number> <outbound_caller_id_name>Avi%20Marcus</outbound_caller_id_name> <outbound_caller_id_number>12013554419</outbound_caller_id_number> <nibble_account>1000</nibble_account> <sip_from_user>1000</sip_from_user> <sip_from_uri>1000%40sip-ha.yyy.com</sip_from_uri> <sip_from_host>sip-ha.yyy.com</sip_from_host> <sip_from_user_stripped>1000</sip_from_user_stripped> <sofia_profile_name>internal</sofia_profile_name> <sip_Remote-Party-ID>%3Csip%3A1000%40sip-ha.yyy.com %3E%3Bscreen%3Dyes%3Bparty%3Dcalling</sip_Remote-Party-ID> <sip_cid_type>rpid</sip_cid_type>
<sip_full_via>SIP/2.0/UDP%20192.168.1.5%3A5072%3Bbranch%3Dz9hG4bK-329da816%3Brport%3D5072%3Breceived%3D79.176.185.32</sip_full_via> <sip_req_user>*9664</sip_req_user> <sip_req_uri>*9664%40sip-ha.yyy.com</sip_req_uri> <sip_req_host>sip-ha.yyy.com</sip_req_host> <sip_to_user>*9664</sip_to_user> <sip_to_uri>*9664%40sip-ha.yyy.com</sip_to_uri> <sip_to_host>sip-ha.yyy.com</sip_to_host> <sip_contact_user>1000</sip_contact_user> <sip_contact_port>5072</sip_contact_port> <sip_contact_uri>1000%4079.176.yyy.32%3A5072</sip_contact_uri> <sip_contact_host>79.176.yyy.32</sip_contact_host> <channel_name>sofia/internal/1000%40sip-ha.yyy.com</channel_name> <sip_user_agent>Linksys/SPA2102-5.2.10</sip_user_agent> <sip_via_host>192.168.1.5</sip_via_host> <sip_via_port>5072</sip_via_port> <sip_via_rport>5072</sip_via_rport> <max_forwards>70</max_forwards> <presence_id>1000%40sip-ha.yyy.com</presence_id>
<switch_r_sdp>v%3D0%0D%0Ao%3D-%2033038436%2033038436%20IN%20IP4%2079.176.185.32%0D%0As%3D-%0D%0Ac%3DIN%20IP4%2079.176.185.32%0D%0At%3D0%200%0D%0Am%3Daudio%2016422%20RTP/AVP%2018%200%202%204%208%2096%2097%2098%20100%20101%0D%0Aa%3Drtpmap%3A18%20G729/8000%0D%0Aa%3Drtpmap%3A0%20PCMU/8000%0D%0Aa%3Drtpmap%3A2%20G726-32/8000%0D%0Aa%3Drtpmap%3A4%20G723/8000%0D%0Aa%3Drtpmap%3A8%20PCMA/8000%0D%0Aa%3Drtpmap%3A96%20G726-40/8000%0D%0Aa%3Drtpmap%3A97%20G726-24/8000%0D%0Aa%3Drtpmap%3A98%20G726-16/8000%0D%0Aa%3Drtpmap%3A100%20NSE/8000%0D%0Aa%3Dfmtp%3A100%20192-193%0D%0Aa%3Drtpmap%3A101%20telephone-event/8000%0D%0Aa%3Dfmtp%3A101%200-15%0D%0Aa%3Dptime%3A20%0D%0A</switch_r_sdp>
<ep_codec_string>PCMU%408000h%4020i%4064000b,PCMA%408000h%4020i%4064000b</ep_codec_string> <nibble_current_balance>0.000000</nibble_current_balance>
<RFC2822_DATE>Wed,%2026%20Jan%202011%2013%3A57%3A18%20%2B0200</RFC2822_DATE> <zrtp_secure_media>true</zrtp_secure_media> <sip_use_codec_name>PCMU</sip_use_codec_name> <sip_use_codec_rate>8000</sip_use_codec_rate> <sip_use_codec_ptime>20</sip_use_codec_ptime> <read_codec>PCMU</read_codec> <read_rate>8000</read_rate> <write_codec>PCMU</write_codec> <write_rate>8000</write_rate> <local_media_ip>178.79.yyy.47</local_media_ip> <local_media_port>19600</local_media_port> <sip_use_pt>0</sip_use_pt> <rtp_use_ssrc>922702377</rtp_use_ssrc> <remote_media_ip>79.176.185.32</remote_media_ip> <remote_media_port>16422</remote_media_port>
<sip_local_sdp_str>v%3D0%0Ao%3DFreeSWITCH%201296023438%201296023439%20IN%20IP4%20178.79.147.47%0As%3DFreeSWITCH%0Ac%3DIN%20IP4%20178.79.147.47%0At%3D0%200%0Am%3Daudio%2019600%20RTP/AVP%200%20101%0Aa%3Drtpmap%3A0%20PCMU/8000%0Aa%3Drtpmap%3A101%20telephone-event/8000%0Aa%3Dfmtp%3A101%200-16%0Aa%3DsilenceSupp%3Aoff%20-%20-%20-%20-%0Aa%3Dptime%3A20%0Aa%3Dsendrecv%0A</sip_local_sdp_str> <endpoint_disposition>ANSWER</endpoint_disposition> <sip_to_tag>vgcH82ctg6QaD</sip_to_tag> <sip_from_tag>9241a2573e4f702o0</sip_from_tag> <sip_cseq>102</sip_cseq> <sip_call_id>17217721-3d90de36%40192.168.1.5</sip_call_id> <sip_full_from>%3Csip%3A1000%40sip-ha.yyy.com %3E%3Btag%3D9241a2573e4f702o0</sip_full_from> <sip_full_to>%3Csip%3A*9664%40sip-ha.yyy.com %3E%3Btag%3DvgcH82ctg6QaD</sip_full_to> <playback_seconds>2</playback_seconds> <playback_ms>2000</playback_ms> <playback_samples>16000</playback_samples>
<current_application_data>local_stream%3A//moh</current_application_data> <current_application>playback</current_application> </variables> <app_log> <application app_name="hash" app_data="insert/sip.yyy.com-spymap/1000/6cda8922-2943-11e0-b622-639ef8e43974"></application> <application app_name="hash" app_data="insert/sip.yyy.com-last_dial/1000/*9664"></application> <application app_name="hash" app_data="insert/sip.yyy.com-last_dial/global/6cda8922-2943-11e0-b622-639ef8e43974"></application> <application app_name="set" app_data="RFC2822_DATE=Wed, 26 Jan 2011 13:57:18 +0200"></application> <application app_name="set" app_data="zrtp_secure_media=true"></application> <application app_name="answer" app_data=""></application> <application app_name="playback" app_data="silence_stream://2000"></application> <application app_name="execute_extension" app_data="is_zrtp_secure XML features"></application> <application app_name="eval" app_data="not_secure"></application> <application app_name="playback" app_data="local_stream://moh"></application> </app_log> <callflow dialplan="XML" profile_index="1"> <extension name="global" number="*9664"> <application app_name="hash" app_data="insert/${domain_name}-spymap/${caller_id_number}/${uuid}"></application> <application app_name="hash" app_data="insert/${domain_name}-last_dial/${caller_id_number}/${destination_number}"></application> <application app_name="hash" app_data="insert/${domain_name}-last_dial/global/${uuid}"></application> <application app_name="set" app_data="RFC2822_DATE=${strftime(%a, %d %b %Y %T %z)}"></application> <application app_name="set" app_data="zrtp_secure_media=true"></application> <application app_name="answer" app_data=""></application> <application app_name="playback" app_data="silence_stream://2000"></application> <application app_name="execute_extension" app_data="is_zrtp_secure XML features"></application> <application app_name="playback" app_data="local_stream://moh"></application> <sub_extensions> <extension name="is_zrtp_secure" number="is_zrtp_secure" dialplan="XML"> <application app_name="eval" app_data="not_secure"></application> </extension> </sub_extensions> </extension> <caller_profile> <username>1000</username> <dialplan>XML</dialplan> <caller_id_name>1000</caller_id_name> <ani>1000</ani> <aniii></aniii> <caller_id_number>1000</caller_id_number> <network_addr>79.176.yyy.32</network_addr> <rdnis></rdnis> <destination_number>*9664</destination_number> <uuid>6cda8922-2943-11e0-b622-639ef8e43974</uuid> <source>mod_sofia</source> <context>default</context> <chan_name>sofia/internal/1000@sip-ha.yyy.com</chan_name> </caller_profile> <times> <created_time>1296043038692089</created_time> <profile_created_time>1296043038692089</profile_created_time> <progress_time>0</progress_time> <progress_media_time>1296043038708572</progress_media_time> <answered_time>1296043038708572</answered_time> <hangup_time>0</hangup_time> <resurrect_time>0</resurrect_time> <transfer_time>0</transfer_time> </times> </callflow> </cdr>
On Wed, Jan 26, 2011 at 12:53 PM, Tihomir Culjaga <tculjaga@gmail.com>wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
_______________________________________________ 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
hmmm, it should be working :P void sofia_glue_tech_track(sofia_profile_t *profile, switch_core_session_t *session) { switch_event_t *event; private_object_t *tech_pvt = (private_object_t *) switch_core_session_get_private(session); if (!sofia_test_pflag(profile, PFLAG_TRACK_CALLS) || sofia_test_flag(tech_pvt, TFLAG_RECOVERING)) { return; } if (sofia_test_flag(tech_pvt, TFLAG_TRACKED)) { sofia_glue_tech_untrack(profile, session, SWITCH_TRUE); } if (switch_event_create(&event, SWITCH_EVENT_CHANNEL_DATA) == SWITCH_STATUS_SUCCESS) { switch_xml_t cdr = NULL; char *xml_cdr_text = NULL; if (switch_ivr_generate_xml_cdr(session, &cdr) == SWITCH_STATUS_SUCCESS) { xml_cdr_text = switch_xml_toxml(cdr, SWITCH_FALSE); switch_xml_free(cdr); } if (xml_cdr_text) { char *sql; sql = switch_mprintf("insert into sip_recovery (runtime_uuid, profile_name, hostname, uuid, metadata) values ('%q','%q','%q','%q','%q')", switch_core_get_uuid(), profile->name, mod_sofia_globals.hostname, switch_core_session_get_uuid(session), xml_cdr_text); sofia_glue_execute_sql_now(profile, &sql, SWITCH_TRUE); free(xml_cdr_text); sofia_set_flag(tech_pvt, TFLAG_TRACKED); } } } im gonna dig why xml_cdr_text is empty. On Wed, Jan 26, 2011 at 1:20 PM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
dam, your metadata is awesome ... now i see the difference.
i do have track calls enabled on both profiles (internal & external) and i have odbc configured as well.
but my version is:
freeswitch@cxss01> version
FreeSWITCH Version 1.0.6 (svn-exported)
freeswitch@cxss01>
how can i make sure it is because of the version ?
freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> sofia profile external start 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 debug [0] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-trace [no] *2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 track-calls [true]* 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rfc2833-pt [101] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-port [5080] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dialplan [XML] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 context [public] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dtmf-duration [70] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:3279 Duration out of bounds, using default of 2000! 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dtmf-type [inband] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 inbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 outbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 hold-music [local_stream://moh] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-timer-name [soft] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 local-network-acl [localnet.auto] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 manage-presence [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 inbound-codec-negotiation [generous] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 nonce-ttl [60] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 auth-calls [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-ip [195.88.212.30] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-ip [195.88.212.30] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 ext-rtp-ip [auto-nat] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 ext-sip-ip [auto-nat] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-timeout-sec [300] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-hold-timeout-sec [1800] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-bind-params [transport=tls] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-sip-port [5081] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-cert-dir [/usr/local/freeswitch/conf/ssl] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-version [tlsv1] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 odbc-dsn [COREFSdrv:adminfs:4F0s8wj] 2011-01-26 13:14:11.423588 [NOTICE] sofia_reg.c:2451 Added gateway ' example.com' to profile 'external' 2011-01-26 13:14:11.423588 [NOTICE] sofia.c:3535 Connecting ODBC Profile external [sofia_reg_external] 2011-01-26 13:14:11.424818 [DEBUG] sofia.c:1317 Creating agent for external 2011-01-26 13:14:11.438512 [INFO] sofia_glue.c:4569 Connected ODBC DSN: COREFSdrv 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1353 Created agent for external 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1389 Set params for external 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1412 Activated db for external 2011-01-26 13:14:11.460603 [DEBUG] sofia.c:1439 Starting thread for external
external started successfully
freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> sofia profile internal start 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 debug [0] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-trace [no] *2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 track-calls [true]* 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 log-auth-failures [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 context [public] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rfc2833-pt [101] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-port [5060] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dialplan [XML] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dtmf-duration [70] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:3279 Duration out of bounds, using default of 2000! 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 outbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-timer-name [soft] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-ip [195.88.212.30] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-ip [195.88.212.30] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 hold-music [local_stream://moh] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 apply-nat-acl [nat.auto] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 apply-inbound-acl [domains] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 local-network-acl [localnet.auto] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dtmf-type [inband] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 record-path [/usr/local/freeswitch/recordings] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 record-template [${caller_id_number}.${target_domain}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 manage-presence [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-codec-negotiation [generous] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls [false] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-bind-params [transport=tls] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-sip-port [5061] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-cert-dir [/usr/local/freeswitch/conf/ssl] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-version [tlsv1] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 odbc-dsn [COREFSdrv:adminfs:4F0s8wj] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-late-negotiation [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 nonce-ttl [60] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 auth-calls [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-reg-force-matching-username [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 auth-all-packets [false] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 ext-rtp-ip [auto-nat] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 ext-sip-ip [auto-nat] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-timeout-sec [300] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-hold-timeout-sec [1800] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-register-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-subscription-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-register-db-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 challenge-realm [auto_from] 2011-01-26 13:14:16.440442 [NOTICE] sofia_reg.c:2451 Added gateway 'hr-sbc01' to profile 'internal' 2011-01-26 13:14:16.441444 [NOTICE] sofia_reg.c:2451 Added gateway 'hr-sbc02' to profile 'internal' 2011-01-26 13:14:16.441444 [NOTICE] sofia.c:2040 Adding Alias [195.88.212.31] for profile [internal] 2011-01-26 13:14:16.441444 [NOTICE] sofia.c:3535 Connecting ODBC Profile internal [sofia_reg_internal] 2011-01-26 13:14:16.441444 [DEBUG] sofia.c:1317 Creating agent for internal 2011-01-26 13:14:16.455326 [INFO] sofia_glue.c:4569 Connected ODBC DSN: COREFSdrv 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1353 Created agent for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1389 Set params for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1412 Activated db for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1439 Starting thread for internal
internal started successfully
i do have track-calls enabled on the sip profiles.
and yes, FS is quite outdated:
freeswitch@cxss01> version
FreeSWITCH Version 1.0.6 (svn-exported)
freeswitch@cxss01>
On Wed, Jan 26, 2011 at 1:00 PM, Avi Marcus <avi@avimarcus.net> wrote:
The sip recovery table should have a LOT more data than that, all stuffed into a single column. Do you have track calls on in all the involved profiles? I suppose it really wouldn't be here otherwise.
e.g. my sip_recovery table has this in the metadata field for a "simple" MOH call. Does yours?
<cdr> <channel_data> <state>CS_EXECUTE</state> <direction>inbound</direction> <state_number>4</state_number> <flags>0=1;1=1;3=1;35=1;41=1;51=1</flags> <caps>1=1;2=1;3=1;4=1;5=1</caps> </channel_data> <variables> <direction>inbound</direction> <uuid>6cda8922-2943-11e0-b622-639ef8e43974</uuid> <sip_local_network_addr>178.79.147.47</sip_local_network_addr> <sip_network_ip>79.176.185.32</sip_network_ip> <sip_network_port>5072</sip_network_port> <sip_received_ip>79.176.yyy.32</sip_received_ip> <sip_received_port>5072</sip_received_port> <sip_via_protocol>udp</sip_via_protocol> <sip_authorized>true</sip_authorized> <sip_number_alias>1000</sip_number_alias> <sip_auth_username>1000</sip_auth_username> <sip_auth_realm>sip-ha.yyy.com</sip_auth_realm> <number_alias>1000</number_alias> <user_name>1000</user_name> <domain_name>sip.yyy.com</domain_name> <record_stereo>true</record_stereo> <default_areacode>208</default_areacode> <transfer_fallback_extension>operator</transfer_fallback_extension> <accountcode>1000</accountcode> <user_context>default</user_context> <effective_caller_id_name>Avi%20Marcus</effective_caller_id_name> <effective_caller_id_number>12013554419</effective_caller_id_number> <outbound_caller_id_name>Avi%20Marcus</outbound_caller_id_name> <outbound_caller_id_number>12013554419</outbound_caller_id_number> <nibble_account>1000</nibble_account> <sip_from_user>1000</sip_from_user> <sip_from_uri>1000%40sip-ha.yyy.com</sip_from_uri> <sip_from_host>sip-ha.yyy.com</sip_from_host> <sip_from_user_stripped>1000</sip_from_user_stripped> <sofia_profile_name>internal</sofia_profile_name> <sip_Remote-Party-ID>%3Csip%3A1000%40sip-ha.yyy.com %3E%3Bscreen%3Dyes%3Bparty%3Dcalling</sip_Remote-Party-ID> <sip_cid_type>rpid</sip_cid_type>
<sip_full_via>SIP/2.0/UDP%20192.168.1.5%3A5072%3Bbranch%3Dz9hG4bK-329da816%3Brport%3D5072%3Breceived%3D79.176.185.32</sip_full_via> <sip_req_user>*9664</sip_req_user> <sip_req_uri>*9664%40sip-ha.yyy.com</sip_req_uri> <sip_req_host>sip-ha.yyy.com</sip_req_host> <sip_to_user>*9664</sip_to_user> <sip_to_uri>*9664%40sip-ha.yyy.com</sip_to_uri> <sip_to_host>sip-ha.yyy.com</sip_to_host> <sip_contact_user>1000</sip_contact_user> <sip_contact_port>5072</sip_contact_port> <sip_contact_uri>1000%4079.176.yyy.32%3A5072</sip_contact_uri> <sip_contact_host>79.176.yyy.32</sip_contact_host> <channel_name>sofia/internal/1000%40sip-ha.yyy.com</channel_name> <sip_user_agent>Linksys/SPA2102-5.2.10</sip_user_agent> <sip_via_host>192.168.1.5</sip_via_host> <sip_via_port>5072</sip_via_port> <sip_via_rport>5072</sip_via_rport> <max_forwards>70</max_forwards> <presence_id>1000%40sip-ha.yyy.com</presence_id>
<switch_r_sdp>v%3D0%0D%0Ao%3D-%2033038436%2033038436%20IN%20IP4%2079.176.185.32%0D%0As%3D-%0D%0Ac%3DIN%20IP4%2079.176.185.32%0D%0At%3D0%200%0D%0Am%3Daudio%2016422%20RTP/AVP%2018%200%202%204%208%2096%2097%2098%20100%20101%0D%0Aa%3Drtpmap%3A18%20G729/8000%0D%0Aa%3Drtpmap%3A0%20PCMU/8000%0D%0Aa%3Drtpmap%3A2%20G726-32/8000%0D%0Aa%3Drtpmap%3A4%20G723/8000%0D%0Aa%3Drtpmap%3A8%20PCMA/8000%0D%0Aa%3Drtpmap%3A96%20G726-40/8000%0D%0Aa%3Drtpmap%3A97%20G726-24/8000%0D%0Aa%3Drtpmap%3A98%20G726-16/8000%0D%0Aa%3Drtpmap%3A100%20NSE/8000%0D%0Aa%3Dfmtp%3A100%20192-193%0D%0Aa%3Drtpmap%3A101%20telephone-event/8000%0D%0Aa%3Dfmtp%3A101%200-15%0D%0Aa%3Dptime%3A20%0D%0A</switch_r_sdp>
<ep_codec_string>PCMU%408000h%4020i%4064000b,PCMA%408000h%4020i%4064000b</ep_codec_string> <nibble_current_balance>0.000000</nibble_current_balance>
<RFC2822_DATE>Wed,%2026%20Jan%202011%2013%3A57%3A18%20%2B0200</RFC2822_DATE> <zrtp_secure_media>true</zrtp_secure_media> <sip_use_codec_name>PCMU</sip_use_codec_name> <sip_use_codec_rate>8000</sip_use_codec_rate> <sip_use_codec_ptime>20</sip_use_codec_ptime> <read_codec>PCMU</read_codec> <read_rate>8000</read_rate> <write_codec>PCMU</write_codec> <write_rate>8000</write_rate> <local_media_ip>178.79.yyy.47</local_media_ip> <local_media_port>19600</local_media_port> <sip_use_pt>0</sip_use_pt> <rtp_use_ssrc>922702377</rtp_use_ssrc> <remote_media_ip>79.176.185.32</remote_media_ip> <remote_media_port>16422</remote_media_port>
<sip_local_sdp_str>v%3D0%0Ao%3DFreeSWITCH%201296023438%201296023439%20IN%20IP4%20178.79.147.47%0As%3DFreeSWITCH%0Ac%3DIN%20IP4%20178.79.147.47%0At%3D0%200%0Am%3Daudio%2019600%20RTP/AVP%200%20101%0Aa%3Drtpmap%3A0%20PCMU/8000%0Aa%3Drtpmap%3A101%20telephone-event/8000%0Aa%3Dfmtp%3A101%200-16%0Aa%3DsilenceSupp%3Aoff%20-%20-%20-%20-%0Aa%3Dptime%3A20%0Aa%3Dsendrecv%0A</sip_local_sdp_str> <endpoint_disposition>ANSWER</endpoint_disposition> <sip_to_tag>vgcH82ctg6QaD</sip_to_tag> <sip_from_tag>9241a2573e4f702o0</sip_from_tag> <sip_cseq>102</sip_cseq> <sip_call_id>17217721-3d90de36%40192.168.1.5</sip_call_id> <sip_full_from>%3Csip%3A1000%40sip-ha.yyy.com %3E%3Btag%3D9241a2573e4f702o0</sip_full_from> <sip_full_to>%3Csip%3A*9664%40sip-ha.yyy.com %3E%3Btag%3DvgcH82ctg6QaD</sip_full_to> <playback_seconds>2</playback_seconds> <playback_ms>2000</playback_ms> <playback_samples>16000</playback_samples>
<current_application_data>local_stream%3A//moh</current_application_data> <current_application>playback</current_application> </variables> <app_log> <application app_name="hash" app_data="insert/sip.yyy.com-spymap/1000/6cda8922-2943-11e0-b622-639ef8e43974"></application> <application app_name="hash" app_data="insert/sip.yyy.com-last_dial/1000/*9664"></application> <application app_name="hash" app_data="insert/sip.yyy.com-last_dial/global/6cda8922-2943-11e0-b622-639ef8e43974"></application> <application app_name="set" app_data="RFC2822_DATE=Wed, 26 Jan 2011 13:57:18 +0200"></application> <application app_name="set" app_data="zrtp_secure_media=true"></application> <application app_name="answer" app_data=""></application> <application app_name="playback" app_data="silence_stream://2000"></application> <application app_name="execute_extension" app_data="is_zrtp_secure XML features"></application> <application app_name="eval" app_data="not_secure"></application> <application app_name="playback" app_data="local_stream://moh"></application> </app_log> <callflow dialplan="XML" profile_index="1"> <extension name="global" number="*9664"> <application app_name="hash" app_data="insert/${domain_name}-spymap/${caller_id_number}/${uuid}"></application> <application app_name="hash" app_data="insert/${domain_name}-last_dial/${caller_id_number}/${destination_number}"></application> <application app_name="hash" app_data="insert/${domain_name}-last_dial/global/${uuid}"></application> <application app_name="set" app_data="RFC2822_DATE=${strftime(%a, %d %b %Y %T %z)}"></application> <application app_name="set" app_data="zrtp_secure_media=true"></application> <application app_name="answer" app_data=""></application> <application app_name="playback" app_data="silence_stream://2000"></application> <application app_name="execute_extension" app_data="is_zrtp_secure XML features"></application> <application app_name="playback" app_data="local_stream://moh"></application> <sub_extensions> <extension name="is_zrtp_secure" number="is_zrtp_secure" dialplan="XML"> <application app_name="eval" app_data="not_secure"></application> </extension> </sub_extensions> </extension> <caller_profile> <username>1000</username> <dialplan>XML</dialplan> <caller_id_name>1000</caller_id_name> <ani>1000</ani> <aniii></aniii> <caller_id_number>1000</caller_id_number> <network_addr>79.176.yyy.32</network_addr> <rdnis></rdnis> <destination_number>*9664</destination_number> <uuid>6cda8922-2943-11e0-b622-639ef8e43974</uuid> <source>mod_sofia</source> <context>default</context> <chan_name>sofia/internal/1000@sip-ha.yyy.com</chan_name> </caller_profile> <times> <created_time>1296043038692089</created_time> <profile_created_time>1296043038692089</profile_created_time> <progress_time>0</progress_time> <progress_media_time>1296043038708572</progress_media_time> <answered_time>1296043038708572</answered_time> <hangup_time>0</hangup_time> <resurrect_time>0</resurrect_time> <transfer_time>0</transfer_time> </times> </callflow> </cdr>
On Wed, Jan 26, 2011 at 12:53 PM, Tihomir Culjaga <tculjaga@gmail.com>wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
_______________________________________________ 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
ya, I added a line: switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_NOTICE, "sip_recovery SQL => %s\n", sql); and found that it actually inserts the xml_cdr_text into sip_recovery table ... its just isql command line utility that was unable to display it ... maybe because of xml tags. Anyhow, metadata looks like: ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- <cdr> <channel_data> <state>CS_EXECUTE</state> <direction>inbound</direction> <state_number>4</state_number> <flags>0=1;1=1;35=1;41=1;51=1</flags> <caps>1=1;2=1;3=1</caps> </channel_data> <variables> <uuid>4be94b6f-1df1-45bd-b920-1c55185dc3bd</uuid> <sip_local_network_addr>195.88.212.30</sip_local_network_addr> <sip_network_ip>195.88.212.39</sip_network_ip> <sip_network_port>49603</sip_network_port> <sip_received_ip>195.88.212.39</sip_received_ip> <sip_received_port>49603</sip_received_port> <sip_via_protocol>udp</sip_via_protocol> <sip_from_user>38515492122</sip_from_user> <sip_from_uri>38515492122%40195.88.212.39</sip_from_uri> <sip_from_host>195.88.212.39</sip_from_host> <sip_from_user_stripped>38515492122</sip_from_user_stripped> <sofia_profile_name>external</sofia_profile_name> <sip_Remote-Party-ID>%3Csip%3A38515492122%40195.88.212.39%3E%3Bparty%3Dcalling%3Bscreen%3Dyes%3Bprivacy%3Doff</sip_Remote-Party-ID> <sip_cid_type>rpid</sip_cid_type> <sip_full_via>SIP/2.0/UDP%20195.88.212.39%3A5060%3Bbranch%3Dz9hG4bK27A84C</sip_full_via> <sip_req_user>38518880050</sip_req_user> <sip_req_port>5080</sip_req_port> <sip_req_uri>38518880050%40195.88.212.30%3A5080</sip_req_uri> <sip_req_host>195.88.212.30</sip_req_host> <sip_to_user>38518880050</sip_to_user> <sip_to_uri>38518880050%40195.88.212.30</sip_to_uri> <sip_to_host>195.88.212.30</sip_to_host> <sip_contact_user>38515492122</sip_contact_user> <sip_contact_port>5060</sip_contact_port> <sip_contact_uri>38515492122%40195.88.212.39%3A5060</sip_contact_uri> <sip_contact_host>195.88.212.39</sip_contact_host> <channel_name>sofia/external/38515492122%40195.88.212.39</channel_name> <sip_user_agent>Cisco-SIPGateway/IOS-12.x</sip_user_agent> <sip_via_host>195.88.212.39</sip_via_host> <sip_via_port>5060</sip_via_port> <switch_r_sdp>v%3D0%0D%0Ao%3DCiscoSystemsSIP-GW-UserAgent%203218%205821%20IN%20IP4%20195.88.212.39%0D%0As%3DSIP%20Call%0D%0Ac%3DIN%20IP4%20195.88.212.39%0D%0At%3D0%200%0D%0Am%3Daudio%2016464%20RTP/AVP%208%20101%0D%0Ac%3DIN%20IP4%20195.88.212.39%0D%0Aa%3Drtpmap%3A8%20PCMA/8000%0D%0Aa%3Drtpmap%3A101%20telephone-event/8000%0D%0Aa%3Dfmtp%3A101%200-16%0D%0Aa%3Dptime%3A20%0D%0A</switch_r_sdp> <sip_use_codec_name>PCMA</sip_use_codec_name> <sip_use_codec_rate>8000</sip_use_codec_rate> <sip_use_codec_ptime>20</sip_use_codec_ptime> <read_codec>PCMA</read_codec> <read_rate>8000</read_rate> <write_codec>PCMA</write_codec> <write_rate>8000</write_rate> <outside_call>true</outside_call> <domain_name>195.88.212.31</domain_name> <max_forwards>69</max_forwards> <myDNIS>38518880050</myDNIS> <sip_local_sdp_str>v%3D0%0Ao%3DFreeSWITCH%201296021156%201296021157%20IN%20IP4%20195.88.212.30%0As%3DFreeSWITCH%0Ac%3DIN%20IP4%20195.88.212.30%0At%3D0%200%0Am%3Daudio%2025930%20RTP/AVP%208%0Aa%3Drtpmap%3A8%20PCMA/8000%0Aa%3DsilenceSupp%3Aoff%20-%20-%20-%20-%0Aa%3Dptime%3A20%0Aa%3Dsendrecv%0A</sip_local_sdp_str> <local_media_ip>195.88.212.30</local_media_ip> <local_media_port>25930</local_media_port> <sip_use_pt>8</sip_use_pt> <rtp_use_ssrc>1713917945</rtp_use_ssrc> <remote_media_ip>195.88.212.39</remote_media_ip> <remote_media_port>16464</remote_media_port> <endpoint_disposition>ANSWER</endpoint_disposition> <sip_to_tag>va1j6gN6FQKtp</sip_to_tag> <sip_from_tag>CDA3D150-264D</sip_from_tag> <sip_cseq>101</sip_cseq> <sip_call_id>AED34DF0-288311E0-89BBD88B-B59C2BD1%40195.88.212.39</sip_call_id> <sip_full_from>%3Csip%3A38515492122%40195.88.212.39%3E%3Btag%3DCDA3D150-264D</sip_full_from> <sip_full_to>%3Csip%3A38518880050%40195.88.212.30%3E%3Btag%3Dva1j6gN6FQKtp</sip_full_to> <language>hr</language> <CALLID>h323-conf-id%3D4be94b6f-1df1-45bd-b920-1c55185dc3bd</CALLID> <SERVICENUM>h323-prompt-id%3D38518880050</SERVICENUM> <TRANSACTIONID>h323-ivr-out%3DtransactionID%3A1234</TRANSACTIONID> <auto_hunt>true</auto_hunt> <CALLINGNUMBER>38515492122</CALLINGNUMBER> <billing_model>h323-billing-model%3D0</billing_model> <return_code>h323-return-code%3D0</return_code> <ANI_AUTH_RESULT>OK</ANI_AUTH_RESULT> <UNAME>38515492122</UNAME> <PASSWD>1234</PASSWD> <export_vars>myDNIS,UNAME,PASSWD</export_vars> <sound_prefix>/usr/local/freeswitch/sounds/hr/HR/teta1</sound_prefix> <ENTER_DEST_PR>tone_stream%3A//%25(200,300,425,425)%3B%25(700,800,425,425)%3Bloops%3D5</ENTER_DEST_PR> <DST_TIMEOUT>1000</DST_TIMEOUT> <playback_seconds>0</playback_seconds> <playback_ms>0</playback_ms> <playback_samples>0</playback_samples> <read_result>failure</read_result> <DN_INT>false</DN_INT> <DN_NAT>false</DN_NAT> <DN_LOC>false</DN_LOC> <DST_ERR_PR>ivr/_no_dest_entered2.wav</DST_ERR_PR> <DST_RETRIES>2</DST_RETRIES> <bind_meta_key></bind_meta_key> <playback_delimiter>!</playback_delimiter> <playback_terminators>%23*0123456789</playback_terminators> <current_application_data>6%2020%20ivr/_no_dest_entered2.wav!tone_stream%3A//%25(200,300,425,425)%3B%25(700,800,425,425)%3Bloops%3D5%20DN%201000%20*</current_application_data> <current_application>read</current_application> </variables> <app_log> <application app_name="set" app_data="outside_call=true"></application> <application app_name="set" app_data="domain_name=195.88.212.31"></application> <application app_name="transfer" app_data="38518880050 XML default"></application> <application app_name="export" app_data="myDNIS=38518880050"></application> <application app_name="set" app_data="playback_terminators=#*0123456789"></application> <application app_name="answer" app_data=""></application> <application app_name="sleep" app_data="100"></application> <application app_name="set" app_data="language=hr"></application> <application app_name="set" app_data="CALLID=h323-conf-id=4be94b6f-1df1-45bd-b920-1c55185dc3bd"></application> <application app_name="set" app_data="SERVICENUM=h323-prompt-id=38518880050"></application> <application app_name="set" app_data="TRANSACTIONID=h323-ivr-out=transactionID:1234"></application> <application app_name="set" app_data="auto_hunt=true"></application> <application app_name="execute_extension" app_data="ANIorPIN XML NXIVR"></application> <application app_name="export" app_data="DIALED_NUMBER="></application> <application app_name="set" app_data="CALLINGNUMBER=38515492122"></application> <application app_name="auth_function" app_data="in , in 38515492122, in 1234, out ANI_AUTH_RESULT"></application> <application app_name="execute_extension" app_data="CheckANI XML NXIVR"></application> <application app_name="export" app_data="UNAME=38515492122"></application> <application app_name="export" app_data="PASSWD=1234"></application> <application app_name="set" app_data="sound_prefix=/usr/local/freeswitch/sounds/hr/HR/teta1"></application> <application app_name="set" app_data="ENTER_DEST_PR=tone_stream://%(200,300,425,425);%(700,800,425,425);loops=5"></application> <application app_name="set" app_data="DST_TIMEOUT=1000"></application> <application app_name="execute_extension" app_data="GetDstNum XML NXIVR"></application> <application app_name="set" app_data="DST_RETRIES=1"></application> <application app_name="set" app_data="bind_meta_key=#"></application> <application app_name="bind_meta_app" app_data="0 a a transfer::LongDTMF XML NXIVR"></application> <application app_name="set" app_data="playback_delimiter=!"></application> <application app_name="set" app_data="playback_terminators=#*0123456789"></application> <application app_name="start_dtmf" app_data=""></application> <application app_name="read" app_data="6 20 !tone_stream://%(200,300,425,425);%(700,800,425,425);loops=5 DN 1000 *"></application> <application app_name="stop_dtmf" app_data=""></application> <application app_name="execute_extension" app_data="TranslateLocal XML NXIVR"></application> <application app_name="set" app_data="DN_INT=false"></application> <application app_name="set" app_data="DN_NAT=false"></application> <application app_name="set" app_data="DN_LOC=false"></application> <application app_name="export" app_data="DIALED_NUMBER="></application> <application app_name="export" app_data="DIALED_NUMBER="></application> <application app_name="export" app_data="DIALED_NUMBER="></application> <application app_name="execute_extension" app_data="ParseDN XML NXIVR"></application> <application app_name="log" app_data="INFO ################# EMPTY DESTINATION ################ "></application> <application app_name="set" app_data="DST_ERR_PR=ivr/_no_dest_entered2.wav"></application> <application app_name="execute_extension" app_data="DstRetries XML NXIVR"></application> <application app_name="execute_extension" app_data="GetDstNum XML NXIVR"></application> <application app_name="set" app_data="DST_RETRIES=2"></application> <application app_name="set" app_data="bind_meta_key=#"></application> <application app_name="bind_meta_app" app_data="0 a a transfer::LongDTMF XML NXIVR"></application> <application app_name="set" app_data="playback_delimiter=!"></application> <application app_name="set" app_data="playback_terminators=#*0123456789"></application> <application app_name="start_dtmf" app_data=""></application> <application app_name="read" app_data="6 20 ivr/_no_dest_entered2.wav!tone_stream://%(200,300,425,425);%(700,800,425,425);loops=5 DN 1000 *"></application> </app_log> <callflow dialplan="XML"> <extension name="GetDstNum" number="GetDstNum" current_app="read"> <application app_name="set" app_data="bind_meta_key=#"></application> <application app_name="bind_meta_app" app_data="0 a a transfer::LongDTMF XML NXIVR"></application> <application app_name="set" app_data="playback_delimiter=!"></application> <application app_name="set" app_data="playback_terminators=#*0123456789"></application> <application app_name="start_dtmf" app_data=""></application> <application last_executed="true" app_name="read" app_data="${DST_MIN_DIG} ${DST_MAX_DIG} ${DST_ERR_PR}!${ENTER_DEST_PR} DN ${DST_TIMEOUT} *"></application> <application app_name="stop_dtmf" app_data=""></application> <application app_name="execute_extension" app_data="TranslateLocal XML NXIVR"></application> <application app_name="execute_extension" app_data="ParseDN XML NXIVR"></application> <application app_name="auth_function" app_data="in ${DIALED_NUMBER}, in ${UNAME}, in ${PASSWD}, out AUTH_RESULT"></application> <application app_name="set" app_data="CALLINGNUMBER=${caller_id_number}"></application> <application app_name="execute_extension" app_data="PARSE_RET_CODE XML NXIVR"></application> <application app_name="execute_extension" app_data="CheckDstNum XML NXIVR"></application> </extension> <caller_profile> <username>38515492122</username> <dialplan>XML</dialplan> <caller_id_name>38515492122</caller_id_name> <ani>38515492122</ani> <aniii></aniii> <caller_id_number>38515492122</caller_id_number> <network_addr>195.88.212.39</network_addr> <rdnis>38518880050</rdnis> <destination_number>GetDstNum</destination_number> <uuid>4be94b6f-1df1-45bd-b920-1c55185dc3bd</uuid> <source>mod_sofia</source> <context>NXIVR</context> <chan_name>sofia/external/38515492122@195.88.212.39</chan_name> </caller_profile> </callflow> </cdr> is we have full info of the call ... and still no joy :) well, its time for the update i guess... a lot of pain in the next hours. On Wed, Jan 26, 2011 at 1:32 PM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
hmmm,
it should be working :P
void sofia_glue_tech_track(sofia_profile_t *profile, switch_core_session_t *session) { switch_event_t *event; private_object_t *tech_pvt = (private_object_t *) switch_core_session_get_private(session);
if (!sofia_test_pflag(profile, PFLAG_TRACK_CALLS) || sofia_test_flag(tech_pvt, TFLAG_RECOVERING)) { return; }
if (sofia_test_flag(tech_pvt, TFLAG_TRACKED)) { sofia_glue_tech_untrack(profile, session, SWITCH_TRUE); }
if (switch_event_create(&event, SWITCH_EVENT_CHANNEL_DATA) == SWITCH_STATUS_SUCCESS) { switch_xml_t cdr = NULL; char *xml_cdr_text = NULL;
if (switch_ivr_generate_xml_cdr(session, &cdr) == SWITCH_STATUS_SUCCESS) { xml_cdr_text = switch_xml_toxml(cdr, SWITCH_FALSE); switch_xml_free(cdr); }
if (xml_cdr_text) { char *sql; sql = switch_mprintf("insert into sip_recovery (runtime_uuid, profile_name, hostname, uuid, metadata) values ('%q','%q','%q','%q','%q')",
switch_core_get_uuid(), profile->name, mod_sofia_globals.hostname, switch_core_session_get_uuid(session), xml_cdr_text);
sofia_glue_execute_sql_now(profile, &sql, SWITCH_TRUE); free(xml_cdr_text); sofia_set_flag(tech_pvt, TFLAG_TRACKED); }
}
}
im gonna dig why xml_cdr_text is empty.
On Wed, Jan 26, 2011 at 1:20 PM, Tihomir Culjaga <tculjaga@gmail.com>wrote:
dam, your metadata is awesome ... now i see the difference.
i do have track calls enabled on both profiles (internal & external) and i have odbc configured as well.
but my version is:
freeswitch@cxss01> version
FreeSWITCH Version 1.0.6 (svn-exported)
freeswitch@cxss01>
how can i make sure it is because of the version ?
freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> sofia profile external start 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 debug [0] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-trace [no] *2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 track-calls [true]* 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rfc2833-pt [101] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-port [5080] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dialplan [XML] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 context [public] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dtmf-duration [70] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:3279 Duration out of bounds, using default of 2000! 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 dtmf-type [inband] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 inbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 outbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 hold-music [local_stream://moh] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-timer-name [soft] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 local-network-acl [localnet.auto] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 manage-presence [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 inbound-codec-negotiation [generous] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 nonce-ttl [60] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 auth-calls [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-ip [195.88.212.30] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 sip-ip [195.88.212.30] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 ext-rtp-ip [auto-nat] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 ext-sip-ip [auto-nat] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-timeout-sec [300] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 rtp-hold-timeout-sec [1800] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls [false] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-bind-params [transport=tls] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-sip-port [5081] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-cert-dir [/usr/local/freeswitch/conf/ssl] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 tls-version [tlsv1] 2011-01-26 13:14:11.423588 [DEBUG] sofia.c:2755 odbc-dsn [COREFSdrv:adminfs:4F0s8wj] 2011-01-26 13:14:11.423588 [NOTICE] sofia_reg.c:2451 Added gateway ' example.com' to profile 'external' 2011-01-26 13:14:11.423588 [NOTICE] sofia.c:3535 Connecting ODBC Profile external [sofia_reg_external] 2011-01-26 13:14:11.424818 [DEBUG] sofia.c:1317 Creating agent for external 2011-01-26 13:14:11.438512 [INFO] sofia_glue.c:4569 Connected ODBC DSN: COREFSdrv 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1353 Created agent for external 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1389 Set params for external 2011-01-26 13:14:11.459433 [DEBUG] sofia.c:1412 Activated db for external 2011-01-26 13:14:11.460603 [DEBUG] sofia.c:1439 Starting thread for external
external started successfully
freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> freeswitch@cxss01> sofia profile internal start 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 debug [0] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-trace [no] *2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 track-calls [true]* 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 log-auth-failures [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 context [public] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rfc2833-pt [101] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-port [5060] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dialplan [XML] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dtmf-duration [70] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:3279 Duration out of bounds, using default of 2000! 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 outbound-codec-prefs [PCMA,GSM] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-timer-name [soft] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-ip [195.88.212.30] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 sip-ip [195.88.212.30] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 hold-music [local_stream://moh] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 apply-nat-acl [nat.auto] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 apply-inbound-acl [domains] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 local-network-acl [localnet.auto] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 dtmf-type [inband] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 record-path [/usr/local/freeswitch/recordings] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 record-template [${caller_id_number}.${target_domain}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 manage-presence [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-codec-negotiation [generous] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls [false] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-bind-params [transport=tls] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-sip-port [5061] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-cert-dir [/usr/local/freeswitch/conf/ssl] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 tls-version [tlsv1] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 odbc-dsn [COREFSdrv:adminfs:4F0s8wj] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-late-negotiation [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 nonce-ttl [60] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 auth-calls [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 inbound-reg-force-matching-username [true] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 auth-all-packets [false] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 ext-rtp-ip [auto-nat] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 ext-sip-ip [auto-nat] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-timeout-sec [300] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 rtp-hold-timeout-sec [1800] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-register-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-subscription-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 force-register-db-domain [195.88.212.31] 2011-01-26 13:14:16.440442 [DEBUG] sofia.c:2755 challenge-realm [auto_from] 2011-01-26 13:14:16.440442 [NOTICE] sofia_reg.c:2451 Added gateway 'hr-sbc01' to profile 'internal' 2011-01-26 13:14:16.441444 [NOTICE] sofia_reg.c:2451 Added gateway 'hr-sbc02' to profile 'internal' 2011-01-26 13:14:16.441444 [NOTICE] sofia.c:2040 Adding Alias [195.88.212.31] for profile [internal] 2011-01-26 13:14:16.441444 [NOTICE] sofia.c:3535 Connecting ODBC Profile internal [sofia_reg_internal] 2011-01-26 13:14:16.441444 [DEBUG] sofia.c:1317 Creating agent for internal 2011-01-26 13:14:16.455326 [INFO] sofia_glue.c:4569 Connected ODBC DSN: COREFSdrv 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1353 Created agent for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1389 Set params for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1412 Activated db for internal 2011-01-26 13:14:16.476319 [DEBUG] sofia.c:1439 Starting thread for internal
internal started successfully
i do have track-calls enabled on the sip profiles.
and yes, FS is quite outdated:
freeswitch@cxss01> version
FreeSWITCH Version 1.0.6 (svn-exported)
freeswitch@cxss01>
On Wed, Jan 26, 2011 at 1:00 PM, Avi Marcus <avi@avimarcus.net> wrote:
The sip recovery table should have a LOT more data than that, all stuffed into a single column. Do you have track calls on in all the involved profiles? I suppose it really wouldn't be here otherwise.
e.g. my sip_recovery table has this in the metadata field for a "simple" MOH call. Does yours?
<cdr> <channel_data> <state>CS_EXECUTE</state> <direction>inbound</direction> <state_number>4</state_number> <flags>0=1;1=1;3=1;35=1;41=1;51=1</flags> <caps>1=1;2=1;3=1;4=1;5=1</caps> </channel_data> <variables> <direction>inbound</direction> <uuid>6cda8922-2943-11e0-b622-639ef8e43974</uuid> <sip_local_network_addr>178.79.147.47</sip_local_network_addr> <sip_network_ip>79.176.185.32</sip_network_ip> <sip_network_port>5072</sip_network_port> <sip_received_ip>79.176.yyy.32</sip_received_ip> <sip_received_port>5072</sip_received_port> <sip_via_protocol>udp</sip_via_protocol> <sip_authorized>true</sip_authorized> <sip_number_alias>1000</sip_number_alias> <sip_auth_username>1000</sip_auth_username> <sip_auth_realm>sip-ha.yyy.com</sip_auth_realm> <number_alias>1000</number_alias> <user_name>1000</user_name> <domain_name>sip.yyy.com</domain_name> <record_stereo>true</record_stereo> <default_areacode>208</default_areacode> <transfer_fallback_extension>operator</transfer_fallback_extension> <accountcode>1000</accountcode> <user_context>default</user_context> <effective_caller_id_name>Avi%20Marcus</effective_caller_id_name> <effective_caller_id_number>12013554419</effective_caller_id_number> <outbound_caller_id_name>Avi%20Marcus</outbound_caller_id_name> <outbound_caller_id_number>12013554419</outbound_caller_id_number> <nibble_account>1000</nibble_account> <sip_from_user>1000</sip_from_user> <sip_from_uri>1000%40sip-ha.yyy.com</sip_from_uri> <sip_from_host>sip-ha.yyy.com</sip_from_host> <sip_from_user_stripped>1000</sip_from_user_stripped> <sofia_profile_name>internal</sofia_profile_name> <sip_Remote-Party-ID>%3Csip%3A1000%40sip-ha.yyy.com %3E%3Bscreen%3Dyes%3Bparty%3Dcalling</sip_Remote-Party-ID> <sip_cid_type>rpid</sip_cid_type>
<sip_full_via>SIP/2.0/UDP%20192.168.1.5%3A5072%3Bbranch%3Dz9hG4bK-329da816%3Brport%3D5072%3Breceived%3D79.176.185.32</sip_full_via> <sip_req_user>*9664</sip_req_user> <sip_req_uri>*9664%40sip-ha.yyy.com</sip_req_uri> <sip_req_host>sip-ha.yyy.com</sip_req_host> <sip_to_user>*9664</sip_to_user> <sip_to_uri>*9664%40sip-ha.yyy.com</sip_to_uri> <sip_to_host>sip-ha.yyy.com</sip_to_host> <sip_contact_user>1000</sip_contact_user> <sip_contact_port>5072</sip_contact_port> <sip_contact_uri>1000%4079.176.yyy.32%3A5072</sip_contact_uri> <sip_contact_host>79.176.yyy.32</sip_contact_host> <channel_name>sofia/internal/1000%40sip-ha.yyy.com</channel_name> <sip_user_agent>Linksys/SPA2102-5.2.10</sip_user_agent> <sip_via_host>192.168.1.5</sip_via_host> <sip_via_port>5072</sip_via_port> <sip_via_rport>5072</sip_via_rport> <max_forwards>70</max_forwards> <presence_id>1000%40sip-ha.yyy.com</presence_id>
<switch_r_sdp>v%3D0%0D%0Ao%3D-%2033038436%2033038436%20IN%20IP4%2079.176.185.32%0D%0As%3D-%0D%0Ac%3DIN%20IP4%2079.176.185.32%0D%0At%3D0%200%0D%0Am%3Daudio%2016422%20RTP/AVP%2018%200%202%204%208%2096%2097%2098%20100%20101%0D%0Aa%3Drtpmap%3A18%20G729/8000%0D%0Aa%3Drtpmap%3A0%20PCMU/8000%0D%0Aa%3Drtpmap%3A2%20G726-32/8000%0D%0Aa%3Drtpmap%3A4%20G723/8000%0D%0Aa%3Drtpmap%3A8%20PCMA/8000%0D%0Aa%3Drtpmap%3A96%20G726-40/8000%0D%0Aa%3Drtpmap%3A97%20G726-24/8000%0D%0Aa%3Drtpmap%3A98%20G726-16/8000%0D%0Aa%3Drtpmap%3A100%20NSE/8000%0D%0Aa%3Dfmtp%3A100%20192-193%0D%0Aa%3Drtpmap%3A101%20telephone-event/8000%0D%0Aa%3Dfmtp%3A101%200-15%0D%0Aa%3Dptime%3A20%0D%0A</switch_r_sdp>
<ep_codec_string>PCMU%408000h%4020i%4064000b,PCMA%408000h%4020i%4064000b</ep_codec_string> <nibble_current_balance>0.000000</nibble_current_balance>
<RFC2822_DATE>Wed,%2026%20Jan%202011%2013%3A57%3A18%20%2B0200</RFC2822_DATE> <zrtp_secure_media>true</zrtp_secure_media> <sip_use_codec_name>PCMU</sip_use_codec_name> <sip_use_codec_rate>8000</sip_use_codec_rate> <sip_use_codec_ptime>20</sip_use_codec_ptime> <read_codec>PCMU</read_codec> <read_rate>8000</read_rate> <write_codec>PCMU</write_codec> <write_rate>8000</write_rate> <local_media_ip>178.79.yyy.47</local_media_ip> <local_media_port>19600</local_media_port> <sip_use_pt>0</sip_use_pt> <rtp_use_ssrc>922702377</rtp_use_ssrc> <remote_media_ip>79.176.185.32</remote_media_ip> <remote_media_port>16422</remote_media_port>
<sip_local_sdp_str>v%3D0%0Ao%3DFreeSWITCH%201296023438%201296023439%20IN%20IP4%20178.79.147.47%0As%3DFreeSWITCH%0Ac%3DIN%20IP4%20178.79.147.47%0At%3D0%200%0Am%3Daudio%2019600%20RTP/AVP%200%20101%0Aa%3Drtpmap%3A0%20PCMU/8000%0Aa%3Drtpmap%3A101%20telephone-event/8000%0Aa%3Dfmtp%3A101%200-16%0Aa%3DsilenceSupp%3Aoff%20-%20-%20-%20-%0Aa%3Dptime%3A20%0Aa%3Dsendrecv%0A</sip_local_sdp_str> <endpoint_disposition>ANSWER</endpoint_disposition> <sip_to_tag>vgcH82ctg6QaD</sip_to_tag> <sip_from_tag>9241a2573e4f702o0</sip_from_tag> <sip_cseq>102</sip_cseq> <sip_call_id>17217721-3d90de36%40192.168.1.5</sip_call_id> <sip_full_from>%3Csip%3A1000%40sip-ha.yyy.com %3E%3Btag%3D9241a2573e4f702o0</sip_full_from> <sip_full_to>%3Csip%3A*9664%40sip-ha.yyy.com %3E%3Btag%3DvgcH82ctg6QaD</sip_full_to> <playback_seconds>2</playback_seconds> <playback_ms>2000</playback_ms> <playback_samples>16000</playback_samples>
<current_application_data>local_stream%3A//moh</current_application_data> <current_application>playback</current_application> </variables> <app_log> <application app_name="hash" app_data="insert/sip.yyy.com-spymap/1000/6cda8922-2943-11e0-b622-639ef8e43974"></application> <application app_name="hash" app_data="insert/sip.yyy.com-last_dial/1000/*9664"></application> <application app_name="hash" app_data="insert/sip.yyy.com-last_dial/global/6cda8922-2943-11e0-b622-639ef8e43974"></application> <application app_name="set" app_data="RFC2822_DATE=Wed, 26 Jan 2011 13:57:18 +0200"></application> <application app_name="set" app_data="zrtp_secure_media=true"></application> <application app_name="answer" app_data=""></application> <application app_name="playback" app_data="silence_stream://2000"></application> <application app_name="execute_extension" app_data="is_zrtp_secure XML features"></application> <application app_name="eval" app_data="not_secure"></application> <application app_name="playback" app_data="local_stream://moh"></application> </app_log> <callflow dialplan="XML" profile_index="1"> <extension name="global" number="*9664"> <application app_name="hash" app_data="insert/${domain_name}-spymap/${caller_id_number}/${uuid}"></application> <application app_name="hash" app_data="insert/${domain_name}-last_dial/${caller_id_number}/${destination_number}"></application> <application app_name="hash" app_data="insert/${domain_name}-last_dial/global/${uuid}"></application> <application app_name="set" app_data="RFC2822_DATE=${strftime(%a, %d %b %Y %T %z)}"></application> <application app_name="set" app_data="zrtp_secure_media=true"></application> <application app_name="answer" app_data=""></application> <application app_name="playback" app_data="silence_stream://2000"></application> <application app_name="execute_extension" app_data="is_zrtp_secure XML features"></application> <application app_name="playback" app_data="local_stream://moh"></application> <sub_extensions> <extension name="is_zrtp_secure" number="is_zrtp_secure" dialplan="XML"> <application app_name="eval" app_data="not_secure"></application> </extension> </sub_extensions> </extension> <caller_profile> <username>1000</username> <dialplan>XML</dialplan> <caller_id_name>1000</caller_id_name> <ani>1000</ani> <aniii></aniii> <caller_id_number>1000</caller_id_number> <network_addr>79.176.yyy.32</network_addr> <rdnis></rdnis> <destination_number>*9664</destination_number> <uuid>6cda8922-2943-11e0-b622-639ef8e43974</uuid> <source>mod_sofia</source> <context>default</context> <chan_name>sofia/internal/1000@sip-ha.yyy.com</chan_name> </caller_profile> <times> <created_time>1296043038692089</created_time> <profile_created_time>1296043038692089</profile_created_time> <progress_time>0</progress_time> <progress_media_time>1296043038708572</progress_media_time> <answered_time>1296043038708572</answered_time> <hangup_time>0</hangup_time> <resurrect_time>0</resurrect_time> <transfer_time>0</transfer_time> </times> </callflow> </cdr>
On Wed, Jan 26, 2011 at 12:53 PM, Tihomir Culjaga <tculjaga@gmail.com>wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
_______________________________________________ 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
It shouldn't be hard to update them. Most interfaces haven't changed, and those that have won't have changed much. Any changes will show up as compile-time errors. If you wrote them in the first place then you'll be easily capable of updating them for the latest version. If you have any patches that you think would be beneficial for the entire community you can share them on http://jira.freeswitch.org, then they'll get considered for adding to the trunk - what's the patch for? Patches to trunk modules will always be easier for you to maintain if you can get them into trunk. -Steve On 26 January 2011 10:53, Tihomir Culjaga <tculjaga@gmail.com> wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
On Wed, Jan 26, 2011 at 1:12 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
There is an xml_cdr snapshot in sip_recovery sql table that contains the data used for the recovery. Also based on your logs, you are not using latest git. I would try that first before anything else.
On Tue, Jan 25, 2011 at 7:24 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, both using the same config
can you advice where is FS getting the SDP info for the re-INVITE ?
On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote:
Are you using two machines for the HA? do both have the same configs? -Avi
On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Here is the debug: http://pastebin.freeswitch.org/15133
i have set verbose_sdp=true in vars.xml as. <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/>
but not much to be seen of the verbose thing in the debug...
Still, FS is sending a re-INVITE with wrong SDP. The call to be recovered is using ALAW... and ULAW is not supported. FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is
rejected
due to incompatible SDP.
Where does FS get the information for the SDP in re-INVITE message?
please advice, T.
On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga < tculjaga@gmail.com> wrote:
yap, i do have PCMA ... and the debug shows it correctly :=)
i will try to see what it does with verbose. Post new debug
tomorrow.
ty.
On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com> wrote: > > Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA? > > Steve on iPhone > > On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote: > > > What makes you think that fails? It has ULAW and CN in the codec > > list! > > Sounds like you need the verbose sdp... set the global variable > > "verbose_sdp=true" > > > > /b > > > > On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote: > > > >> > >> > >> i configured FS HA and looks like its trying to recover the call
..
> >> but the re-INVITE fails due to "wrong/missed" codec capability. > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
_______________________________________________ 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
Tihomir, Are you saying all of those are implemented in mod_xml_cdr? If so, that's probably not the best place to implement them. They'd be better off in their own separate modules. - added radius accounting interface
There's already a module for this I believe? http://wiki.freeswitch.org/wiki/Mod_radius_cdr - added odbc cdr interface
This would be better in its own module. - not the best place but
added a function to build up my dial-string... basically the same functionality of LCR module but much more simpler :=)
Indeed it's not, I don't see how CDRs and LCR is related. This would be better as something like mod_custom_lcr. mod_lcr may well do what you need though with custom SQL. Warm Regards, -Steve On 26 January 2011 14:03, Tihomir Culjaga <tculjaga@gmail.com> wrote:
patch for mod_xml_cdr
- added radius accounting interface - added odbc cdr interface
- not the best place but added a function to build up my dial-string... basically the same functionality of LCR module but much more simpler :=)
On 26 January 2011 13:28, Steven Ayre <steveayre@gmail.com> wrote:
It shouldn't be hard to update them. Most interfaces haven't changed, and those that have won't have changed much. Any changes will show up as compile-time errors. If you wrote them in the first place then you'll be easily capable of updating them for the latest version.
If you have any patches that you think would be beneficial for the entire community you can share them on http://jira.freeswitch.org, then they'll get considered for adding to the trunk - what's the patch for?
Patches to trunk modules will always be easier for you to maintain if you can get them into trunk.
-Steve
On 26 January 2011 10:53, Tihomir Culjaga <tculjaga@gmail.com> wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
On Wed, Jan 26, 2011 at 1:12 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
There is an xml_cdr snapshot in sip_recovery sql table that contains the data used for the recovery. Also based on your logs, you are not using latest git. I would try that first before anything else.
On Tue, Jan 25, 2011 at 7:24 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, both using the same config
can you advice where is FS getting the SDP info for the re-INVITE ?
On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote:
Are you using two machines for the HA? do both have the same configs? -Avi
On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga <tculjaga@gmail.com
wrote:
Here is the debug: http://pastebin.freeswitch.org/15133
i have set verbose_sdp=true in vars.xml as. <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/>
but not much to be seen of the verbose thing in the debug...
Still, FS is sending a re-INVITE with wrong SDP. The call to be recovered is using ALAW... and ULAW is not supported. FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected due to incompatible SDP.
Where does FS get the information for the SDP in re-INVITE message?
please advice, T.
On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga < tculjaga@gmail.com> wrote: > > yap, i do have PCMA ... and the debug shows it correctly :=) > > i will try to see what it does with verbose. Post new debug tomorrow. > > ty. > > > On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com
> wrote: >> >> Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA? >> >> Steve on iPhone >> >> On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote: >> >> > What makes you think that fails? It has ULAW and CN in the codec >> > list! >> > Sounds like you need the verbose sdp... set the global variable >> > "verbose_sdp=true" >> > >> > /b >> > >> > On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote: >> > >> >> >> >> >> >> i configured FS HA and looks like its trying to recover the call .. >> >> but the re-INVITE fails due to "wrong/missed" codec capability. >> > >> > >> > _______________________________________________ >> > 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 >> >> _______________________________________________ >> 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 >
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
_______________________________________________ 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
On Wed, Jan 26, 2011 at 4:34 PM, Steven Ayre <steveayre@gmail.com> wrote:
Tihomir,
Are you saying all of those are implemented in mod_xml_cdr?
If so, that's probably not the best place to implement them. They'd be better off in their own separate modules.
well, i have tested it with the original module ... don't wary about that :=) ... I always use default modules if i have issues to see the behaviour.
- added radius accounting interface
There's already a module for this I believe? http://wiki.freeswitch.org/wiki/Mod_radius_cdr
sorry to say that and pls don't get me wrong, but its not good ... and doesn't support adding custom VSAs (something as in mod_rad_auth).
- added odbc cdr interface
This would be better in its own module.
- not the best place but
I don't agree with you here, mod_xml_cdr has already two interfaces (curl and fs) .. why not add radius and odbc as well ? Of course i can move all of that in separate modules ... but why.. i look at that as additional interfaces where i can send the CDR. LCR stuff is on the roadmap already... and i agree its has no place here.
added a function to build up my dial-string... basically the same
functionality of LCR module but much more simpler :=)
Indeed it's not, I don't see how CDRs and LCR is related. This would be better as something like mod_custom_lcr. mod_lcr may well do what you need though with custom SQL.
Warm Regards, -Steve
On 26 January 2011 14:03, Tihomir Culjaga <tculjaga@gmail.com> wrote:
patch for mod_xml_cdr
- added radius accounting interface - added odbc cdr interface
- not the best place but added a function to build up my dial-string... basically the same functionality of LCR module but much more simpler :=)
On 26 January 2011 13:28, Steven Ayre <steveayre@gmail.com> wrote:
It shouldn't be hard to update them. Most interfaces haven't changed, and those that have won't have changed much. Any changes will show up as compile-time errors. If you wrote them in the first place then you'll be easily capable of updating them for the latest version.
If you have any patches that you think would be beneficial for the entire community you can share them on http://jira.freeswitch.org, then they'll get considered for adding to the trunk - what's the patch for?
Patches to trunk modules will always be easier for you to maintain if you can get them into trunk.
-Steve
On 26 January 2011 10:53, Tihomir Culjaga <tculjaga@gmail.com> wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
On Wed, Jan 26, 2011 at 1:12 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
There is an xml_cdr snapshot in sip_recovery sql table that contains the data used for the recovery. Also based on your logs, you are not using latest git. I would try that first before anything else.
On Tue, Jan 25, 2011 at 7:24 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, both using the same config
can you advice where is FS getting the SDP info for the re-INVITE ?
On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote:
Are you using two machines for the HA? do both have the same configs? -Avi
On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga <
tculjaga@gmail.com>
wrote: > Here is the debug: http://pastebin.freeswitch.org/15133 > > i have set verbose_sdp=true in vars.xml as. > <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/> > > but not much to be seen of the verbose thing in the debug... > > Still, FS is sending a re-INVITE with wrong SDP. The call to be > recovered is > using ALAW... and ULAW is not supported. > FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected > due > to incompatible SDP. > > Where does FS get the information for the SDP in re-INVITE message? > > > please advice, > T. > > > > On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga < tculjaga@gmail.com> > wrote: >> >> yap, i do have PCMA ... and the debug shows it correctly :=) >> >> i will try to see what it does with verbose. Post new debug tomorrow. >> >> ty. >> >> >> On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre < steveayre@gmail.com> >> wrote: >>> >>> Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA? >>> >>> Steve on iPhone >>> >>> On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote: >>> >>> > What makes you think that fails? It has ULAW and CN in the codec >>> > list! >>> > Sounds like you need the verbose sdp... set the global variable >>> > "verbose_sdp=true" >>> > >>> > /b >>> > >>> > On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote: >>> > >>> >> >>> >> >>> >> i configured FS HA and looks like its trying to recover the call .. >>> >> but the re-INVITE fails due to "wrong/missed" codec capability. >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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 > >
_______________________________________________ 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
_______________________________________________ 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
-- 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
Tihomir,
Are you saying all of those are implemented in mod_xml_cdr?
If so, that's probably not the best place to implement them. They'd be better off in their own separate modules.
well, i have tested it with the original module ... don't wary about that :=) ... I always use default modules if i have issues to see the behaviour.
There's no reason it should work in a default module if it wouldn't work in its own.
- added radius accounting interface
There's already a module for this I believe? http://wiki.freeswitch.org/wiki/Mod_radius_cdr
sorry to say that and pls don't get me wrong, but its not good ... and doesn't support adding custom VSAs (something as in mod_rad_auth).
Fair enough. If you think it can be improved post jira tickets requesting new features and possibly supplying patches to improve it.
- not the best place but
I don't agree with you here, mod_xml_cdr has already two interfaces (curl and fs) .. why not add radius and odbc as well ?
curl and fs are writing the same generated XML cdr content. The fs support is there partly to give the ability to store CDRs when the HTTP request fails so they can be resent later. Radius and ODBC on the otherhand aren't XML, so it's an entirely different type of CDR. (Well, ODBC could be but it's probably not the best way to store it). -Steve On 26 January 2011 18:12, Tihomir Culjaga <tculjaga@gmail.com> wrote:
On Wed, Jan 26, 2011 at 4:34 PM, Steven Ayre <steveayre@gmail.com> wrote:
Tihomir,
Are you saying all of those are implemented in mod_xml_cdr?
If so, that's probably not the best place to implement them. They'd be better off in their own separate modules.
well, i have tested it with the original module ... don't wary about that :=) ... I always use default modules if i have issues to see the behaviour.
- added radius accounting interface
There's already a module for this I believe? http://wiki.freeswitch.org/wiki/Mod_radius_cdr
sorry to say that and pls don't get me wrong, but its not good ... and doesn't support adding custom VSAs (something as in mod_rad_auth).
- added odbc cdr interface
This would be better in its own module.
- not the best place but
I don't agree with you here, mod_xml_cdr has already two interfaces (curl and fs) .. why not add radius and odbc as well ?
Of course i can move all of that in separate modules ... but why.. i look at that as additional interfaces where i can send the CDR.
LCR stuff is on the roadmap already... and i agree its has no place here.
added a function to build up my dial-string... basically the same
functionality of LCR module but much more simpler :=)
Indeed it's not, I don't see how CDRs and LCR is related. This would be better as something like mod_custom_lcr. mod_lcr may well do what you need though with custom SQL.
Warm Regards, -Steve
On 26 January 2011 14:03, Tihomir Culjaga <tculjaga@gmail.com> wrote:
patch for mod_xml_cdr
- added radius accounting interface - added odbc cdr interface
- not the best place but added a function to build up my dial-string... basically the same functionality of LCR module but much more simpler :=)
On 26 January 2011 13:28, Steven Ayre <steveayre@gmail.com> wrote:
It shouldn't be hard to update them. Most interfaces haven't changed, and those that have won't have changed much. Any changes will show up as compile-time errors. If you wrote them in the first place then you'll be easily capable of updating them for the latest version.
If you have any patches that you think would be beneficial for the entire community you can share them on http://jira.freeswitch.org, then they'll get considered for adding to the trunk - what's the patch for?
Patches to trunk modules will always be easier for you to maintain if you can get them into trunk.
-Steve
On 26 January 2011 10:53, Tihomir Culjaga <tculjaga@gmail.com> wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
On Wed, Jan 26, 2011 at 1:12 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
There is an xml_cdr snapshot in sip_recovery sql table that contains the data used for the recovery. Also based on your logs, you are not using latest git. I would try that first before anything else.
On Tue, Jan 25, 2011 at 7:24 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, both using the same config
can you advice where is FS getting the SDP info for the re-INVITE ?
On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote: > > Are you using two machines for the HA? do both have the same configs? > -Avi > > On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga < tculjaga@gmail.com> > wrote: > > Here is the debug: http://pastebin.freeswitch.org/15133 > > > > i have set verbose_sdp=true in vars.xml as. > > <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/> > > > > but not much to be seen of the verbose thing in the debug... > > > > Still, FS is sending a re-INVITE with wrong SDP. The call to be > > recovered is > > using ALAW... and ULAW is not supported. > > FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected > > due > > to incompatible SDP. > > > > Where does FS get the information for the SDP in re-INVITE message? > > > > > > please advice, > > T. > > > > > > > > On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga < tculjaga@gmail.com> > > wrote: > >> > >> yap, i do have PCMA ... and the debug shows it correctly :=) > >> > >> i will try to see what it does with verbose. Post new debug tomorrow. > >> > >> ty. > >> > >> > >> On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre < steveayre@gmail.com> > >> wrote: > >>> > >>> Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA? > >>> > >>> Steve on iPhone > >>> > >>> On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote: > >>> > >>> > What makes you think that fails? It has ULAW and CN in the codec > >>> > list! > >>> > Sounds like you need the verbose sdp... set the global variable > >>> > "verbose_sdp=true" > >>> > > >>> > /b > >>> > > >>> > On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote: > >>> > > >>> >> > >>> >> > >>> >> i configured FS HA and looks like its trying to recover the call .. > >>> >> but the re-INVITE fails due to "wrong/missed" codec capability. > >>> > > >>> > > >>> > _______________________________________________ > >>> > 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 > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > 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
_______________________________________________ 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
-- 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<MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org<sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
points taken :=) just updated to latest git, included the mod_xml_cdr modifications and i can recover the calls now. Thanks for your help. anyhow, im going to move the functionalities to appropriate modules instead. On Wed, Jan 26, 2011 at 8:20 PM, Steven Ayre <steveayre@gmail.com> wrote:
Tihomir,
Are you saying all of those are implemented in mod_xml_cdr?
If so, that's probably not the best place to implement them. They'd be better off in their own separate modules.
well, i have tested it with the original module ... don't wary about that :=) ... I always use default modules if i have issues to see the behaviour.
There's no reason it should work in a default module if it wouldn't work in its own.
- added radius accounting interface
There's already a module for this I believe? http://wiki.freeswitch.org/wiki/Mod_radius_cdr
sorry to say that and pls don't get me wrong, but its not good ... and doesn't support adding custom VSAs (something as in mod_rad_auth).
Fair enough. If you think it can be improved post jira tickets requesting new features and possibly supplying patches to improve it.
- not the best place but
I don't agree with you here, mod_xml_cdr has already two interfaces (curl and fs) .. why not add radius and odbc as well ?
curl and fs are writing the same generated XML cdr content. The fs support is there partly to give the ability to store CDRs when the HTTP request fails so they can be resent later. Radius and ODBC on the otherhand aren't XML, so it's an entirely different type of CDR. (Well, ODBC could be but it's probably not the best way to store it).
-Steve
On 26 January 2011 18:12, Tihomir Culjaga <tculjaga@gmail.com> wrote:
On Wed, Jan 26, 2011 at 4:34 PM, Steven Ayre <steveayre@gmail.com> wrote:
Tihomir,
Are you saying all of those are implemented in mod_xml_cdr?
If so, that's probably not the best place to implement them. They'd be better off in their own separate modules.
well, i have tested it with the original module ... don't wary about that :=) ... I always use default modules if i have issues to see the behaviour.
- added radius accounting interface
There's already a module for this I believe? http://wiki.freeswitch.org/wiki/Mod_radius_cdr
sorry to say that and pls don't get me wrong, but its not good ... and doesn't support adding custom VSAs (something as in mod_rad_auth).
- added odbc cdr interface
This would be better in its own module.
- not the best place but
I don't agree with you here, mod_xml_cdr has already two interfaces (curl and fs) .. why not add radius and odbc as well ?
Of course i can move all of that in separate modules ... but why.. i look at that as additional interfaces where i can send the CDR.
LCR stuff is on the roadmap already... and i agree its has no place here.
added a function to build up my dial-string... basically the same
functionality of LCR module but much more simpler :=)
Indeed it's not, I don't see how CDRs and LCR is related. This would be better as something like mod_custom_lcr. mod_lcr may well do what you need though with custom SQL.
Warm Regards, -Steve
On 26 January 2011 14:03, Tihomir Culjaga <tculjaga@gmail.com> wrote:
patch for mod_xml_cdr
- added radius accounting interface - added odbc cdr interface
- not the best place but added a function to build up my dial-string... basically the same functionality of LCR module but much more simpler :=)
On 26 January 2011 13:28, Steven Ayre <steveayre@gmail.com> wrote:
It shouldn't be hard to update them. Most interfaces haven't changed, and those that have won't have changed much. Any changes will show up as compile-time errors. If you wrote them in the first place then you'll be easily capable of updating them for the latest version.
If you have any patches that you think would be beneficial for the entire community you can share them on http://jira.freeswitch.org, then they'll get considered for adding to the trunk - what's the patch for?
Patches to trunk modules will always be easier for you to maintain if you can get them into trunk.
-Steve
On 26 January 2011 10:53, Tihomir Culjaga <tculjaga@gmail.com> wrote:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
On Wed, Jan 26, 2011 at 1:12 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
There is an xml_cdr snapshot in sip_recovery sql table that contains the data used for the recovery. Also based on your logs, you are not using latest git. I would try that first before anything else.
On Tue, Jan 25, 2011 at 7:24 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote: > yap, both using the same config > > > can you advice where is FS getting the SDP info for the re-INVITE ? > > > On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote: >> >> Are you using two machines for the HA? do both have the same configs? >> -Avi >> >> On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga < tculjaga@gmail.com> >> wrote: >> > Here is the debug: http://pastebin.freeswitch.org/15133 >> > >> > i have set verbose_sdp=true in vars.xml as. >> > <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/> >> > >> > but not much to be seen of the verbose thing in the debug... >> > >> > Still, FS is sending a re-INVITE with wrong SDP. The call to be >> > recovered is >> > using ALAW... and ULAW is not supported. >> > FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected >> > due >> > to incompatible SDP. >> > >> > Where does FS get the information for the SDP in re-INVITE message? >> > >> > >> > please advice, >> > T. >> > >> > >> > >> > On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga < tculjaga@gmail.com> >> > wrote: >> >> >> >> yap, i do have PCMA ... and the debug shows it correctly :=) >> >> >> >> i will try to see what it does with verbose. Post new debug tomorrow. >> >> >> >> ty. >> >> >> >> >> >> On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre < steveayre@gmail.com> >> >> wrote: >> >>> >> >>> Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA? >> >>> >> >>> Steve on iPhone >> >>> >> >>> On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote: >> >>> >> >>> > What makes you think that fails? It has ULAW and CN in the codec >> >>> > list! >> >>> > Sounds like you need the verbose sdp... set the global variable >> >>> > "verbose_sdp=true" >> >>> > >> >>> > /b >> >>> > >> >>> > On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote: >> >>> > >> >>> >> >> >>> >> >> >>> >> i configured FS HA and looks like its trying to recover the call .. >> >>> >> but the re-INVITE fails due to "wrong/missed" codec capability. >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > 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 >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> > >> > _______________________________________________ >> > 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 >> > >> > >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 > >
-- 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<MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org<sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
Am 26.01.2011 um 11:53 schrieb Tihomir Culjaga:
hello Anthony,
ya, i was afraid of that... this means moving all my modules & patches to the latest git...
radius cdr interface
What about the one thats in tree ?
odbc cdr interface
within mod_xml_cdr <= i can share this as a patch... if you are interested.
mod_say_hr - really bad programming .. needs big re-factoring but lack of time :( patches for mod_say_de & mod_say_fr - because wrong playing in some scenarios
sent me those I will work them in.
and some small stuff i made within mod_commands... anyhow this was on the road.
anyhow i was really into understanding the way the call context replication works... this may be the DB connection issue as the ODBC connection is reset on switchover (im switching entire resource .. floating IP, & database)
so what really happens is the FS on 2nd node just getting sessions from sip_recovery
from sofia_glue_recover: i see you are selecting sip_recovery table.
select * from sip_recovery; runtime_uuid profile_name hostname uuid metadata 24f77a1f-f315-4beb-904f-f779e8767c75 internal cxss01 102b2c7f-466f-4b6d-a795-e2cc25630e78 24f77a1f-f315-4beb-904f-f779e8767c75 external cxss01 52834d99-c1be-4832-bee9-7ba05238871d
so, what do you do afterward?
on the recovering node i see some portion of dialplan is executed and re-INVITEs being sent ... where do you get the DSP info for the recovering re-INVITE ?
thanks for your help, Tihomir.
On Wed, Jan 26, 2011 at 1:12 AM, Anthony Minessale <anthony.minessale@gmail.com> wrote: There is an xml_cdr snapshot in sip_recovery sql table that contains the data used for the recovery. Also based on your logs, you are not using latest git. I would try that first before anything else.
On Tue, Jan 25, 2011 at 7:24 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, both using the same config
can you advice where is FS getting the SDP info for the re-INVITE ?
On Tue, Jan 25, 2011 at 2:03 PM, Avi Marcus <avi@avimarcus.net> wrote:
Are you using two machines for the HA? do both have the same configs? -Avi
On Tue, Jan 25, 2011 at 11:41 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Here is the debug: http://pastebin.freeswitch.org/15133
i have set verbose_sdp=true in vars.xml as. <X-PRE-PROCESS cmd="set" data="verbose_sdp=true"/>
but not much to be seen of the verbose thing in the debug...
Still, FS is sending a re-INVITE with wrong SDP. The call to be recovered is using ALAW... and ULAW is not supported. FS sends a re-INVITE with ULAW and CN in SDP. The re-INVITE is rejected due to incompatible SDP.
Where does FS get the information for the SDP in re-INVITE message?
please advice, T.
On Tue, Jan 25, 2011 at 12:01 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:
yap, i do have PCMA ... and the debug shows it correctly :=)
i will try to see what it does with verbose. Post new debug tomorrow.
ty.
On Mon, Jan 24, 2011 at 11:29 PM, Steven Ayre <steveayre@gmail.com> wrote:
Brian, it has PCMU in the sdp, but Sofia thinks it's setting PCMA?
Steve on iPhone
On 24 Jan 2011, at 20:17, Brian West <brian@freeswitch.org> wrote:
> What makes you think that fails? It has ULAW and CN in the codec > list! > Sounds like you need the verbose sdp... set the global variable > "verbose_sdp=true" > > /b > > On Jan 24, 2011, at 1:50 PM, Tihomir Culjaga wrote: > >> >> >> i configured FS HA and looks like its trying to recover the call .. >> but the re-INVITE fails due to "wrong/missed" codec capability. > > > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- 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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ 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
_______________________________________________ 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
Michal Bielicki Geschäftsführer / CEO Seventh Signal Ltd. & Co. KG Weigandufer 45, Büro 115, D-12059 Berlin Voice: +49 30 60988730 Amtsgericht Charlottenburg HRA 44413 B Ust.-ID: DE266981999 Geschäftsführer: Michal Bielicki Persönlich Haftende Gesellschafterin: Seventh Signal Ltd, 69 Great Hampton St. Birmingham, B18 6EW, GB, Company Nr.: 06889439 WWW.: http://www.seventhsignal.de
participants (7)
-
Anthony Minessale
-
Avi Marcus
-
Brian West
-
Michal Bielicki
-
Serge S. Yuriev
-
Steven Ayre
-
Tihomir Culjaga