[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openser-users
Subject:    Re: [SR-Users] CANCEL is not processed in onsend_route
From:       Daniel-Constantin Mierla <miconda () gmail ! com>
Date:       2011-09-23 9:50:14
Message-ID: 4E7C5656.2030604 () gmail ! com
[Download RAW message or body]

Hello,

here is the link to the commit:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7b2eca4939ccae16ec7af4fa42e4b8a6e1a92b2f


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:
> > 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

-- 
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


[prev in list] [next in list] [prev in thread] [next in thread]