murf at digium.com Guest
|
Posted: Thu Jun 26, 2008 2:21 pm Post subject: [asterisk-users] Warning: CDRfix branches about to be merged |
|
|
On Wed, 2008-06-25 at 22:50 +0100, Grey Man wrote:
Quote: | On Tue, Jun 24, 2008 at 4:28 PM, Steve Murphy <murf at digium.com> wrote:
Quote: | 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,
Quote: | 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.... !
Quote: | 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 |
|