23 Sep
2011
23 Sep
'11
10:27 a.m.
Hello,
On 9/15/11 4:02 PM, Timo Klecker wrote:
Hi Daniel,
I managed to get a log with debug 4 from one call. I had to take out all
IP-Addresses and Usernames, hope you can use it.
the log confirmed what I
expected:
Sep 15 15:32:33 vux896 /sbin/kamailio[31594]: DEBUG: siptrace
[siptrace.c:954]: no uas msg, local transaction
Sep 15 15:32:33 vux896 /sbin/kamailio[31594]: DEBUG: tm [t_fwd.c:1242]:
DEBUG: e2e_cancel: e2e cancel proceeding
Because a new CANCEL is generated from scratch, incoming message is lost
and no longer available to check the sip trace flag.
Now, the question is how to decide whether the cancel is to be
siptraced. I can lookup for incoming CANCEL and check if it has the
siptrace flag set, but there are CANCELs in case of local timeout or
parallel forking, so I think it is better to actually lookup the INVITE
transaction and if the siptrace flag is set for it, record the cancel.
If there is no INVITE transaction anymore, the cancel is forwarded
stateless and can be captured in onsend route, although it should be
normally discarded if it is known that the proxy works in statefull mode
only.
Any other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
23 Sep
23 Sep
10:38 a.m.
New subject: CANCEL is not processed in onsend_route
Hello Daniel,
thanks for your reply. I think it would be best to lookup the INVITE
transaction and decide based on the trace-flag, as you suggested.
Greetings
Timo
-----Ursprüngliche Nachricht-----
Von: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Gesendet: Freitag, 23. September 2011 10:27
An: Timo Klecker; kamailio users
Betreff: Re: [SR-Users] CANCEL is not processed in onsend_route
Hello,
On 9/15/11 4:02 PM, Timo Klecker wrote:
Hi Daniel,
I managed to get a log with debug 4 from one call. I had to take out
all IP-Addresses and Usernames, hope you can use it.
the log confirmed what I
expected:
Sep 15 15:32:33 vux896 /sbin/kamailio[31594]: DEBUG: siptrace
[siptrace.c:954]: no uas msg, local transaction Sep 15 15:32:33 vux896
/sbin/kamailio[31594]: DEBUG: tm [t_fwd.c:1242]:
DEBUG: e2e_cancel: e2e cancel proceeding
Because a new CANCEL is generated from scratch, incoming message is lost and
no longer available to check the sip trace flag.
Now, the question is how to decide whether the cancel is to be siptraced. I
can lookup for incoming CANCEL and check if it has the siptrace flag set,
but there are CANCELs in case of local timeout or parallel forking, so I
think it is better to actually lookup the INVITE transaction and if the
siptrace flag is set for it, record the cancel.
If there is no INVITE transaction anymore, the cancel is forwarded stateless
and can be captured in onsend route, although it should be normally
discarded if it is known that the proxy works in statefull mode only.
Any other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced
Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
11:50 a.m.
New subject: CANCEL is not processed in onsend_route
Hello,
here is the link to the commit:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7b2eca4…
The patch is not that big, can be easily extracted and applied to 3.1 if
more convenient for testing, Anyhow, I did no tests here, please do it
and let me know if works fine. If not, then send me again the debug
messages. When all ok, I will backport to 3.1 as well.
Thanks,
Daniel
On 9/23/11 10:38 AM, Timo Klecker wrote:
Hello Daniel,
thanks for your reply. I think it would be best to lookup the INVITE
transaction and decide based on the trace-flag, as you suggested.
Greetings
Timo
-----Ursprüngliche Nachricht-----
Von: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Gesendet: Freitag, 23. September 2011 10:27
An: Timo Klecker; kamailio users
Betreff: Re: [SR-Users] CANCEL is not processed in onsend_route
Hello,
On 9/15/11 4:02 PM, Timo Klecker wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel,
I managed to get a log with debug 4 from one call. I had to take out
all IP-Addresses and Usernames, hope you can use it.
the log confirmed what I
expected:
Sep 15 15:32:33 vux896 /sbin/kamailio[31594]: DEBUG: siptrace
[siptrace.c:954]: no uas msg, local transaction Sep 15 15:32:33 vux896
/sbin/kamailio[31594]: DEBUG: tm [t_fwd.c:1242]:
DEBUG: e2e_cancel: e2e cancel proceeding
Because a new CANCEL is generated from scratch, incoming message is lost and
no longer available to check the sip trace flag.
Now, the question is how to decide whether the cancel is to be siptraced. I
can lookup for incoming CANCEL and check if it has the siptrace flag set,
but there are CANCELs in case of local timeout or parallel forking, so I
think it is better to actually lookup the INVITE transaction and if the
siptrace flag is set for it, record the cancel.
If there is no INVITE transaction anymore, the cancel is forwarded stateless
and can be captured in onsend route, although it should be normally
discarded if it is known that the proxy works in statefull mode only.
Any other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced
Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
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
4608
days inactive
4608
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Timo Klecker