On 05/11/2012 11:24 PM, Konstantin M. wrote:

Hi Daniel,

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

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?

Cheers, M.

2012/5/11 Daniel-Constantin Mierla <miconda@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@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hello,

there is no particular reason to avoid extending the code so that onsend_route is executed for replies. It wasn't done because no developer/contributed needed it (or didn't make the code public).

I had it in mind, but lack of time and no real need for myself set lower priority.

If Marius has a patch, once we branch the 3.3 series, he can put it on git master. Meanwhile he can share the patch as he wants, by tracker, mailing list or personal branch...

Cheers, Daniel

On 5/14/12 8: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 <marius.zbihlei@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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;

2012/5/15 Anca Vamanu anca.vamanu@1and1.ro

** 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 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 Sect 1, Bucuresti mailto: marius.zbihlei@1and1.ro 71295, Romania

---

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

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 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@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi Knostantin,

I have looked at your patch and it seems that you use a module that registers a response function which returns 0. The problem is not actually in the forward.c file but with that function.

Can you please tell me which is the list of modules that you are using?

Regards, Anca

On 05/17/2012 01:33 PM, Konstantin M. wrote:

Hi Anca,

I fixed this problem with your help. A modified patch is attached.

Thanks!

2012/5/16 Konstantin M. <evilzluk@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 <anca.vamanu@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@lists.sip-router.org
    <mailto:sr-users@lists.sip-router.org>
    http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

I second that.

Siptrace doesn't log everything, but workarounds can be done, such as using a combination of setting a flag and using the sip_trace( ) function, and using them as well from the onsend_route for some outgoing messages, with careful handling to prevent duplicate logging.

Reda

On Tue, May 22, 2012 at 9:07 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:

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:

...

Hello,

On 5/9/12 11:45 PM, Bruno Bresciani wrote:

...

Hi all,

Why kamailio send to syslog only received SIP messages? I want see the messages that kamailio send to the UAs, it's possible? On TCP/TLS SIP messages there is a degub of buffer with the message that will be send, but a strange content has been shown... following the log:

*tcp_send: buf= ^W^C^A^B0HFCðg^W^R £MÃ<8f>C^U<8f>ÃQB^^,¼8ÃÃ^**KZÃÃ|<97>¼zÃö<82>ìñÃ%sÃâ**³g¿à S©<97>}y<91>.<94>ð¯ô<8f>**Y¿¥µf<9d>ë<8f><9d>*

My kamailio is version 3.1.2 and run with global parameter 'debug=3' and send the syslog messages.

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://www.linkedin.com/in/**micondahttp://www.linkedin.com/in/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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

______________________________**_________________ 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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hello,

few clarifications about siptrace, see inline ...

On 5/22/12 9:31 AM, Marius Zbihlei wrote:

On 05/22/2012 10:07 AM, Klaus Darilion wrote:

...

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.

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.

Even if onsend_route is not executed for replies in the current version, siptrace uses internal callbacks to store received and sent replies. So with siptrace you should get all the traffic going through kamailio, no matter is reply or request.

Cheers, Daniel

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