Hi, My initial motivation for trying out Freeswitch is to see if the transfer CDRs are correct. A seemingly small thing but one that has literally cost my business thousands of Euro due to Asterisk not creating them properly. I'm in the process of trying out FreeSwitch but haven't got a call working yet (I'm doing it the hard way by building from source on Windows). In the meantime I was wondering if anyone else has verified whether CDRs are correctly produced for blind and attended transfers? Thanks, Greyman.
if you use mod_xml_cdr you will get 1 cdr report in it's own file per call. Each time the call is transferred it's documented and the call flow is expanded so you should be satisfied with it. On Mon, Jul 7, 2008 at 3:15 AM, Grey Man <greymanvoip@gmail.com> wrote:
Hi,
My initial motivation for trying out Freeswitch is to see if the transfer CDRs are correct. A seemingly small thing but one that has literally cost my business thousands of Euro due to Asterisk not creating them properly. I'm in the process of trying out FreeSwitch but haven't got a call working yet (I'm doing it the hard way by building from source on Windows). In the meantime I was wondering if anyone else has verified whether CDRs are correctly produced for blind and attended transfers?
Thanks,
Greyman.
_______________________________________________ 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/ 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> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
if you use mod_xml_cdr you will get 1 cdr report in it's own file per call.
Each time the call is transferred it's documented and the call flow is expanded so you should be satisfied with it.
Hi There, I was able to test transfer CDRs with freeswitch and encountered similar issues to those I've had with Asterisk (http://bugs.digium.com/view.php?id=11849). In Freeswitch's case the blind transfer CDR problem is the same as Asterisk's. If you call a billable destination through the server and then do a blind transfer (REFER) to another billable destination you get left with a call that has two billable legs but you will only get one CDR. With attended transfers Freeswitch generates a CDR for the first call leg when the transfer occurs and a CDR for the second call leg when the call ends except that the destination on the second call leg is incorrect and has been modified to be the callerid of the first caller. It should be generating the CDRs for both call legs when the call ends and not when the transfer occurs. I also got an extra CDR quite a while after the transferred call had hung up with a disposition of "RECOVERY_ON_TIMER_EXPIRE" with a destination corresponding to the second call leg. This whole transfer/CDR thing is very unsexy and a pain for developers but it's a critical thing for those of us that run businesses supplying telephony services. This one issue has cost the company I work for an amount into 4 figures. Regards, Greyman.
The way I did it (but still dont understand completely) was as follows: What I am trying to do is have a web based panel which can 'follow through' calls. Scenario A: 1. Caller Extension 200 (me) calls my cell phone 2. Cell phone picks up, we talk for 10 seconds 3. I call extension 603, talk for 5 seconds and do a attended transfer 4. 603 talks to my cell phone and hangs up after 15 seconds I get 3 results XML_CDR curl posts (or 3 files if not using curl): CDR for Step 1 & 2 - this is treated like a separate call and has its own CDR. I am assuming (please correct me if Im wrong): sip_call_id points to the uuid of the call leg between the phone and freeswitch uuid in callflow/0/caller_profile/uuid is the first channel that was bridged to this call- which is the leg of the call going from freeswitch to the sip_pstn_gateway CDR for Step 3: This has the endpoint_disposition set to ATTENDED_TRANSFER. This is treated as a brand new call (which is correct). it has a different sip_call_id and a different callflow/0/caller_profile/uuid CDR for Step 4: This is generated after 603 hangs up. This is where I am confused. The sip_call_id is brand new (shouldn't it be the same as the uuid in Step 1? isn't this the same call?) This call has two callflows: callflow/0/caller_profile/uuid = uuid found in step 1 callflow/1/caller_profile_uuid = uuid found in step 2 questions: 1. What exactly does callflow mean? My understand is that its the channels that have been bridged to THIS channel (in order) 2. In the Last CDR thats generated, what do the "times" part of the tree contain? What time is freeswitch exactly calculating and how is it different from the time_stamps in the 'variables' part of the tree? I can contribute back a decently slick CDR panel and mysql DB if somebody can help me understand the XML output! :) Grey Man wrote:
On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
if you use mod_xml_cdr you will get 1 cdr report in it's own file per call.
Each time the call is transferred it's documented and the call flow is expanded so you should be satisfied with it.
Hi There,
I was able to test transfer CDRs with freeswitch and encountered similar issues to those I've had with Asterisk (http://bugs.digium.com/view.php?id=11849).
In Freeswitch's case the blind transfer CDR problem is the same as Asterisk's. If you call a billable destination through the server and then do a blind transfer (REFER) to another billable destination you get left with a call that has two billable legs but you will only get one CDR.
With attended transfers Freeswitch generates a CDR for the first call leg when the transfer occurs and a CDR for the second call leg when the call ends except that the destination on the second call leg is incorrect and has been modified to be the callerid of the first caller. It should be generating the CDRs for both call legs when the call ends and not when the transfer occurs. I also got an extra CDR quite a while after the transferred call had hung up with a disposition of "RECOVERY_ON_TIMER_EXPIRE" with a destination corresponding to the second call leg.
This whole transfer/CDR thing is very unsexy and a pain for developers but it's a critical thing for those of us that run businesses supplying telephony services. This one issue has cost the company I work for an amount into 4 figures.
Regards,
Greyman.
_______________________________________________ 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
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
Sorry for the multiple posts but I am just trying to provide as much information so that somebody can shed light on it: Problem scenario: 1. Inbound call from PSTN to IVR (9999) 2. caller dials 200 and gets to my extension 3. I do a Attended transfer to 204 4. 204 talks and hangs up. for this i only get TWO cdrs: 1. First CDR is the call i made to 204 and ends with ATTENDED_TRANSFER 2. The last CDR has the actual inbound PSTN call. However, this time callflow/0/call_profile/uuid links to a uuid which was NEVER logged by the CDR. I am guessing this was the UUID of the inbound PSTN call. What ends up happening is that I have two calls without a method of establishing a relationship with the earlier calls- since the first uuid mentioned in the callflow was never logged. If my understanding of the 'callflow' tree is completely flawed can someone point me in the right direction? I would love to have this call tracing feature!
Grey Man wrote:
On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
if you use mod_xml_cdr you will get 1 cdr report in it's own file per call.
Each time the call is transferred it's documented and the call flow is expanded so you should be satisfied with it.
Hi There,
I was able to test transfer CDRs with freeswitch and encountered similar issues to those I've had with Asterisk (http://bugs.digium.com/view.php?id=11849).
In Freeswitch's case the blind transfer CDR problem is the same as Asterisk's. If you call a billable destination through the server and then do a blind transfer (REFER) to another billable destination you get left with a call that has two billable legs but you will only get one CDR.
With attended transfers Freeswitch generates a CDR for the first call leg when the transfer occurs and a CDR for the second call leg when the call ends except that the destination on the second call leg is incorrect and has been modified to be the callerid of the first caller. It should be generating the CDRs for both call legs when the call ends and not when the transfer occurs. I also got an extra CDR quite a while after the transferred call had hung up with a disposition of "RECOVERY_ON_TIMER_EXPIRE" with a destination corresponding to the second call leg.
This whole transfer/CDR thing is very unsexy and a pain for developers but it's a critical thing for those of us that run businesses supplying telephony services. This one issue has cost the company I work for an amount into 4 figures.
Regards,
Greyman.
_______________________________________________ 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
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
Try enabling b legs in the xml_cdr <param name="log-b-leg" value="true"/> On Wed, Jul 9, 2008 at 9:35 AM, Faraz R. Khan <faraz.khan@emergen.biz> wrote:
Sorry for the multiple posts but I am just trying to provide as much information so that somebody can shed light on it:
Problem scenario:
1. Inbound call from PSTN to IVR (9999) 2. caller dials 200 and gets to my extension 3. I do a Attended transfer to 204 4. 204 talks and hangs up.
for this i only get TWO cdrs:
1. First CDR is the call i made to 204 and ends with ATTENDED_TRANSFER 2. The last CDR has the actual inbound PSTN call. However, this time callflow/0/call_profile/uuid links to a uuid which was NEVER logged by the CDR. I am guessing this was the UUID of the inbound PSTN call.
What ends up happening is that I have two calls without a method of establishing a relationship with the earlier calls- since the first uuid mentioned in the callflow was never logged.
If my understanding of the 'callflow' tree is completely flawed can someone point me in the right direction? I would love to have this call tracing feature!
Grey Man wrote:
On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
if you use mod_xml_cdr you will get 1 cdr report in it's own file per call.
Each time the call is transferred it's documented and the call flow is expanded so you should be satisfied with it.
Hi There,
I was able to test transfer CDRs with freeswitch and encountered similar issues to those I've had with Asterisk (http://bugs.digium.com/view.php?id=11849).
In Freeswitch's case the blind transfer CDR problem is the same as Asterisk's. If you call a billable destination through the server and then do a blind transfer (REFER) to another billable destination you get left with a call that has two billable legs but you will only get one CDR.
With attended transfers Freeswitch generates a CDR for the first call leg when the transfer occurs and a CDR for the second call leg when the call ends except that the destination on the second call leg is incorrect and has been modified to be the callerid of the first caller. It should be generating the CDRs for both call legs when the call ends and not when the transfer occurs. I also got an extra CDR quite a while after the transferred call had hung up with a disposition of "RECOVERY_ON_TIMER_EXPIRE" with a destination corresponding to the second call leg.
This whole transfer/CDR thing is very unsexy and a pain for developers but it's a critical thing for those of us that run businesses supplying telephony services. This one issue has cost the company I work for an amount into 4 figures.
Regards,
Greyman.
_______________________________________________ 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
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
_______________________________________________ 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/ 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> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Amazing! Why didnt I see that? :) Beautiful CDRs in my mysql DB. Simplistic call panel with call tracing coming up in a few days! Might want to enable that by default to auto-impress new comers! Anthony Minessale wrote:
Try enabling b legs in the xml_cdr
<param name="log-b-leg" value="true"/>
On Wed, Jul 9, 2008 at 9:35 AM, Faraz R. Khan <faraz.khan@emergen.biz <mailto:faraz.khan@emergen.biz>> wrote:
Sorry for the multiple posts but I am just trying to provide as much information so that somebody can shed light on it:
Problem scenario:
1. Inbound call from PSTN to IVR (9999) 2. caller dials 200 and gets to my extension 3. I do a Attended transfer to 204 4. 204 talks and hangs up.
for this i only get TWO cdrs:
1. First CDR is the call i made to 204 and ends with ATTENDED_TRANSFER 2. The last CDR has the actual inbound PSTN call. However, this time callflow/0/call_profile/uuid links to a uuid which was NEVER logged by the CDR. I am guessing this was the UUID of the inbound PSTN call.
What ends up happening is that I have two calls without a method of establishing a relationship with the earlier calls- since the first uuid mentioned in the callflow was never logged.
If my understanding of the 'callflow' tree is completely flawed can someone point me in the right direction? I would love to have this call tracing feature!
> Grey Man wrote: >> On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale >> <anthony.minessale@gmail.com <mailto:anthony.minessale@gmail.com>> wrote: >>> if you use mod_xml_cdr you will get 1 cdr report in it's own file per call. >>> >>> Each time the call is transferred it's documented and the call flow is >>> expanded so you should be satisfied with it. >>> >> Hi There, >> >> I was able to test transfer CDRs with freeswitch and encountered >> similar issues to those I've had with Asterisk >> (http://bugs.digium.com/view.php?id=11849). >> >> In Freeswitch's case the blind transfer CDR problem is the same as >> Asterisk's. If you call a billable destination through the server and >> then do a blind transfer (REFER) to another billable destination you >> get left with a call that has two billable legs but you will only get >> one CDR. >> >> With attended transfers Freeswitch generates a CDR for the first call >> leg when the transfer occurs and a CDR for the second call leg when >> the call ends except that the destination on the second call leg is >> incorrect and has been modified to be the callerid of the first >> caller. It should be generating the CDRs for both call legs when the >> call ends and not when the transfer occurs. I also got an extra CDR >> quite a while after the transferred call had hung up with a >> disposition of "RECOVERY_ON_TIMER_EXPIRE" with a destination >> corresponding to the second call leg. >> >> This whole transfer/CDR thing is very unsexy and a pain for developers >> but it's a critical thing for those of us that run businesses >> supplying telephony services. This one issue has cost the company I >> work for an amount into 4 figures. >> >> Regards, >> >> Greyman. >> >> _______________________________________________ >> Freeswitch-users mailing list >> Freeswitch-users@lists.freeswitch.org <mailto: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 >> >
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz <http://www.emergen.biz>
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto: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/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ 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
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
Hi all, As part of my initial tests I set two Xlite in the network and I can make internal calls. Then I set line 2 (line 1 is configured with another provider) of a SPA941 . The line register normally but when I try to call it I get user busy. 2008-07-09 07:56:42 [NOTICE] sofia.c:2085 sofia_handle_sip_i_state() Hangup sofia/internal/1002@192.168.0.112:5060 [CS_CONSUME_MEDIA] [USER_BUSY] 2008-07-09 07:56:42 [ERR] switch_ivr_originate.c:823 switch_ivr_originate() Cannot create outgoing channel of type [user] cause: [USER_BUSY] 2008-07-09 07:56:42 [INFO] mod_dptools.c:1797 audio_bridge_function() Originate Failed. Cause: USER_BUSY Any ideas ? Thanks Jair Santos
If it's a registered user its sofia/internal/1002%192.168.0.112 /b On Jul 9, 2008, at 10:09 AM, Jair Santos wrote:
Hi all,
As part of my initial tests I set two Xlite in the network and I can make internal calls.
Then I set line 2 (line 1 is configured with another provider) of a SPA941 . The line register normally but when I try to call it I get user busy.
2008-07-09 07:56:42 [NOTICE] sofia.c:2085 sofia_handle_sip_i_state() Hangup sofia/internal/1002@192.168.0.112:5060 [CS_CONSUME_MEDIA] [USER_BUSY] 2008-07-09 07:56:42 [ERR] switch_ivr_originate.c:823 switch_ivr_originate() Cannot create outgoing channel of type [user] cause: [USER_BUSY] 2008-07-09 07:56:42 [INFO] mod_dptools.c:1797 audio_bridge_function() Originate Failed. Cause: USER_BUSY
Any ideas ?
Thanks
Jair Santos
_______________________________________________ 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
Brian West sip:brian@freeswitch.org
Doh... I replied too soon... ignore my previous email. Can you tell me if both phones are registered? sofia status profile internal /b On Jul 9, 2008, at 10:09 AM, Jair Santos wrote:
Hi all,
As part of my initial tests I set two Xlite in the network and I can make internal calls.
Then I set line 2 (line 1 is configured with another provider) of a SPA941 . The line register normally but when I try to call it I get user busy.
2008-07-09 07:56:42 [NOTICE] sofia.c:2085 sofia_handle_sip_i_state() Hangup sofia/internal/1002@192.168.0.112:5060 [CS_CONSUME_MEDIA] [USER_BUSY] 2008-07-09 07:56:42 [ERR] switch_ivr_originate.c:823 switch_ivr_originate() Cannot create outgoing channel of type [user] cause: [USER_BUSY] 2008-07-09 07:56:42 [INFO] mod_dptools.c:1797 audio_bridge_function() Originate Failed. Cause: USER_BUSY
Any ideas ?
Thanks
Jair Santos
_______________________________________________ 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
Brian West sip:brian@freeswitch.org
Yes they are properly registered. And by the way , the phone I am calling to is not busy :-) thanks Jair Santos
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: Wednesday, July 09, 2008 8:15 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] USER_BUSY
Doh... I replied too soon... ignore my previous email. Can you tell me if both phones are registered?
sofia status profile internal
/b
On Jul 9, 2008, at 10:09 AM, Jair Santos wrote:
Hi all,
As part of my initial tests I set two Xlite in the network and I can make internal calls.
Then I set line 2 (line 1 is configured with another provider) of a SPA941 . The line register normally but when I try to call it I get user busy.
2008-07-09 07:56:42 [NOTICE] sofia.c:2085 sofia_handle_sip_i_state() Hangup sofia/internal/1002@192.168.0.112:5060 [CS_CONSUME_MEDIA] [USER_BUSY] 2008-07-09 07:56:42 [ERR] switch_ivr_originate.c:823 switch_ivr_originate() Cannot create outgoing channel of type [user] cause: [USER_BUSY] 2008-07-09 07:56:42 [INFO] mod_dptools.c:1797 audio_bridge_function() Originate Failed. Cause: USER_BUSY
Any ideas ?
Thanks
Jair Santos
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freesw itch-users
Brian West sip:brian@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/freesw itch-users http://www.freeswitch.org
Grey, Are you using mod_xml_cdr? I get TWO cdrs for Blind transfers and THREE cdrs for attended transfers. If I call from 200 (my extension) to mobile and then transfer out to 204 (or any other extension) I will get: 1. CDR for the initial call to mobile with a disposition of BLIND_TRANSFER 2. continuing CDR with TWO call flows (which I dont understand completely) but what Im doing is LINKING the calls so that I can go through them. I am guessing we would need to run a billing routine to process these multiple CDRs and make sense out of them. But the data is there! mod_cdr_csv is from asterisk land- avoid at all costs :) Grey Man wrote:
On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
if you use mod_xml_cdr you will get 1 cdr report in it's own file per call.
Each time the call is transferred it's documented and the call flow is expanded so you should be satisfied with it.
Hi There,
I was able to test transfer CDRs with freeswitch and encountered similar issues to those I've had with Asterisk (http://bugs.digium.com/view.php?id=11849).
In Freeswitch's case the blind transfer CDR problem is the same as Asterisk's. If you call a billable destination through the server and then do a blind transfer (REFER) to another billable destination you get left with a call that has two billable legs but you will only get one CDR.
With attended transfers Freeswitch generates a CDR for the first call leg when the transfer occurs and a CDR for the second call leg when the call ends except that the destination on the second call leg is incorrect and has been modified to be the callerid of the first caller. It should be generating the CDRs for both call legs when the call ends and not when the transfer occurs. I also got an extra CDR quite a while after the transferred call had hung up with a disposition of "RECOVERY_ON_TIMER_EXPIRE" with a destination corresponding to the second call leg.
This whole transfer/CDR thing is very unsexy and a pain for developers but it's a critical thing for those of us that run businesses supplying telephony services. This one issue has cost the company I work for an amount into 4 figures.
Regards,
Greyman.
_______________________________________________ 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
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
Let me clarify this: You have to choices of CDR modules. mod_cdr_csv mod_xml_cdr cdr_csv is a template based module that was designed for back compat with the asterisk cdr format. see config file conf/autoload_configs/cdr_csv.conf.xml Here is the asterisk template that makes it possible for us to emulate asterisk it expands variables at the time the call ends. <template name="asterisk">"${accountcode}","${caller_id_number}","${destination_number}","${context}","${caller_id}","${channel_name}","${bridge_channel}"," ${last_app}","${last_arg}","${start_stamp}","${answer_stamp}","${end_stamp}","${duration}","${billsec}","${hangup_cause}","${amaflags}","${uuid}","${userfield}" </template> The default behavior is to log A legs meaning if you make an inbound call then the record will be generated when that leg goes away. This is why you see what you see, we are trying to emulate asterisk here for backward compat. The param you want to look at is the legs param. This controls what legs are logged. you can set it to a, b or ab to log a b or both legs. <!-- may be a b or ab --> <param name="legs" value="a"/> if you set it to b, then you will get logs every time a leg that was dialed via an existing leg hangs up. which will give you a new one every time a call is transfered. Next comes mod_xml_cdr which is the more robust choice for important call details. conf/autoload_configs/xml_cdr.conf.xml This module creates a single XML file per call leg with full detail of everything that happens including the time of each transfer etc. It always logs a legs but allows an option to also log b legs too: <param name="log-b-leg" value="true"/> In the XML report the <callflow> represents a single trip to the dialplan. Every time a channel is transferred, a whole new callflow will be stacked into the xml so by the end you have a full path of every single thing that happened in the call. See this url for an example of the xml_cdr reports. http://www.freeswitch.org/eg/xml_cdr/ On Wed, Jul 9, 2008 at 8:53 AM, Brian West <brian@freeswitch.org> wrote:
It can log a and b legs. Unlike Asterisk.
On Jul 9, 2008, at 8:39 AM, Faraz R. Khan wrote:
mod_cdr_csv is from asterisk land- avoid at all costs :)
Brian West sip:brian@freeswitch.org <sip%3Abrian@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/ 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> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
participants (5)
-
Anthony Minessale
-
Brian West
-
Faraz R. Khan
-
Grey Man
-
Jair Santos