T.38 with Re-INVITE question
I was testing T.38 with Re-INVITE. Call Flow: Inbound Carrier (1.2.3.4) -> FS (Bypass Media) -> Outbound Carrier that will send T.38 Re-INVITE (6.7.8.9). However, I noticed that FS generated 2 CDRs for the same call, which are: 1) A-leg CDR from inbound carrier, and also 2) A-leg CDR from outbound carrier that send T.38 Re-INVITE. I am wondering whether this is a normal behavior, or there is a way to ignore the 2nd CDR? Example of 2 FS CDRs below: 1 : caller_id_name = +16193301897 2 : caller_id_number = +16193301897 3 : aniii = 0 4 : destination_number = +12133456789 5 : context = routing 6 : start_stamp = 2012-09-13 21:12:13 7 : answer_stamp = 2012-09-13 21:12:13 8 : end_stamp = 2012-09-13 21:14:06 9 : duration = 113 10: billsec = 113 11: hangup_cause = NORMAL_CLEARING 12: channel_name = sofia/fs/+16193301897@1.2.3.4:5060 13: bridge_channel = 14: network_addr = 1.2.3.4 15: remote_ip_last_arg = sofia/fs/2133456789@6.7.8.9 16: bleg_network_addr = 6.7.8.9 17: sip_hangup_disposition = recv_bye 18: endpoint_disposition = ANSWER ***************************************** 1 : caller_id_name = 2133456789 2 : caller_id_number = 2133456789 3 : aniii = 4 : destination_number = mod_sofia 5 : context = routing 6 : start_stamp = 2012-09-13 21:12:13 7 : answer_stamp = 2012-09-13 21:12:13 8 : end_stamp = 2012-09-13 21:14:06 9 : duration = 113 10: billsec = 113 11: hangup_cause = NORMAL_CLEARING 12: channel_name = sofia/fs/2133456789@6.7.8.9 13: bridge_channel = 14: network_addr = 6.7.8.9 15: remote_ip_last_arg = 16: bleg_network_addr = 17: sip_hangup_disposition = send_bye 18: endpoint_disposition = INBOUND CALL Thank you.
On Thu, Sep 13, 2012 at 5:07 PM, DJB International <djbinter@gmail.com> wrote:
I was testing T.38 with Re-INVITE.
Call Flow: Inbound Carrier (1.2.3.4) -> FS (Bypass Media) -> Outbound Carrier that will send T.38 Re-INVITE (6.7.8.9).
However, I noticed that FS generated 2 CDRs for the same call, which are: 1) A-leg CDR from inbound carrier, and also 2) A-leg CDR from outbound carrier that send T.38 Re-INVITE.
I am wondering whether this is a normal behavior, or there is a way to ignore the 2nd CDR?
Does this help? process_cdr <-- indicates how to process CDR records. http://wiki.freeswitch.org/wiki/Channel_Variables#process_cdr Good luck. Gabe
Thank you for your suggestion; however, as mentioned, both CDRs are a-leg and related to only the T.38 re-INVITE call behavior only. Sent from my iPad On Sep 14, 2012, at 2:38 AM, Gabriel Gunderson <gabe@gundy.org> wrote:
On Thu, Sep 13, 2012 at 5:07 PM, DJB International <djbinter@gmail.com> wrote:
I was testing T.38 with Re-INVITE.
Call Flow: Inbound Carrier (1.2.3.4) -> FS (Bypass Media) -> Outbound Carrier that will send T.38 Re-INVITE (6.7.8.9).
However, I noticed that FS generated 2 CDRs for the same call, which are: 1) A-leg CDR from inbound carrier, and also 2) A-leg CDR from outbound carrier that send T.38 Re-INVITE.
I am wondering whether this is a normal behavior, or there is a way to ignore the 2nd CDR?
Does this help?
process_cdr <-- indicates how to process CDR records.
http://wiki.freeswitch.org/wiki/Channel_Variables#process_cdr
Good luck.
Gabe
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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 Fri, Sep 14, 2012 at 9:32 AM, Dorn DJBinter <djbinter@gmail.com> wrote:
Thank you for your suggestion; however, as mentioned, both CDRs are a-leg and related to only the T.38 re-INVITE call behavior only.
I should have seen that; it rather *was* late when I read it :) As far as I know, you're going to have to insert a variable based on your logic to tell FreeSWITCH that it should or shouldn't log. Sorry I wasn't more helpful. Gabe
Thank you. I've already opened Jira for a bug report since it only happens on latest git, but not on older version. -djbinter On Fri, Sep 14, 2012 at 2:33 PM, Gabriel Gunderson <gabe@gundy.org> wrote:
On Fri, Sep 14, 2012 at 9:32 AM, Dorn DJBinter <djbinter@gmail.com> wrote:
Thank you for your suggestion; however, as mentioned, both CDRs are a-leg and related to only the T.38 re-INVITE call behavior only.
I should have seen that; it rather *was* late when I read it :)
As far as I know, you're going to have to insert a variable based on your logic to tell FreeSWITCH that it should or shouldn't log.
Sorry I wasn't more helpful.
Gabe
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
participants (3)
-
DJB International
-
Dorn DJBinter
-
Gabriel Gunderson