1. Brekeke Product Name and Version:
Version 3.2.4.3 Advanced
2. Java version:
1.6.0_45
3. OS type and the version:
Red Hat Enterprise Linux Server release 5.11 (Tikanga)
4. UA (phone), gateway or other hardware/software involved:
IVR
5. Your problem:
This is more of a general inquiry.
With a normal call clearing (answer / hangup) scenario we see the session tear down and is immediately followed by a sipex close, e.g.
session.27: send: to=UAS:xx.xxx.xxx.xx(UDP) at 10/17/14 19:22:04.978
[snip]
session.27: sipex.10: close: result=Cancel total-pkt=7 at 10/17/14 19:23:34.979
When it's not a normal call clearing we see the sipex line appear sometimes around 90 seconds later,e.g
session.19: send: to=UAS:xx.xxx.xxx.xx(UDP) at 10/17/14 19:01:05.803
[snip]
session.19: sipex.10: close: result=Cancel total-pkt=7 at 10/17/14 19:02:35.805
Just wondering why that is and I'm assuming that it has no implication on the duration of the session, right? At that point both UA and UAS have terminated the session.
Thanks in advance,
Mike
sipex log line and duration
Moderator: Brekeke Support Team
It depends on how a SIP session is ended.
If the SIP Server supposes there will be subsequent packets, the server keeps the session for a while (90sec).
This length can be tuned with the environment variable "net.sip.timeout.bye". (its default is 90000 [ms]).
Even if the SIP Server keeps a session for a while, the session log doesn't count this additional time.
It means the session log always shows the actual time-stamps.
If the SIP Server supposes there will be subsequent packets, the server keeps the session for a while (90sec).
This length can be tuned with the environment variable "net.sip.timeout.bye". (its default is 90000 [ms]).
Even if the SIP Server keeps a session for a while, the session log doesn't count this additional time.
It means the session log always shows the actual time-stamps.