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.