[asterisk-dev] CDR4fix segfault
Steve Murphy
murf at digium.com
Wed Jun 11 16:44:58 CDT 2008
On Tue, 2008-06-10 at 11:27 -0500, John Lange wrote:
> The good news is; no segfaults this time. See inline for test results.
>
> On Mon, 2008-06-09 at 20:02 -0600, Steve Murphy wrote:
> > On Mon, 2008-06-09 at 11:26 -0500, John Lange wrote:
> > > Steve, here is another backtrace from a segfault.
> > >
> > > This time the sequence was:
> > >
> > > outside -> 502
> > > 502 axfr -> 501
> > > 501 bxfr -> 503
> > >
> > > When 503 answers there is a segfault.
> > >
> > > On a positive note, the logging before the segfault appears to be
> > > correct.
> > >
> > > Regards,
> > > -
> > > John Lange
> > > www.johnlange.ca
> > >
> >
> > Well, the changes I committed allowed me to try to replicate
> > your results;
> >
> > your outside = Zap/1, ext 101
> > your 502 = Sip/Snom360, ext 200
> > your 501 = Sip/Polycom430, ext 201
> > your 503 = Sip/Eyebeam, ext 202
> >
> > So, my steps/events are:
> >
> > Zap/1 calls ext 200, Sip/snom360
> > 200 answers
> > 200 preses hold key (101 gets MOH)
> > 200 dials 201
> > 201 answers, they can talk (axfer)
> > 200 hits Transfer button, gets silence, 101 and 201 are connected
> > 200 hangs up
> > 201 presses the Transfr soft key, 101 gets MOH
> > 201 presses the Blind soft key
> > 201 enters 202
> > 201 presses the "send" softkey, 201 gets congestion (iirc),
> > 202 answers, 101 and 202 are connected, and converse
> > 202 hangs up, 101 gets congestion
> >
> > 3 CDR's are emitted.
> >
> > 101->200 t1, t2, t5
> > 200->201 t3, t4, t6
> > 101->202 t6, t7, t8
>
> Yes, with your fixes from today that is what I'm getting. It is missing
> data but does that match the results from the old 1.2?
Just checked. 1.2 says:
CDR 1:
from Sip/snom, to: Sip/polycom, app: NoOp Data: last NoOp arg
start: 15:25:55 ans: 15:25:58 end: 15:26:21,
dur: 26; billsec: 23
CDR 2:
from Zap/1 to Sip/snom, app: NoOp; Data: last NoOp arg
start 15:25:31; ans: 15:25:35; end: 15:26:21
dur: 50; billsec: 46
In the above, the NoOp and its arg are stuff from the 'h' (hangup)
extension. Both CDR's ended at the same time; which is not so good.
So, CDRfix4/5/6 is a little better than 1.2
>
> We should have 4 CDRs, one for each leg in this call:
>
> leg 1: 101 -> 200
> leg 2: 200 -> 201
> leg 3: 101 -> 201
> leg 4: 101 -> 202
>
> With the way things stand Leg 3 is missing.
>
> To make things easier, lets simplify the example. The one that is of
> most concern is the attended transfers so lets consider that scenario by
> itself.
>
> My phones (Aastra 57i & Linksys 942) work differently than what you
> described so for the sake of completeness I'll describe it exactly as we
> do it. The machine I'm testing on (my laptop) does not have a zap card
> so In fact I'm using a SIP trunk for outside calls which I'll call 516.
>
> Scenario:
>
> 1. 516 (outside) calls 502 and 502 answers (leg 1)
> 2. 502 presses the xfr button (which puts 516 on hold)
> 3. 502 calls 501 and 501 answers (leg 2)
> 4. 502 presses the xfr button again which completes the attended xfr.
> 5. 516 and 501 talk for a while and then hangup. (leg 3)
>
> We should have 3 CDRs, one for each leg in this call and they would be
> in the order that the calls ended (leg 2, leg 1, leg 3) but for the sake
> of not making it too confusing I'll keep them in the order the calls
> started:
>
> leg 1: 516 -> 502 (duration 15)
> leg 2: 502 -> 501 (duration 5)
> leg 3: 516 -> 501 (duration 10)
>
> However, what we actually get is 2 CDRs like this:
> leg 1: 516 -> 502 (duration 15)
> leg 2: 502 -> 501 (duration 15) (the sum of leg 2 & 3)
>
> If there is only going to be 2 CDRs then it should be leg 1 & 3 as they
> are the most important.
John--
OK, I have investigated this scenario.
I can get it to work on my Snom360, but am having trouble getting
it working on my Polycom430 or Eyebeam, mainly due (I think)
multiple registrations. My Snom registers to 3 test systems,
the polycom to 2, and the Eyebeam to 2. the Eyebeam and polycom
seem to want to route the xfer to the first host on the list,
and that's not the right one today... which is
kinda funny, because I can make the polycom work
with blind xfers! I'll try to see
what I can do... (have I expressed my hatred yet today
for the various phone user interfaces?)
So, with SNOM360, it looks like this:
1. pick up zap/1 (ext 101) (t1)
2. zap/1 dials exten 200 (the snom360)
3. 200 answers zap/1 & sip/snom360 converse (t2)
4. 200 presses the HOLD button (t3)
(200 gets dialtone, 101 gets MOH)
5. 200 dials 201 (the polycom)
6. 201 answers (200 & 201 converse) (t4)
7. 200 hits the transfer button (101 & 201 get MOH)
8. 200 hangs up (101 & 201 get connected) (t5)
(They converse)
9. 101 or 201 hang up. Sequence finishes. (t6)
With the above sequence, it is as you pointed out; you get two
CDR's generated:
CDR 1:
from Zap/1, to Sip/snom360, Dial, Sip/snom360,
start: 11:06:46 (t1), ans: 11:06:52 (t2); end:11:08:03 (t5)
dur: 77; billsec: 71
CDR 2:
from Sip/snom360, to Sip/polycom, Dial, Sip/polycom,
start: 11:07:17 (t3), ans: 11:07:26 (t4),end:11:09:40 (t6)
dur: 143, billsec: 134
I've labeled each time in the CDR's with t1-t6; I have also
put the corresponding labels (t1-t6) in the event list above.
Now, the real question is: "What SHOULD the CDR's look like?"
cdr 1:
same
cdr 2:
from Sip/snom360, to Sip/polycom, Dial, Sip/polycom,
start: 11:07:17 (t3), ans: 11:07:26 (t4),end:11:08:03 (t5)
dur: 46 ; billsec: 37
cdr 3:
from Zap/1, to Sip/polycom, "xfer", "Sip/snom360",
start: 11:08:03 (t5), ans: 11:08:03 (t5); end: 11:09:40 (t6)
dur: 97 ; billsec: 97
I'm not at this point committing to making this change, but
I'll investigate to see if it's even possible. I think/hope
it is. I was investigating this some months ago, and got
diverted...
For the application, I set the last CDR to "xfer", which
could be used to infer that the CDR is from a transfer.
The appdata I show as "Sip/snom360", to show who actually
dialed the polycom. If the polycom were in Fiji or Antarctica,
I'd think most billing systems would like to know who
should rightfully get the bill.
Notice that the current CDR system at least sets the
caller/callee fields such that the transferer (in CDR2)
(snom360, ext 200) would get the bill for calling
polycom, (a bit inflated, but at least accurate in that
respect).
I can't picture this change being "backwards compatible"
with any existing CDR system. What the CDR record is
showing will take some definite interpretation!
What do you think? What should we put in what field?
>
> I hope this doesn't confuse things but there is one other scenario that
> happens quite a lot and is actually recorded properly in the CDRs.
>
> Scenario:
>
> 1. 516 (outside) calls 502 and 502 answers (leg 1)
> 2. 502 presses the xfr button (which puts 516 on hold)
> 3. 502 dials 501 and while 501 is ringing, 502 presses the xfr button
> again which completes the xfr. (leg 2)
> 5. 516 and 501 talk for a while and then hangup. (leg 3)
>
> (this happens a lot because receptionists often use the attended
> transfer even when they really should be using the blind transfer)
>
> In the CDR we get 3 legs exactly as we would expect:
>
> leg 1: 516 -> 502
> leg 2: 502 -> 501 disposition: FAILED
> leg 3: 516 -> 501
>
> Perhaps this can be built on so it works for the other attended xfr
> scenario as well?
>
Each CDR scenario usually takes a different path thru the code.
The trick is not to try to use one path vs. another, but to
make sure that changing one path doesn't muck up the others
(which I have ample experience with, as per my notes from
previous efforts).
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-dev/attachments/20080611/b88ca625/attachment-0001.bin
More information about the asterisk-dev
mailing list