[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