And one more thing.
In captured packet from Homer, I see original SIP packets, without topoh modifications. But in dump from network interface by wireshark i see that packets was modified...
On 05/01/16 14:05, Sergey Basov wrote:
And one more thing.
In captured packet from Homer, I see original SIP packets, without topoh modifications. But in dump from network interface by wireshark i see that packets was modified...
sip_trace module is taking the sip message as it is processed by the configuration file, after topoh did decryption of headers and before encrypting again. If you use udp/tcp, perhaps you can use homer agent application.
Eventaully, as a new feature, would be good to update sip_trace to hook into sending process after the topoh.
Cheers, Daniel
It will be great, because I am using sip TLS in production environment. This is why I can not using homer capture agent...
If you try to use the sip_trace() function inside onsend_route{ }, what messages do you get?
Cheers, Daniel
On 05/01/16 15:38, Sergey Basov wrote:
It will be great, because I am using sip TLS in production environment. This is why I can not using homer capture agent...
I just try it. I got only last ACK when call was finished.
I think than siptrace must catch and send duplicate message after topoh module. Because in other case we can see message as it is inside kamailio, not message that will be send to upstream or client...
WBR.
No other SIP requests? Only the ACK?
Cheers, Daniel
On 06/01/16 07:55, Sergey Basov wrote:
I just try it. I got only last ACK when call was finished.
I think than siptrace must catch and send duplicate message after topoh module. Because in other case we can see message as it is inside kamailio, not message that will be send to upstream or client...
WBR.
Sorry, not only ACK. There is ACK, INVITE, ACK and BYE
I am using kamailio as statefull proxy.
So in case of normal callflow there is REGISTER and so on..
And with sip_trace enabled in onsend_route errors in kamailio.log still persist.
Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <script>: onsend_route entered !!! Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023�#023�#0128*#027#0128*#024Q̌V��>
Is there any possibility do sending message via siptrace module after topoh module?
WBR -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-06 10:02 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
No other SIP requests? Only the ACK?
Cheers, Daniel
On 06/01/16 07:55, Sergey Basov wrote:
I just try it. I got only last ACK when call was finished.
I think than siptrace must catch and send duplicate message after topoh module. Because in other case we can see message as it is inside kamailio, not message that will be send to upstream or client...
WBR.
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
On 06/01/16 09:19, Sergey Basov wrote:
Sorry, not only ACK. There is ACK, INVITE, ACK and BYE
OK.
I pushed two patches to master branch that should fix the issue with the error log messages. Can you test with master branch? If all goes fine, then I will consider backporting.
For capturing the packets after topoh, more time is needed to analyze and implement if possible.
Cheers, Daniel
I am using kamailio as statefull proxy.
So in case of normal callflow there is REGISTER and so on..
And with sip_trace enabled in onsend_route errors in kamailio.log still persist.
Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <script>: onsend_route entered !!! Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023�#023�#0128*#027#0128*#024Q̌V��>
Is there any possibility do sending message via siptrace module after topoh module?
WBR
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-06 10:02 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
No other SIP requests? Only the ACK?
Cheers, Daniel
On 06/01/16 07:55, Sergey Basov wrote:
I just try it. I got only last ACK when call was finished.
I think than siptrace must catch and send duplicate message after topoh module. Because in other case we can see message as it is inside kamailio, not message that will be send to upstream or client...
WBR.
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
Thank you for patch.
I have applied patches from your commits 526fb4cdc2246284ecbd7de9ed65678da2dbe357 and 284c11ed16bdc5afcc9abf49c9f5c1749ce831e0 to kamailio 4.3.4 it was applied and build successfully.
There is no more errors in kamailio.log.
But Packet which is send by siptrace module to homer capture server is send before topoh modifications.
If you can correct this flow it will be great.
Thank you.
you can see this by looking at contact header:
dump from physical interface to upstream ================ INVITE sip:1111@10.1.23.23;transport=UDP;user=phone SIP/2.0 Record-Route: sip:10.56.42.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes Record-Route: sip:127.0.0.8;line=sr-BRwEk.dED.d0z.z0z.zvB.afyR8vygavebZAeL7LGVeJGVz2epcMQuTfzVGwD.1Szpc01rTfOuYL Via: SIP/2.0/UDP 10.56.42.23;branch=z9hG4bK4fed.265c2242365ddb0a53289d8a3eac05a7.0 Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-s7wTDLa0zUfYZXl5zpl0zpl0z.lRD.zok.sEG.lvBJY.euwReuTfzpl0zpl0z.lRD.zokqZaxuZ9P.c3BJX01R5fO.wCZLZ3WSqMkhBqGgCceVT7G.G.epGwe.wAzh5jz37jDW7ceh52GpZKDpcSBVfSPh7qzh1E Max-Forwards: 69 Contact: sip:127.0.0.8;line=sr-BRwEk.z8zh1LGplEzhdRzsljzU8jzU8Szh10zLMKGplRzhc7BJX0B2n6BbTfYsZT To: sip:1111@10.1.23.23;transport=UDP From: sip:2222@10.1.23.23;transport=UDP;tag=34ff4c7e Call-ID: Y2EyYmU5NGZiNjYxMGY3MDc0M2ZhYTU1MmNkODFjOWQ. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Content-Type: application/sdp Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Allow-Events: presence, kpml Content-Length: 382 P-Asserted-Identity: sip:635000161@SNSIP.LIFE.COM;user=phone Expires: 180
v=0 o=Z 0 0 IN IP4 10.56.42.23 s=Z c=IN IP4 10.56.42.23 t=0 0 m=audio 18274 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18275 a=ice-ufrag:MyrLrVTV a=ice-pwd:uoYbKhQTednj4xw3aF2R0ysK6R a=candidate:1zTwRqKsCajOhkZK 1 UDP 2130706431 10.56.42.23 18274 typ host a=candidate:1zTwRqKsCajOhkZK 2 UDP 2130706430 10.56.42.23 18275 typ host
================
dump from homer db
INVITE sip:1111@10.1.23.23;transport=UDP;user=phone SIP/2.0 Record-Route: sip:10.56.42.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes Record-Route: sip:10.1.23.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes Via: SIP/2.0/UDP 10.56.42.23;branch=z9hG4bK4fed.265c2242365ddb0a53289d8a3eac05a7.0 Via: SIP/2.0/UDP 10.10.206.39:5060;received=10.10.206.39;TH=div;branch=z9hG4bK-d8754z-dd463ce3ef9a0812-1---d8754z-;rport=5060 Max-Forwards: 69 Contact: sip:2222@10.10.206.39:5060;transport=UDP To: sip:1111@10.1.23.23;transport=UDP From: sip:2222@10.1.23.23;transport=UDP;tag=34ff4c7e Call-ID: Y2EyYmU5NGZiNjYxMGY3MDc0M2ZhYTU1MmNkODFjOWQ. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Content-Type: application/sdp Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Allow-Events: presence, kpml Content-Length: 382 TH: dih P-Asserted-Identity: sip:635000161@SNSIP.LIFE.COM;user=phone Expires: 180
v=0 o=Z 0 0 IN IP4 10.56.42.23 s=Z c=IN IP4 10.56.42.23 t=0 0 m=audio 18274 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18275 a=ice-ufrag:MyrLrVTV a=ice-pwd:uoYbKhQTednj4xw3aF2R0ysK6R a=candidate:1zTwRqKsCajOhkZK 1 UDP 2130706431 10.56.42.23 18274 typ host a=candidate:1zTwRqKsCajOhkZK 2 UDP 2130706430 10.56.42.23 18275 typ host -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-06 11:08 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 09:19, Sergey Basov wrote:
Sorry, not only ACK. There is ACK, INVITE, ACK and BYE
OK.
I pushed two patches to master branch that should fix the issue with the error log messages. Can you test with master branch? If all goes fine, then I will consider backporting.
For capturing the packets after topoh, more time is needed to analyze and implement if possible.
Cheers, Daniel
I am using kamailio as statefull proxy.
So in case of normal callflow there is REGISTER and so on..
And with sip_trace enabled in onsend_route errors in kamailio.log still persist.
Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <script>: onsend_route entered !!! Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023�#023�#0128*#027#0128*#024Q̌V��>
Is there any possibility do sending message via siptrace module after topoh module?
WBR
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-06 10:02 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
No other SIP requests? Only the ACK?
Cheers, Daniel
On 06/01/16 07:55, Sergey Basov wrote:
I just try it. I got only last ACK when call was finished.
I think than siptrace must catch and send duplicate message after topoh module. Because in other case we can see message as it is inside kamailio, not message that will be send to upstream or client...
WBR.
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
On 06/01/16 11:00, Sergey Basov wrote:
Thank you for patch.
I have applied patches from your commits 526fb4cdc2246284ecbd7de9ed65678da2dbe357 and 284c11ed16bdc5afcc9abf49c9f5c1749ce831e0 to kamailio 4.3.4 it was applied and build successfully.
There is no more errors in kamailio.log.
Thanks for testing and reporting back.
But Packet which is send by siptrace module to homer capture server is send before topoh modifications.
If you can correct this flow it will be great.
I will look into it as I said before.
Cheers, Daniel
Thank you.
you can see this by looking at contact header:
dump from physical interface to upstream
INVITE sip:1111@10.1.23.23;transport=UDP;user=phone SIP/2.0 Record-Route: sip:10.56.42.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes Record-Route: sip:127.0.0.8;line=sr-BRwEk.dED.d0z.z0z.zvB.afyR8vygavebZAeL7LGVeJGVz2epcMQuTfzVGwD.1Szpc01rTfOuYL Via: SIP/2.0/UDP 10.56.42.23;branch=z9hG4bK4fed.265c2242365ddb0a53289d8a3eac05a7.0 Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-s7wTDLa0zUfYZXl5zpl0zpl0z.lRD.zok.sEG.lvBJY.euwReuTfzpl0zpl0z.lRD.zokqZaxuZ9P.c3BJX01R5fO.wCZLZ3WSqMkhBqGgCceVT7G.G.epGwe.wAzh5jz37jDW7ceh52GpZKDpcSBVfSPh7qzh1E Max-Forwards: 69 Contact: sip:127.0.0.8;line=sr-BRwEk.z8zh1LGplEzhdRzsljzU8jzU8Szh10zLMKGplRzhc7BJX0B2n6BbTfYsZT To: sip:1111@10.1.23.23;transport=UDP From: sip:2222@10.1.23.23;transport=UDP;tag=34ff4c7e Call-ID: Y2EyYmU5NGZiNjYxMGY3MDc0M2ZhYTU1MmNkODFjOWQ. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Content-Type: application/sdp Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Allow-Events: presence, kpml Content-Length: 382 P-Asserted-Identity: sip:635000161@SNSIP.LIFE.COM;user=phone Expires: 180
v=0 o=Z 0 0 IN IP4 10.56.42.23 s=Z c=IN IP4 10.56.42.23 t=0 0 m=audio 18274 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18275 a=ice-ufrag:MyrLrVTV a=ice-pwd:uoYbKhQTednj4xw3aF2R0ysK6R a=candidate:1zTwRqKsCajOhkZK 1 UDP 2130706431 10.56.42.23 18274 typ host a=candidate:1zTwRqKsCajOhkZK 2 UDP 2130706430 10.56.42.23 18275 typ host
================
dump from homer db
INVITE sip:1111@10.1.23.23;transport=UDP;user=phone SIP/2.0 Record-Route: sip:10.56.42.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes Record-Route: sip:10.1.23.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes Via: SIP/2.0/UDP 10.56.42.23;branch=z9hG4bK4fed.265c2242365ddb0a53289d8a3eac05a7.0 Via: SIP/2.0/UDP 10.10.206.39:5060;received=10.10.206.39;TH=div;branch=z9hG4bK-d8754z-dd463ce3ef9a0812-1---d8754z-;rport=5060 Max-Forwards: 69 Contact: sip:2222@10.10.206.39:5060;transport=UDP To: sip:1111@10.1.23.23;transport=UDP From: sip:2222@10.1.23.23;transport=UDP;tag=34ff4c7e Call-ID: Y2EyYmU5NGZiNjYxMGY3MDc0M2ZhYTU1MmNkODFjOWQ. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Content-Type: application/sdp Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Allow-Events: presence, kpml Content-Length: 382 TH: dih P-Asserted-Identity: sip:635000161@SNSIP.LIFE.COM;user=phone Expires: 180
v=0 o=Z 0 0 IN IP4 10.56.42.23 s=Z c=IN IP4 10.56.42.23 t=0 0 m=audio 18274 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18275 a=ice-ufrag:MyrLrVTV a=ice-pwd:uoYbKhQTednj4xw3aF2R0ysK6R a=candidate:1zTwRqKsCajOhkZK 1 UDP 2130706431 10.56.42.23 18274 typ host a=candidate:1zTwRqKsCajOhkZK 2 UDP 2130706430 10.56.42.23 18275 typ host -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-06 11:08 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 09:19, Sergey Basov wrote:
Sorry, not only ACK. There is ACK, INVITE, ACK and BYE
OK.
I pushed two patches to master branch that should fix the issue with the error log messages. Can you test with master branch? If all goes fine, then I will consider backporting.
For capturing the packets after topoh, more time is needed to analyze and implement if possible.
Cheers, Daniel
I am using kamailio as statefull proxy.
So in case of normal callflow there is REGISTER and so on..
And with sip_trace enabled in onsend_route errors in kamailio.log still persist.
Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <script>: onsend_route entered !!! Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Jan 6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023�#023�#0128*#027#0128*#024Q̌V��>
Is there any possibility do sending message via siptrace module after topoh module?
WBR
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-06 10:02 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
No other SIP requests? Only the ACK?
Cheers, Daniel
On 06/01/16 07:55, Sergey Basov wrote:
I just try it. I got only last ACK when call was finished.
I think than siptrace must catch and send duplicate message after topoh module. Because in other case we can see message as it is inside kamailio, not message that will be send to upstream or client...
WBR.
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
On 06/01/16 11:49, Daniel-Constantin Mierla wrote:
[...]
But Packet which is send by siptrace module to homer capture server is send before topoh modifications.
If you can correct this flow it will be great.
I will look into it as I said before.
Can you try with master branch? I pushed a series of commits for this. You need to set siptrace modparam trace_mode to 1, then remove any use of sip_trace() function as well as setflag() with trace flag.
The receiving is after topoh does decoding at this moment, but sending should be after topoh does enconding. Going to finalize the receiving soon, but thought you may want to give it a try and report if sending is captured properly.
Cheers, Daniel
Thank you for commits.
I just try it and now I can see that sending packets captured properly..
Now there is a problem with receiving packets, I does not see Initial invite from client into the capture.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-11 23:54 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 11:49, Daniel-Constantin Mierla wrote:
[...]
But Packet which is send by siptrace module to homer capture server is send before topoh modifications.
If you can correct this flow it will be great.
I will look into it as I said before.
Can you try with master branch? I pushed a series of commits for this. You need to set siptrace modparam trace_mode to 1, then remove any use of sip_trace() function as well as setflag() with trace flag.
The receiving is after topoh does decoding at this moment, but sending should be after topoh does enconding. Going to finalize the receiving soon, but thought you may want to give it a try and report if sending is captured properly.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
I am sorry. I have missed commit 4fc969760d8eec6355ce661ccd3c5fd9ad2a36f0...
Now all works as I had expected.
Than you so match.
If you are interesting, I now try to backport changes to kamailio 4.3.4.
When it will be done I can email patch file to you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-12 10:45 GMT+02:00 Sergey Basov sergey.v.basov@gmail.com:
Thank you for commits.
I just try it and now I can see that sending packets captured properly..
Now there is a problem with receiving packets, I does not see Initial invite from client into the capture.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-11 23:54 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 11:49, Daniel-Constantin Mierla wrote:
[...]
But Packet which is send by siptrace module to homer capture server is send before topoh modifications.
If you can correct this flow it will be great.
I will look into it as I said before.
Can you try with master branch? I pushed a series of commits for this. You need to set siptrace modparam trace_mode to 1, then remove any use of sip_trace() function as well as setflag() with trace flag.
The receiving is after topoh does decoding at this moment, but sending should be after topoh does enconding. Going to finalize the receiving soon, but thought you may want to give it a try and report if sending is captured properly.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
Earlier today I pushed the patch to catch the incoming traffic before topoh gets the chance to decode it. If you can try with latest master and report the results, it will be appreciated.
Cheers, Daniel
On 12/01/16 11:02, Sergey Basov wrote:
I am sorry. I have missed commit 4fc969760d8eec6355ce661ccd3c5fd9ad2a36f0...
Now all works as I had expected.
Than you so match.
If you are interesting, I now try to backport changes to kamailio 4.3.4.
When it will be done I can email patch file to you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-12 10:45 GMT+02:00 Sergey Basov sergey.v.basov@gmail.com:
Thank you for commits.
I just try it and now I can see that sending packets captured properly..
Now there is a problem with receiving packets, I does not see Initial invite from client into the capture.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-11 23:54 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 11:49, Daniel-Constantin Mierla wrote:
[...]
But Packet which is send by siptrace module to homer capture server is send before topoh modifications.
If you can correct this flow it will be great.
I will look into it as I said before.
Can you try with master branch? I pushed a series of commits for this. You need to set siptrace modparam trace_mode to 1, then remove any use of sip_trace() function as well as setflag() with trace flag.
The receiving is after topoh does decoding at this moment, but sending should be after topoh does enconding. Going to finalize the receiving soon, but thought you may want to give it a try and report if sending is captured properly.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
Hi Daniel.
I just build with latest commit. It work as expected now. Now I can see captured packets as they was send and received by kamailio via network interfaces.
Thank you very match.
I make patch which backports your commits to kamailio 4.3.4 please find it in attach -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-13 1:06 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
Earlier today I pushed the patch to catch the incoming traffic before topoh gets the chance to decode it. If you can try with latest master and report the results, it will be appreciated.
Cheers, Daniel
On 12/01/16 11:02, Sergey Basov wrote:
I am sorry. I have missed commit 4fc969760d8eec6355ce661ccd3c5fd9ad2a36f0...
Now all works as I had expected.
Than you so match.
If you are interesting, I now try to backport changes to kamailio 4.3.4.
When it will be done I can email patch file to you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-12 10:45 GMT+02:00 Sergey Basov sergey.v.basov@gmail.com:
Thank you for commits.
I just try it and now I can see that sending packets captured properly..
Now there is a problem with receiving packets, I does not see Initial invite from client into the capture.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-11 23:54 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 11:49, Daniel-Constantin Mierla wrote:
[...]
But Packet which is send by siptrace module to homer capture server is send before topoh modifications.
If you can correct this flow it will be great.
I will look into it as I said before.
Can you try with master branch? I pushed a series of commits for this. You need to set siptrace modparam trace_mode to 1, then remove any use of sip_trace() function as well as setflag() with trace flag.
The receiving is after topoh does decoding at this moment, but sending should be after topoh does enconding. Going to finalize the receiving soon, but thought you may want to give it a try and report if sending is captured properly.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
Hi Sergey,
thanks for testing and the feedback. The patch is also useful to have around for those than want to get the feature in 4.3 by one step, not cherry picking each commit.
One more thing: are the local message properly captured? I mean the replies generated with sl_send_reply()/t_reply() as well as request such as notify or uac_req_send() (in case you have such case in your config).
Cheers, Daniel
On 13/01/16 08:38, Sergey Basov wrote:
Hi Daniel.
I just build with latest commit. It work as expected now. Now I can see captured packets as they was send and received by kamailio via network interfaces.
Thank you very match.
I make patch which backports your commits to kamailio 4.3.4 please find it in attach -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-13 1:06 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
Earlier today I pushed the patch to catch the incoming traffic before topoh gets the chance to decode it. If you can try with latest master and report the results, it will be appreciated.
Cheers, Daniel
On 12/01/16 11:02, Sergey Basov wrote:
I am sorry. I have missed commit 4fc969760d8eec6355ce661ccd3c5fd9ad2a36f0...
Now all works as I had expected.
Than you so match.
If you are interesting, I now try to backport changes to kamailio 4.3.4.
When it will be done I can email patch file to you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-12 10:45 GMT+02:00 Sergey Basov sergey.v.basov@gmail.com:
Thank you for commits.
I just try it and now I can see that sending packets captured properly..
Now there is a problem with receiving packets, I does not see Initial invite from client into the capture.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-11 23:54 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 11:49, Daniel-Constantin Mierla wrote:
[...] > But Packet which is send by siptrace module to homer capture server is > send before topoh modifications. > > If you can correct this flow it will be great. I will look into it as I said before.
Can you try with master branch? I pushed a series of commits for this. You need to set siptrace modparam trace_mode to 1, then remove any use of sip_trace() function as well as setflag() with trace flag.
The receiving is after topoh does decoding at this moment, but sending should be after topoh does enconding. Going to finalize the receiving soon, but thought you may want to give it a try and report if sending is captured properly.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
Hi Daniel.
Seems yes, it is captured properly.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-13 23:14 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
Hi Sergey,
thanks for testing and the feedback. The patch is also useful to have around for those than want to get the feature in 4.3 by one step, not cherry picking each commit.
One more thing: are the local message properly captured? I mean the replies generated with sl_send_reply()/t_reply() as well as request such as notify or uac_req_send() (in case you have such case in your config).
Cheers, Daniel
On 13/01/16 08:38, Sergey Basov wrote:
Hi Daniel.
I just build with latest commit. It work as expected now. Now I can see captured packets as they was send and received by kamailio via network interfaces.
Thank you very match.
I make patch which backports your commits to kamailio 4.3.4 please find it in attach -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-13 1:06 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
Earlier today I pushed the patch to catch the incoming traffic before topoh gets the chance to decode it. If you can try with latest master and report the results, it will be appreciated.
Cheers, Daniel
On 12/01/16 11:02, Sergey Basov wrote:
I am sorry. I have missed commit 4fc969760d8eec6355ce661ccd3c5fd9ad2a36f0...
Now all works as I had expected.
Than you so match.
If you are interesting, I now try to backport changes to kamailio 4.3.4.
When it will be done I can email patch file to you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-12 10:45 GMT+02:00 Sergey Basov sergey.v.basov@gmail.com:
Thank you for commits.
I just try it and now I can see that sending packets captured properly..
Now there is a problem with receiving packets, I does not see Initial invite from client into the capture.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-11 23:54 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 11:49, Daniel-Constantin Mierla wrote: > [...] >> But Packet which is send by siptrace module to homer capture server is >> send before topoh modifications. >> >> If you can correct this flow it will be great. > I will look into it as I said before. Can you try with master branch? I pushed a series of commits for this. You need to set siptrace modparam trace_mode to 1, then remove any use of sip_trace() function as well as setflag() with trace flag.
The receiving is after topoh does decoding at this moment, but sending should be after topoh does enconding. Going to finalize the receiving soon, but thought you may want to give it a try and report if sending is captured properly.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
You should see the received packets if you use latest master, but they are not yet captured before topoh decodes them.
Cheers, Daniel
On 12/01/16 09:45, Sergey Basov wrote:
Thank you for commits.
I just try it and now I can see that sending packets captured properly..
Now there is a problem with receiving packets, I does not see Initial invite from client into the capture.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
tel: (+38067) 403-62-54
2016-01-11 23:54 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 06/01/16 11:49, Daniel-Constantin Mierla wrote:
[...]
But Packet which is send by siptrace module to homer capture server is send before topoh modifications.
If you can correct this flow it will be great.
I will look into it as I said before.
Can you try with master branch? I pushed a series of commits for this. You need to set siptrace modparam trace_mode to 1, then remove any use of sip_trace() function as well as setflag() with trace flag.
The receiving is after topoh does decoding at this moment, but sending should be after topoh does enconding. Going to finalize the receiving soon, but thought you may want to give it a try and report if sending is captured properly.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
-
Daniel-Constantin Mierla -
Sergey Basov