#1060 closed defect (wontfix)
Unable to register transaction (key exists) error message
Reported by: | bennylp | Owned by: | bennylp |
---|---|---|---|
Priority: | normal | Milestone: | release-1.7 |
Component: | pjsip | Version: | trunk |
Keywords: | Cc: | ||
Backport to 1.x milestone: | Backported: |
Description (last modified by bennylp)
Transaction may fail to be created/registered to the hash table with the following error message:
"Unable to register transaction (key exists)"
It has been reported that this happened in this scenario:
- in simulated very bad network conditions, with modified Wifi router's iptable to reject certain TCP packets. When TCP disconnect event is received, renew the registration if account id is valid or start SIP registration from the beginning. Thanks Tamàs Solymosi for the report.
Change History (4)
comment:1 Changed 15 years ago by bennylp
- Description modified (diff)
comment:2 Changed 15 years ago by bennylp
- Resolution set to wontfix
- Status changed from new to closed
comment:3 Changed 15 years ago by bennylp
Another scenario has been reported, where two outgoing INVITE requests from two different calls have exactly the same Via branch value. Upon further investigation, this branch value comes from the guid_simple.c GUID generator. This was reported on Linux.
As it turned out, this is caused by a third party sound device which always reset the random seed (i.e. "srand()") with the same value every time the sound device is opened.
On Linux, installing libuuid-dev should also fix the problem. If libuuid-dev is installed, the ./configure script whould detect it and it will be used instead.
comment:4 Changed 15 years ago by bennylp
Update: the assertion that accompanies this problem is removed by #1090
Looking at the log sent by the user, this is not related to branch param generator at all.
What happened was the call is hangup by user (presumably due to TCP disconnection) which caused CANCEL to be sent. Then shortly after that, the stack is shutdown by the application, and PJSUA-LIB hangs up all active calls, causing another CANCEL to be sent. Since the first CANCEL transaction has not been completed, the second CANCEL would fail with that "key exists" error.
I think this is fine, unless it caused crash or similar problems.