[cisco-voip] Conference call CDR analysis

[dev]

Thanks Wes for your alert and notes.
Well, is the service parameter you indicated is the reason why the remaining
two PSTN numbers get connected/joined after the conference controller hangs
up?
 
Thanks
dev

  _____  

From: Wes Sisk [mailto:wsisk at cisco.com] 
Sent: Monday, 11 October 2010 8:12 PM
To: dev
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Conference call CDR analysis


one note - be careful about posting full e.164 phone numbers for your
employees or customers.  this creates targets for spam calls just like
posting full email addresses.

on initial inspection I agree with your assertion.  It appears 8024 dialed 2
external numbers and conferenced the the 3(including themselves)
participants together.
8024 jointed the bridge at 13:34 and stayed on for 1 minute. That would have
them dropping at 13:35.
At 13:36 8024 placed another call to number ending 7777 and stayed on that
call for 18 minutes.  That call does not appear related to the conference
call.

Termination of the conference is determined by the CM service paramenter
"Drop Ad Hoc Conference".

/Wes


dev wrote: 

Hi CDR experts out there..
 
I highly appreciate your input on this.
 
I am trying to understand the call scenario that took place here. Can you
help clarify it for me. My assumption is that ext 8024 being the conference
controller here sets up a conference call between the two PSTN numbers then
hung up out of the conference after 1 minute. Then called the same PSTN
mobile number again. Am I correct?
 
If yes, my understanding is that if a conference is left with two parties
only, they get joined together. Why isn't it happening here?
 
I have attached the CDR for reference.. Thanks for helping
 
 
 

globalcallid_callid	 datetimeconnect 	callingpartynumber
finalcalledpartynumber	 duration	 Lastredirectdn
,origlegcallidentifier	 ,destlegidentifier,	 joinonbehalfof
,origcallterminationonbehalfof	 ,destcallterminationonbehalfof	 comment

241980	 2010-09-05 13:33:12.000	 8024	 90101917777	 1
90101917777	 49364529	 49364530	 0	 4	 4

241983	 2010-09-05 13:33:59.000	 8024	 900962779260050	 0
900962779260050	 49364559	 49364560	 0	 4	 4

241980	 2010-09-05 13:34:40.000	 8024	 b00203202002	 1
8024	 49364529	 49364572	 4	 12	 0
ConfControllerDn=8024;ConfControllerDeviceName=SEP0004F2E66609;ConfRequestor
Dn=8024;ConfRequestorDeviceName=SEP0004F2E66609	
241980	 2010-09-05 13:34:40.000	 90101917777	 b00203202002	 20
8024	 49364530	 49364573	 4	 12	 4
ConfControllerDn=8024;ConfControllerDeviceName=SEP0004F2E66609;ConfRequestor
Dn=8024;ConfRequestorDeviceName=SEP0004F2E66609	
241980	 2010-09-05 13:34:40.000	 900962779260050
b00203202002	 20	 8024	 49364560	 49364574	 4	 12
0
ConfControllerDn=8024;ConfControllerDeviceName=SEP0004F2E66609;ConfRequestor
Dn=8024;ConfRequestorDeviceName=SEP0004F2E66609	
241989	 2010-09-05 13:36:38.000	 8024	 90101917777	 18
90101917777	 49364596	 49364597	 0	 12	 0



  _____  


_______________________________________________

cisco-voip mailing list

cisco-voip at puck.nether.net

https://puck.nether.net/mailman/listinfo/cisco-voip

  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101026/56dfd3a7/attachment.html>