20 Nov
2013
20 Nov
'13
11:57 p.m.
Hello,
are you dropping replies? I don't see the 'SIP/2.0 487 Request
Terminated' being sent to caller, it looks ok and has two Via headers.
Cheers,
Daniel
On 11/20/13 4:06 PM, Guillaume Bour wrote:
On 20/11/2013 12:01, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
- more details about Kamailio trainings at http://www.asipto.com -
Hello,
On 11/20/13 11:50 AM, Guillaume Bour wrote:
Hi Daniel,
local-request is triggered by a BYE
I have attached sample log and trace
There is some kind of dialogs mixing. Here is the 1st call dialog as
reported by "kamctl mi dlg_list" _before and after_ the 2d call is
answered:
# kamctl mi dlg_list
dialog:: hash=2790:3231
state:: 2
ref_count:: 1
timestart:: 0
timeout:: 0
callid:: GoXhk8GfkIEEqFyFNcySEjSOOpVKg4Uq
from_uri:: sip:15909901@staging.voip
from_tag:: swYh88AkicGbSHpK.D1z7uo3EX9Q-.AZ
caller_contact::
sip:37984520-gch2kindtioq8@10.0.1.10:5060;transport=udp
caller_cseq:: 24899
caller_route_set::
caller_bind_addr:: udp:10.0.1.10:5060
callee_bind_addr::
to_uri:: sip:+3360000011@staging.voip
to_tag::
callee_contact::
callee_cseq::
callee_route_set::
# kamctl mi dlg_list
dialog:: hash=2790:3231
state:: 3
ref_count:: 2
timestart:: 1384952191
timeout:: 20242152
callid:: GoXhk8GfkIEEqFyFNcySEjSOOpVKg4Uq
from_uri:: sip:15909901@staging.voip
from_tag:: swYh88AkicGbSHpK.D1z7uo3EX9Q-.AZ
caller_contact::
sip:37984520-gch2kindtioq8@10.0.1.20:5060;transport=udp
caller_cseq:: 24899
caller_route_set::
caller_bind_addr:: udp:10.0.1.10:5060
callee_bind_addr:: udp:10.0.1.10:5060
to_uri:: sip:+3360000011@staging.voip
to_tag:: as6c8b935a
callee_contact:: sip:+3360000022@10.0.1.11:5060
callee_cseq::
callee_route_set::
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hi All
We wan't to prevent our users to make more than one call at time, so
we choose to disconnect the previous call.
When the previous call is established, we use dlg_bye(), and its ok.
But when it is in early state, we use t_cancel_callid() to cancel
its INVITE transaction.
We face 2 issues:
1) we use local-request event route to account calls on timeout.
Sometimes this route is called for the cancelled call (after default
timeout of 1 hour)
what is in the local-request in this case? Is it a BYE?
2) t_cancel_callid() cancel previous call,
but also _make
current dialog disappear_: call is still ongoing and we can answer
and talk to each other, but the dialog does not appear in 'kamctl
stats dialog' and 'kamctl mi dlg_list' commands
Is there a known limitation, or do we misuse t_cancel_callid() ?
Can you send the
log with debug=3 in kamailio.cfg? It will help to
see what happens. Otherwise, if the call id is different for current
dialog, it should not happen. The ngrep output in this situation (for
both first and second invite) will help.
Cheers,
Daniel