Re: [SR-Users] 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: 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