Hi Daniel, For some reasons, onsend_route doesn't triggered when transfering 100,180,183, etc...

2012/5/11 Daniel-Constantin Mierla &lt;miconda(a)gmail.com <mailto:miconda@gmail.com>> Hello, debug messages printed to syslog from the source code are because the developer needed/wanted them for troubleshooting. As an admin, you have the option of using xlog to print what ever messages you want. In 3.1.x there is onsend_route to see outgoing requests via $snd(...) variable. But if you want to get the sip traffic going through kamailio, better use siptrace module which stores requests/replies in database table. Cheers, Daniel -- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi Marius, My opinion that a replies should be routed to onsend_route after onreply_route in order unless they are dropped in onreply_route. It's by a common sense I think. All the traffic that is being sent/replied/forwarded and so on (in a short, all outgoing traffic) should trigger some callback. A good point to use onsend_route for replies/forwardings/etc too I think. There is a good reason (at least to me) which I need to see/parse them: my outgoing provider has a highly unwanted feature to us: forked calls. I have some program which is analyzing a remote leg connection state (no answer/busy/reorder, etc...) and this app is also analyzing all RTP which are sending within SDP on 180/181/183 messages. Let's say that Telco can send a multiple 183 SDP with a different IP/audio ports (c=/m=) and our application (which hasn't support for forking calls) is receive a multiple rtp streams to the same rtp port. Sure thing I did a proper logic to drop >1 of 180/181/183 sdp with a different contact info but I need to capture all the outgoing traffic that is routing to outbound from kamailio. I have to use wireshark just to see which replies are being set instead of just log them into a syslog/file. Could you please share with me that patch ? Thanks, 2012/5/14 Marius Zbihlei &lt;marius.zbihlei(a)1and1.ro <mailto:marius.zbihlei@1and1.ro>> Hello, Normally, onsend_route is not triggered for replies, only for messages. If there are some good reasons behind it, I don't know, as we have a simple patch that enables this (we are reviewing it before pushing it to upstream). Of course, no changes to the messages/replies are permitted ... So again, is there a cause why onsend_route is not triggered for replies atm? -- Zbihlei Marius Head of Linux Development Services Romania 1&1 Internet Development srl Tel KA: 754-9152 Str Mircea Eliade 18 Tel RO:+40-31-223-9152 <tel:%2B40-31-223-9152> Sect 1, Bucuresti mailto:marius.zbihlei@1and1.ro <mailto:marius.zbihlei@1and1.ro> 71295, Romania _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ 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

** Hi Konstantin, I have attached the patch that allows calling onsend route also for replies. After the 3.3 release is done, I will commit it also upstream. Regards, Anca On 05/14/2012 09:00 PM, Konstantin M. wrote: Hi Marius, My opinion that a replies should be routed to onsend_route after onreply_route in order unless they are dropped in onreply_route. It's by a common sense I think. All the traffic that is being sent/replied/forwarded and so on (in a short, all outgoing traffic) should trigger some callback. A good point to use onsend_route for replies/forwardings/etc too I think. There is a good reason (at least to me) which I need to see/parse them: my outgoing provider has a highly unwanted feature to us: forked calls. I have some program which is analyzing a remote leg connection state (no answer/busy/reorder, etc...) and this app is also analyzing all RTP which are sending within SDP on 180/181/183 messages. Let's say that Telco can send a multiple 183 SDP with a different IP/audio ports (c=/m=) and our application (which hasn't support for forking calls) is receive a multiple rtp streams to the same rtp port. Sure thing I did a proper logic to drop >1 of 180/181/183 sdp with a different contact info but I need to capture all the outgoing traffic that is routing to outbound from kamailio. I have to use wireshark just to see which replies are being set instead of just log them into a syslog/file. Could you please share with me that patch ? Thanks, 2012/5/14 Marius Zbihlei &lt;marius.zbihlei(a)1and1.ro&gt;

Hi Konstantin, Can you tell me exactly what you are calling in onsend_route and how you observe it is not working? Regards, Anca On 05/15/2012 04:55 PM, Konstantin M. wrote: ______________________________**_________________ 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<http:/…

Hi Anca, I fixed this problem with your help. A modified patch is attached. Thanks! 2012/5/16 Konstantin M. &lt;evilzluk(a)gmail.com <mailto:evilzluk@gmail.com>> Hi Anca, Yes, I will explain. Let's assume we have a kamailio config, attached as main.cfg (it's a very simplified, I have excluded a lot of customization here). Debug log attached as log1.txt is a clean log of running that config without your patch. With your patch was nothing changed. After investigation of code I see that a logic is not going to the place you've added in the patch. When I changed your patch this way (see attached forward.c.diff), I see that a logic is going to 'skip'. See a file attached as log2.txt with my modified patch. And finally, you can see what we're missing here, a difference between/after a 'skip' extending (attached as log.diff). Thanks! 2012/5/16 Anca Vamanu &lt;anca.vamanu(a)1and1.ro <mailto:anca.vamanu@1and1.ro>> Hi Konstantin, Can you tell me exactly what you are calling in onsend_route and how you observe it is not working? Regards, Anca On 05/15/2012 04:55 PM, Konstantin M. wrote: Hi Anca, I've tested your patch and I don't think it's working. At least I was noticed that a logic is going to 'skip' label on 183 sdp: /* check modules response_f functions */ for (r=0; r<mod_response_cbk_no; r++) if (mod_response_cbks[r](msg)==0) goto skip; _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

In my opinion it would be cool if core has a feature to log every received and every sent message. The logging should include timestamp+proto+sourceIP:port+**receivedIP:port for received messages and timestamp+proto+sourceIP:port+**destinationIP:port for sent messages. For TLS of course it should log the encrypted message. Configuration should be done with a core parameter "message_log=0-4", similiar to memlog. IIRC there were again issues with siptrace not logging all messages and for example on a load balancer I do not want to use a DB just for logging. Thus, I think this would be a good feature for 3.4 release. regards Klaus On 11.05.2012 09:30, Daniel-Constantin Mierla wrote: ______________________________**_________________ 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<http:/…

On 05/22/2012 10:07 AM, Klaus Darilion wrote: Hello, Siptrace can log all messages if used in onsend_route with the patch Anca provided (will be merged into the master after 3.3 branching). ATM, onsend is called only for messages and not replies but the patch addresses this. You can use siptrace to log the messages to a separate K instance, and there use any DB backend to store the messages.

Regarding logging, I think you can get all these parameters from route(), reply_route() (for incoming) and onsend_route() (for outgoing) and using xlog() statements. Cheers, Marius