[asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
Steve Murphy
murf at digium.com
Thu Jun 26 14:21:31 CDT 2008
On Wed, 2008-06-25 at 22:50 +0100, Grey Man wrote:
> On Tue, Jun 24, 2008 at 4:28 PM, Steve Murphy <murf at digium.com> wrote:
> > This is just a note that the fixes in the CDRfix4 and CDRfix6 branches
> > are getting closer to being merged into 1.4, trunk, and 1.6.x.
> >
> > If CDR's are important to you, and you ignore this notice, then
> > you deserve what you get!
> >
>
> Hi murf,
>
> >From some preliminary testing on the CDRfix4 branch it looks like the
> CDRs for attended transfers are now correct which is fantastic. For
> blind transfers the CDR for the first call leg is still incorrect with
> the duration only being recorded up until the point the transfer
> occurs.
>
I did a blind xfer with my snom360, and got these two cdrs with
**TRUNK**:
Eventlist:
1. 101 dahdi (used to be zap) phone picked up and 200 is dialed for the
snom360
2. 200 (snom360) picks up and answers the call
3. 200 (snom360) hits the Transfer button (101 gets MOH), dials 202
4. 200 (snom360) hits the checkmark button to send off the call
(101 starts hearing ringing, 200 starts getting congestion).
5. 202 (eyebeam) answers (101 & 202 are connected)
6. 101 or 202 hang up. Conversation finished.
""fxs.01"
<101>","101","200","extension","DAHDI/1-1","SIP/snom360-082c3f68","Dial","SIP/snom360,30","2008-06-26 11:04:08","2008-06-26 11:04:12","2008-06-26 11:05:56","108","104","ANSWERED","DOCUMENTATION","","1214499848.11","",""
""fxs.01"
<101>","101","201","extension","DAHDI/1-1","SIP/murf-eyebeam-082d95d8","Dial","SIP/polycom430&SIP/murf-eyebeam,30","2008-06-26 11:06:06","2008-06-26 11:06:12","2008-06-26 11:06:56","50","44","ANSWERED","DOCUMENTATION","","1214499966.13","",""
Here are the two CDR's with their recorded event times:
CDR start answer end
1 1 2 3
2 4 5 6
above, I called into the snom360, and hit the "Transfer" button, dialed
201, and got congestion (101 gets moh until I hit the check key), and
hung up the snom (200). 201, the eyebeam, rings, I answer. 101 and 201
are connected. 101 hangs up, and the conversation ended.
THE SAME PROCEDURE ON THE CDRfix6 branch:
""fxs.01"
<101>","101","200","extension","DAHDI/1-1","SIP/snom360-0829e2d0","Dial","SIP/snom360,30,Tt","2008-06-26 12:16:37","2008-06-26 12:16:44","2008-06-26 12:17:01","24","17","ANSWERED","DOCUMENTATION","","1214504197.4","",""
""fxs.01"
<101>","101","202","extension","DAHDI/1-1","SIP/murf-eyebeam-082c2b70","Dial","SIP/murf-eyebeam,30,Tt","2008-06-26 12:17:01","2008-06-26 12:17:14","2008-06-26 12:17:49","48","35","ANSWERED","DOCUMENTATION","","1214504197.4","",""
CDR start answer end
1 1 2 4
2 4 5 6
Well, time 3 does get lost, but I thought it might be nice to
be able to link 1 & 2 by the coincident times and say, hey, that
looks like a blind transfer!
One point of dissatisfaction I have with these is the fact that SIP/snom
dialed the second CDR, not DAHDI/1. But, if I change it, you won't know
that DAHDI/1 was the guy that murf-eyebeam was talking to... tough
choices.
So, I take it from your above words, that you'd like the 1,2,3; 4,5,6;
times
on the two CDR's?
Can anyone lab this up for 1.2; I don't have enough phones, and I'm not
eager
to reconfigure the ones I've got for just one test.... !
> For people on the list following this bug my company got stung by this
> in the last week so there now appear to be some people out there
> actively looking for Asterisk systems to exploit. The incident for us
> was a user using attended transfers to place free calls through a 1.2
> system. In the past we have had normal users stumble across the
> problem but in this case it was a directed attempt. So if like us you
> are a provider and use Asterisk and are required to support transfers
> it would be highly advisable to keep a close eye on things!
Won't it be pleasant to slip in the fix and watch these guys get billed
for calls they were thinking would be free!
murf
--
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080626/c8ee280b/attachment.bin
More information about the asterisk-users
mailing list