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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
