[SR-Users] CANCEL is not processed in onsend_route

Timo Klecker klecker at decoit.de
Fri Sep 23 10:38:35 CEST 2011

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. 


-----Ursprüngliche Nachricht-----
Von: Daniel-Constantin Mierla [mailto:miconda at 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


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?


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

More information about the sr-users mailing list