[Spce-user] CDR duration issue in forking scenario
Jon Bonilla (Manwe)
manwe at sipdoc.net
Wed Dec 4 20:31:57 EST 2019
Hi all
ngcp 5.5.9
A subscriber has registered two PBX systems and both of them answer the call
almost at the same time when called. The answer is so simultaneous that both
200 ok hit the caller before one of the B leg branches is canceled.
The caller sends BYE to one of the branches and continues the call with the
other B leg branch. The problem is that later in the CDR we get two CDRs, but
seems like mediator uses the same BYE acc mark for both of them. Instead of
having one call less-than-a-second duration and the other one the usual call
duration, both have less than a second duration and that makes a big hole in
the accounting system.
Here's an example:
spce does a parallel forking and received two 200 OK. Let's call them B1 and B2
branches:
200 B1
2131806_47069357
f: tag=63EEED01-5DE7AEBE0003D9E6-87609700
t:tag=as6224adbe
200 B2
2131806_47069357
f:tag=1FAC516F-5DE7AEBE0003DA62-87508700
t:tag=as71ac7991
those are sent to leg A.
200 A:
From: <sip:FROMURI>;tag=gK001af85f
To: <sip:TOURI>;tag=4FC20818-5DE7AEBE0003D8B2-7C789700
Call-ID: 2131806_47069357
200 A:
From: <sip:FROMURI>;tag=gK001af85f
To: <sip:TOURI>;tag=0E4B3F46-5DE7AEBE0003D8CC-7C98B700
Call-ID: 2131806_47069357
The caller sends ACKs
ACK A:
From: <sip:FROMURI>;tag=gK001af85f
To: <sip:TOURI>;tag=4FC20818-5DE7AEBE0003D8B2-7C789700
Call-ID: 2131806_47069357
ACK A
From: <sip:FROMURI>;tag=gK001af85f
To: <sip:TOURI>;tag=0E4B3F46-5DE7AEBE0003D8CC-7C98B700
Call-ID: 2131806_47069357
Immediately the caller sends a BYE to one of the branches:
BYE A
From: <sip:FROMURI>;tag=gK001af85f
To: <sip:TOURI>;tag=0E4B3F46-5DE7AEBE0003D8CC-7C98B700
Call-ID: 2131806_47069357
200 OK A
From: <sip:FROMURI>;tag=gK001af85f
To: <sip:TOURI>;tag=0E4B3F46-5DE7AEBE0003D8CC-7C98B700
Call-ID: 2131806_47069357
11 seconds later the call finishes and caller sends the BYE to the connected
branch:
BYE A
From: <sip:FROMURI>;tag=gK001af85f
To: <sip:TOURI>;tag=4FC20818-5DE7AEBE0003D8B2-7C789700
Call-ID: 2131806_47069357
200 OK A
From: <sip:FROMURI>;tag=gK001af85f
To: <sip:TOURI>;tag=4FC20818-5DE7AEBE0003D8B2-7C789700
Call-ID: 2131806_47069357
Now, if we check accounting.cdr:
MariaDB [kamailio]> select call_id,duration from accounting.cdr where
call_id='2131806_47069357';
+-------------------------------+----------+
| call_id | duration |
+-------------------------------+----------+
| 2131806_47069357 | 0.031 |
| 2131806_47069357 | 0.026 |
+-------------------------------+----------+
And if we check acc marks we'll see that only one BYE acc mark has been used
for both:
MariaDB [kamailio]> select * from acc where callid='2131806_47069357'\G
*************************** 1. row ***************************
id: 677414551
method: BYE
from_tag: gK001af85f
to_tag: 4FC20818-5DE7AEBE0003D8B2-7C789700
callid: 2131806_47069357
sip_code: 200
sip_reason: OK
time: 2019-12-04 08:04:09
time_hires: 1575464649.815
src_leg:
dst_leg:
dst_user:
dst_ouser: DST
dst_domain: 127.0.0.1
src_user: SRC
src_domain: SRC.COM
1 row in set (0.00 sec)
MariaDB [kamailio]> select * from acc_backup where callid='2131806_47069357'\G
*************************** 1. row ***************************
id: 2170676087
method: BYE
from_tag: gK001af85f
to_tag: 0E4B3F46-5DE7AEBE0003D8CC-7C98B700
callid: 2131806_47069357
sip_code: 200
sip_reason: OK
time: 2019-12-04 08:03:58
time_hires: 1575464638.298
src_leg:
dst_leg:
dst_user:
dst_ouser: DST
dst_domain: 127.0.0.1
src_user: SRC
src_domain: SRC.COM
*************************** 2. row ***************************
id: 2170676089
method: INVITE
from_tag: gK001af85f
to_tag: 4FC20818-5DE7AEBE0003D8B2-7C789700
callid: 2131806_47069357
sip_code: 200
sip_reason: OK
time: 2019-12-04 08:03:58
time_hires: 1575464638.267
src_leg:
0|SRC|SRC.COM|SRC|||0|||0|call|SRC.COM|1575464638.184466||||||||||||SRC||
dst_leg:
0|||12|DST|51af95ad-3338-426c-83b8-1d3a6693759a|mysubscriber|mydomain.com|DST|77.77.77.77|0||||||||||||mysubscriber||
dst_user: DSTNUM dst_ouser: DST dst_domain: DST1.COM
src_user: SRC
src_domain: SRC.COM
*************************** 3. row ***************************
id: 2170676091
method: INVITE
from_tag: gK001af85f
to_tag: 0E4B3F46-5DE7AEBE0003D8CC-7C98B700
callid: 2131806_47069357
sip_code: 200
sip_reason: OK
time: 2019-12-04 08:03:58
time_hires: 1575464638.272
src_leg:
0|SRC|SRC.COM|SRC|||0|||0|call|SRC.COM|1575464638.184466||||||||||||SRC||
dst_leg:
0|||12|DST|51af95ad-3338-426c-83b8-1d3a6693759a|mysubscriber|mydomain.com|DST|77.77.77.77|0||||||||||||mysubscriber||
dst_user: DSTNUM dst_ouser: DST dst_domain: DST2.COM
src_user: SRC
src_domain: SRC.COM
Seems like an issue in mediator not honoring callid + fromtag + totag. Looks
like it just uses callid for matching. right?
cheers,
Jon
--
https://pekepbx.com
https://www.issabel.com/multitenant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Firma digital OpenPGP
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20191205/1951afb0/attachment.sig>
More information about the Spce-user
mailing list