henningw created an issue (kamailio/kamailio#4592)
### Description
The dlgs module is used on a load-balancer class system for traffic statistics.
Another system sends INVITE requests to the load-balancer, which are balanced
to different carriers. If carrier A rejects the traffic, the traffic source
creates another INVITE (basically in a serial forking scenario) which only
differs from the branch-id to the previous INVITE. The load-balancer forwards
this to carrier B, which accept the call.
The dlgs module will not track the second call correctly, as the first calls is
already in the list and not yet expired due to the timer. Setting the timer to
e.g. 1s will not solve it, as the serial forking happens faster if the first
carrier just rejects the call for example.. This issue will misreporting of
caller statistics, as established calls which tooks one or more tries to get
setup are not tracked anymore.
Sometimes the call is accepted only at the third or fourth attempt, but the
problem is basically the same.
### Troubleshooting
#### Reproduction
Send serial forked INVITE calls to a system with dlgs enabled.
#### Debugging Data
#### Log Messages
```
Feb 13 18:23:26 lab.WWW.com /usr/local/sbin/kamailio[1675553]: DEBUG: dlgs
[dlgs_records.c:321]: dlgs_add_item(): call-id already in hash table
[d3c5ba80-04b8-4d5c-a249-50220ab6eea5].
Feb 13 18:23:26 lab.WWW.com /usr/local/sbin/kamailio[1675553]: DEBUG: dlgs
[dlgs_mod.c:191]: ki_dlgs_init(): added item return code: 1
```
#### SIP Traffic
Examples for two SIP messages, IPs anonymized below. The log messages quoted
above is from another call (call-id), but the patters is the same. The only
difference of the INVITEs is the branch-id in the first Via header.
```
INVITE sip:[email protected] SIP/2.0
Record-Route: <sip:172.0.0.3;lr;ftag=c75ecd74-6610-46bb-9258-3ce68105aa25>
Record-Route:
<sip:172.0.0.2;lr=on;ftag=c75ecd74-6610-46bb-9258-3ce68105aa25;dlgcor=748c2.b0b1>
Record-Route: <sip:172.0.0.1;r2=on;lr;ftag=c75ecd74-6610-46bb-9258-3ce68105aa25>
Record-Route: <sip:Z.Z.Z.Z;r2=on;lr;ftag=c75ecd74-6610-46bb-9258-3ce68105aa25>
Via: SIP/2.0/UDP 172.0.0.3;branch=z9hG4bK754f.9f854866598f966dd6369bea011bcb4c.2
Via: SIP/2.0/UDP 172.0.0.2;branch=z9hG4bK754f.b89e326662ff3ce3cd68b2abea302811.0
Via: SIP/2.0/UDP 172.0.0.1;branch=z9hG4bK754f.90c8d2597c89cdf4b5d94af55f05d48d.0
Via: SIP/2.0/UDP
192.0.0.2:5060;received=192.0.0.2;rport=5060;branch=z9hG4bKPjf9d051c9-fd5e-4870-8d8f-cab171b4cd2b
From: +123XXX <sip:[email protected]>;tag=c75ecd74-6610-46bb-9258-3ce68105aa25
To: +123YYY <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: 52edd5ec-a4c9-446e-bcce-52c9a6020249
CSeq: 4087 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL,
UPDATE, PRACK, REFER, MESSAGE, INFO
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 22.X
Content-Type: application/sdp
Content-Length: 239
v=0
o=- 828679149 828679149 IN IP4 192.0.0.2
s=Asterisk
c=IN IP4 192.0.0.2
t=0 0
m=audio 65416 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv
```
```
INVITE sip:[email protected] SIP/2.0
Record-Route: <sip:172.0.0.3;lr;ftag=c75ecd74-6610-46bb-9258-3ce68105aa25>
Record-Route:
<sip:172.0.0.2;lr=on;ftag=c75ecd74-6610-46bb-9258-3ce68105aa25;dlgcor=748c2.b0b1>
Record-Route: <sip:172.0.0.1;r2=on;lr;ftag=c75ecd74-6610-46bb-9258-3ce68105aa25>
Record-Route: <sip:Z.Z.Z.Z;r2=on;lr;ftag=c75ecd74-6610-46bb-9258-3ce68105aa25>
Via: SIP/2.0/UDP 172.0.0.3;branch=z9hG4bK754f.9f854866598f966dd6369bea011bcb4c.3
Via: SIP/2.0/UDP 172.0.0.2;branch=z9hG4bK754f.b89e326662ff3ce3cd68b2abea302811.0
Via: SIP/2.0/UDP 172.0.0.1;branch=z9hG4bK754f.90c8d2597c89cdf4b5d94af55f05d48d.0
Via: SIP/2.0/UDP
192.0.0.2:5060;received=192.0.0.2;rport=5060;branch=z9hG4bKPjf9d051c9-fd5e-4870-8d8f-cab171b4cd2b
From: +123XXX <sip:[email protected]>;tag=c75ecd74-6610-46bb-9258-3ce68105aa25
To: +123YYY <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: 52edd5ec-a4c9-446e-bcce-52c9a6020249
CSeq: 4087 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL,
UPDATE, PRACK, REFER, MESSAGE, INFO
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 22.X
Content-Type: application/sdp
Content-Length: 239
v=0
o=- 828679149 828679149 IN IP4 192.0.0.2
s=Asterisk
c=IN IP4 192.0.0.2
t=0 0
m=audio 65416 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv
```
### Possible Solutions
One idea would be to add the branch id of the first Via header to the internal
_dlgs_item structure. And then compare the branch id of the previous tracked
call in the hash table which is in state deleted to the branch id of the new
call. If there differ, add a new entry for the second call, the first call will
be deleted by timer as usual.
### Additional Information
A kamailio 5.8.x was used for testing, but the relevant code is also present in
git master I think. The relevant functionality was not changed by any patches
or other changes.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4592
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/[email protected]>
_______________________________________________
Kamailio - Development Mailing List -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
