Hi,
I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way.
I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table.
I opened a ticket with the details: http://sip-router.org/tracker/index.php?do=details&task_id=144&proje...
Many Thanks, Misi
Hello,
E2E ACK is getting to configuration file routing block. With the latest stable version default config file, it is handled in the route[WITHINDLG]. Be sure you call sip trace function there. This will capture the incoming E2E ACK. For outgoing version, set the flag and it should be captured in TM callback, iirc.
SL module is filtering the ACKs that are a result of negative replies sent with SL module.
Cheers, Daniel
On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály misi@niif.hu wrote:
Hi,
I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way.
I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table.
I opened a ticket with the details: http://sip-router.org/tracker/**index.php?do=details&task_id=** 144&project=1&pagenum=1http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1
Many Thanks, Misi
______________________________**_________________ 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 Daniel,
I put on setflag before WITHINDLG, so AFAIK the ACK as a new transaction is executing this step. The root of my problem is that I can see the incoming E2E ACK, but i couldn't see the "outgoing"!
route { #pike flood detection if (!pike_check_req()) { exit; };
# per request initial checks route(REQINIT);
#siptrace setflag(22); sip_trace();
xdbg("SIP Request: \n $mb \n");
# NAT detection route(NAT);
# handle requests within SIP dialogs route(WITHINDLG);
And in debug i can't find where want kamailio log/trace the _outgoing_ message. I can see only that it will be forwarded in stateless way. This is why i started to dig in sl modul. But thank You, now i see it was a mistake. sorrrrrrrry.
Sorry for the early case opening, you are right not sl causing that. I thought i find something. sorry again.
But i can see only incoming E2E ACK and I can't see the outgoing pair in siptrace. In TM modul i can't see where it is calling back siptrace in case of E2E ack.
Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 14==14 && [195.11 1.192.14] == [195.111.192.14] Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5061 matches port 5061 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:257]: No next Route HF found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:834]: no next URI found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=68 , global msg id=67 , T on entrance= 0xffffffff Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=63155, isACK=1 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_reply.c:301]: DEBUG: totag for e2e ACK found: 0 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb2954a38, callback type 4, id 0 entered Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:2437]: create_via_hf: id added: <;i=01>, rcv proto=2 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:204]: check_via_address(195.111.192.7, 195.111.192.7, 0) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:599]: Sending: ACK sip:193.225.95.130:5061;transport=tls SIP/2.0^M Via: SIP/2.0/TLS 195.111.192.14:5061;branch=0;i=01^M Via: SIP/2.0/TCP 195.111.192.7;branch=0;i=5fb^M Via: SIP/2.0/TLS 193.6.222.62:5061;bra nch=z9hG4bK2619604118-1823^M Max-Forwards: 68^M Proxy-Authorization: Digest username="niif-tartalek",realm="195.111.192.7",nonce="TkOk+05Do 8/4J70CauQqX2GiwryZl/Do",uri="sip:9999@rmx.vvc.niif.hu",response="00e9a9991a2f93c44c25de309022cee8",algorithm=md5^M From: niif-tartalek <si p:niif-tartalek@195.111.192.7>;tag=plcm_2618225217-1823;epid=8210210CA530CG^M To: sip:9999@rmx.vvc.niif.hu;tag=rmx2k_2618766049-17745-RMX -0000000006-0080871424^M Call-ID: 2618224581-1823^M CSeq: 2 ACK^M Contact: niif-tartalek <sip:niif-tartalek@193.6.222.62:5061;transport=tls >;proxy=replace;+sip.instance="urn:uuid:615fd9bb-1986-52eb-9084-681c290b7e3a"^M User-Agent:Polycom HDX 8000 HD (Release - 3.0.2-11176)^M Supported: ms-forking^M Content-Length: 0^M ^M . Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:601]: orig. len=973, new_len=918, proto=3 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2299]: tcp_send: found fd in cache ( 11, 0xb2922e88, 18) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2522]: tcp_send: sending... Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2556]: tcp_send: after real write: c= 0xb2922e88 n=949 fd=11 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2557]: tcp_send: buf= ^W^C^A^C<B0>@<B7>*<D9>^O<B5>-<D2>j<F9>N`<87> lj<F4><8B><B5>B<CE>^VC^_V<FF><F4><D4>h'<ED><CE>sU<92><F8><84>]'<AD>**<EE>H;<94>]'2|<9F><C8>^FNu<CB>!<B0><B6><FC>Y2!<9A> Ue(<E3><9E>M<88>x<8A> <C1><EF><DD>^X<A4><A3>^A<D4><D0>¬f<B1><B0><B9>y^G^] <85>?<86>@<AB><AB>We<C5><EF>4i <84>^B<F2>kf^M<8E><<A7>^<F3><D5>^U5<AE><AB><84><84><EB> <A2>+V<9A>^R<9E><90>_p<AB>^F^Z<A3>i<E0><D0>^E??<CE>^D6LN4L<82><FE>^E<EA>p<F0>6u<A3>VT<94>C9<A7>d[dL1^D<BF><86><8F>3^M<BB><96>S<A8><A3>^^?kO <F7>}Q;<<E6>M<A9>N,AE-F<9A><AE><A1>g<FB>w<95> ?^U^Q_<EF><E2><8F><EC>m&<F3>^^<EF><F4>^[<B8><91>e9#<A7>(<82>^Y<EF><83>^O{<8B><A3><B3>(K_ <EA>- <CE>^F<E3>T<DD><FA><B6><C6><C0>R<B6><AE>mhs^T^G<8F><FF><E9><<F8><8A>|i<A3>? qf<C3>^^G7<C7>ub<F0>&^R^D<C7>^R?<91><BC>uV<9D><F5>^[<F5><AF>w6 <93><98>`<B5>t7D<B1><E1><C5>^<E3>6O<FC><84><9F><F1>y<E8>!v<9F><C1>;<AD><AA>x<AA><B6>^Z<A6>P<8E>Y<BA>^<9D><A2><A6><A6><9E>3}70^K<CC>-<EA>h <DB>^R^O2<D7>H+m:<A4><F5>??<BA><9B>^<AD><B1><85><DF>c<FE><U+05FA><C0>,<87>a&^Z^U^V<A6>4<B0><A8>?<A9>?<F5>3<9E><D1>^[<E7><9D><F7>+<90>P<DA> <E7>^^<D3>WO<ED><97><EF><B4>1<BA>?1<B7><B1><9F>X Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)
Thanks, Misi
2011-08-11 15:38 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
E2E ACK is getting to configuration file routing block. With the latest stable version default config file, it is handled in the route[WITHINDLG]. Be sure you call sip trace function there. This will capture the incoming E2E ACK. For outgoing version, set the flag and it should be captured in TM callback, iirc.
SL module is filtering the ACKs that are a result of negative replies sent with SL module.
Cheers, Daniel
On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály <misi@niif.hu mailto:misi@niif.hu> wrote:
Hi, I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way. I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table. I opened a ticket with the details: http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1 <http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1> Many Thanks, Misi _______________________________________________ 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-- Daniel-Constantin Mierla http://www.asipto.com
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
Hello,
I will look to see what happens with the outgoing ACK, probably tomorrow or so. Btw, there is no need to apologize, here are open discussions, reporting issues, throwing ideas, bad or good, the conclusion comes after some analysis and help from the others. It's hard to know everything and who does not care does not participate.
Cheers, Daniel
On 8/11/11 4:32 PM, MÉSZÁROS Mihály wrote:
Hi Daniel,
I put on setflag before WITHINDLG, so AFAIK the ACK as a new transaction is executing this step. The root of my problem is that I can see the incoming E2E ACK, but i couldn't see the "outgoing"!
route { #pike flood detection if (!pike_check_req()) { exit; }; # per request initial checks route(REQINIT); #siptrace setflag(22); sip_trace(); xdbg("SIP Request: \n $mb \n"); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG);And in debug i can't find where want kamailio log/trace the _outgoing_ message. I can see only that it will be forwarded in stateless way. This is why i started to dig in sl modul. But thank You, now i see it was a mistake. sorrrrrrrry.
Sorry for the early case opening, you are right not sl causing that. I thought i find something. sorry again.
But i can see only incoming E2E ACK and I can't see the outgoing pair in siptrace. In TM modul i can't see where it is calling back siptrace in case of E2E ack.
Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 14==14 && [195.11 1.192.14] == [195.111.192.14] Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5061 matches port 5061 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:257]: No next Route HF found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:834]: no next URI found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=68 , global msg id=67 , T on entrance= 0xffffffff Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=63155, isACK=1 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_reply.c:301]: DEBUG: totag for e2e ACK found: 0 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb2954a38, callback type 4, id 0 entered Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:2437]: create_via_hf: id added: <;i=01>, rcv proto=2 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:204]: check_via_address(195.111.192.7, 195.111.192.7, 0) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:599]: Sending: ACK sip:193.225.95.130:5061;transport=tls SIP/2.0^M Via: SIP/2.0/TLS 195.111.192.14:5061;branch=0;i=01^M Via: SIP/2.0/TCP 195.111.192.7;branch=0;i=5fb^M Via: SIP/2.0/TLS 193.6.222.62:5061;bra nch=z9hG4bK2619604118-1823^M Max-Forwards: 68^M Proxy-Authorization: Digest username="niif-tartalek",realm="195.111.192.7",nonce="TkOk+05Do 8/4J70CauQqX2GiwryZl/Do",uri="sip:9999@rmx.vvc.niif.hu",response="00e9a9991a2f93c44c25de309022cee8",algorithm=md5^M From: niif-tartalek <si p:niif-tartalek@195.111.192.7>;tag=plcm_2618225217-1823;epid=8210210CA530CG^M To: <sip:9999@rmx.vvc.niif.hu>;tag=rmx2k_2618766049-17745-RMX -0000000006-0080871424^M Call-ID: 2618224581-1823^M CSeq: 2 ACK^M Contact: niif-tartalek <sip:niif-tartalek@193.6.222.62:5061;transport=tls >;proxy=replace;+sip.instance="<urn:uuid:615fd9bb-1986-52eb-9084-681c290b7e3a>"^M User-Agent:Polycom HDX 8000 HD (Release - 3.0.2-11176)^M Supported: ms-forking^M Content-Length: 0^M ^M . Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:601]: orig. len=973, new_len=918, proto=3 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2299]: tcp_send: found fd in cache ( 11, 0xb2922e88, 18) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2522]: tcp_send: sending... Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2556]: tcp_send: after real write: c= 0xb2922e88 n=949 fd=11 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2557]: tcp_send: buf= ^W^C^A^C<B0>@<B7>*<D9>^O<B5>-<D2>j<F9>N`<87> lj<F4><8B><B5>B<CE>^VC^_V<FF><F4><D4>h'<ED><CE>sU<92><F8><84>]'<AD>**<EE>H;<94>]'2|<9F><C8>^FNu<CB>!<B0><B6><FC>Y2!<9A> Ue(<E3><9E>M<88>x<8A> <C1><EF><DD>^X<A4><A3>^A<D4><D0>¬f<B1><B0><B9>y^G^] <85>?<86>@<AB><AB>We<C5><EF>4i <84>^B<F2>kf^M<8E><<A7>^\<F3><D5>^U5<AE><AB><84><84><EB> <A2>+V<9A>^R<9E><90>_p<AB>^F^Z<A3>i<E0><D0>^E??<CE>^D6LN4L<82><FE>^E<EA>p<F0>6u<A3>VT<94>C9<A7>d[dL1^D<BF><86><8F>3^M<BB><96>S<A8><A3>^^?kO <F7>}Q;<<E6>M<A9>N,AE-F<9A><AE><A1>g<FB>w<95> ?^U^Q_<EF><E2><8F><EC>m&<F3>^^<EF><F4>^[<B8><91>e9#<A7>(<82>^Y<EF><83>^O{<8B><A3><B3>(K_ <EA>- <CE>^F<E3>T<DD><FA><B6><C6><C0>R<B6><AE>mhs^T^G<8F><FF><E9><<F8><8A>|i<A3>? qf<C3>^^G7<C7>ub<F0>&^R^D<C7>^R?<91><BC>uV<9D><F5>^[<F5><AF>w6 <93><98>`<B5>t7D<B1><E1><C5>^\<E3>6O<FC><84><9F><F1>y<E8>!v<9F><C1>;<AD><AA>x<AA><B6>^Z<A6>P<8E>Y<BA>^\<9D><A2><A6><A6><9E>3}70^K<CC>-<EA>h <DB>^R^O2<D7>H+m:<A4><F5>??<BA><9B>^\<AD><B1><85><DF>c<FE><U+05FA><C0>,<87>a&^Z^U^V<A6>4<B0><A8>?<A9>?<F5>3<9E><D1>^[<E7><9D><F7>+<90>P<DA> <E7>^^<D3>WO<ED><97><EF><B4>1<BA>?1<B7><B1><9F>X Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)Thanks, Misi
2011-08-11 15:38 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
E2E ACK is getting to configuration file routing block. With the latest stable version default config file, it is handled in the route[WITHINDLG]. Be sure you call sip trace function there. This will capture the incoming E2E ACK. For outgoing version, set the flag and it should be captured in TM callback, iirc.
SL module is filtering the ACKs that are a result of negative replies sent with SL module.
Cheers, Daniel
On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály <misi@niif.hu mailto:misi@niif.hu> wrote:
Hi, I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way. I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table. I opened a ticket with the details: http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1 <http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1> Many Thanks, Misi _______________________________________________ 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-- Daniel-Constantin Mierla http://www.asipto.com
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
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
Hello Daniel,
I appreciate highly your help!
Cheers, Misi
2011-08-11 20:41 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I will look to see what happens with the outgoing ACK, probably tomorrow or so. Btw, there is no need to apologize, here are open discussions, reporting issues, throwing ideas, bad or good, the conclusion comes after some analysis and help from the others. It's hard to know everything and who does not care does not participate.
Cheers, Daniel
On 8/11/11 4:32 PM, MÉSZÁROS Mihály wrote:
Hi Daniel,
I put on setflag before WITHINDLG, so AFAIK the ACK as a new transaction is executing this step. The root of my problem is that I can see the incoming E2E ACK, but i couldn't see the "outgoing"!
route { #pike flood detection if (!pike_check_req()) { exit; }; # per request initial checks route(REQINIT); #siptrace setflag(22); sip_trace(); xdbg("SIP Request: \n $mb \n"); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG);And in debug i can't find where want kamailio log/trace the _outgoing_ message. I can see only that it will be forwarded in stateless way. This is why i started to dig in sl modul. But thank You, now i see it was a mistake. sorrrrrrrry.
Sorry for the early case opening, you are right not sl causing that. I thought i find something. sorry again.
But i can see only incoming E2E ACK and I can't see the outgoing pair in siptrace. In TM modul i can't see where it is calling back siptrace in case of E2E ack.
Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 14==14 && [195.11 1.192.14] == [195.111.192.14] Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5061 matches port 5061 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:257]: No next Route HF found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:834]: no next URI found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=68 , global msg id=67 , T on entrance= 0xffffffff Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=63155, isACK=1 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_reply.c:301]: DEBUG: totag for e2e ACK found: 0 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb2954a38, callback type 4, id 0 entered Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:2437]: create_via_hf: id added: <;i=01>, rcv proto=2 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:204]: check_via_address(195.111.192.7, 195.111.192.7, 0) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:599]: Sending: ACK sip:193.225.95.130:5061;transport=tls SIP/2.0^M Via: SIP/2.0/TLS 195.111.192.14:5061;branch=0;i=01^M Via: SIP/2.0/TCP 195.111.192.7;branch=0;i=5fb^M Via: SIP/2.0/TLS 193.6.222.62:5061;bra nch=z9hG4bK2619604118-1823^M Max-Forwards: 68^M Proxy-Authorization: Digest username="niif-tartalek",realm="195.111.192.7",nonce="TkOk+05Do 8/4J70CauQqX2GiwryZl/Do",uri="sip:9999@rmx.vvc.niif.hu",response="00e9a9991a2f93c44c25de309022cee8",algorithm=md5^M From: niif-tartalek <si p:niif-tartalek@195.111.192.7>;tag=plcm_2618225217-1823;epid=8210210CA530CG^M To: <sip:9999@rmx.vvc.niif.hu>;tag=rmx2k_2618766049-17745-RMX -0000000006-0080871424^M Call-ID: 2618224581-1823^M CSeq: 2 ACK^M Contact: niif-tartalek <sip:niif-tartalek@193.6.222.62:5061;transport=tls >;proxy=replace;+sip.instance="<urn:uuid:615fd9bb-1986-52eb-9084-681c290b7e3a>"^M User-Agent:Polycom HDX 8000 HD (Release - 3.0.2-11176)^M Supported: ms-forking^M Content-Length: 0^M ^M . Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:601]: orig. len=973, new_len=918, proto=3 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2299]: tcp_send: found fd in cache ( 11, 0xb2922e88, 18) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2522]: tcp_send: sending... Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2556]: tcp_send: after real write: c= 0xb2922e88 n=949 fd=11 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2557]: tcp_send: buf= ^W^C^A^C<B0>@<B7>*<D9>^O<B5>-<D2>j<F9>N`<87> lj<F4><8B><B5>B<CE>^VC^_V<FF><F4><D4>h'<ED><CE>sU<92><F8><84>]'<AD>**<EE>H;<94>]'2|<9F><C8>^FNu<CB>!<B0><B6><FC>Y2!<9A> Ue(<E3><9E>M<88>x<8A> <C1><EF><DD>^X<A4><A3>^A<D4><D0>¬f<B1><B0><B9>y^G^] <85>?<86>@<AB><AB>We<C5><EF>4i <84>^B<F2>kf^M<8E><<A7>^\<F3><D5>^U5<AE><AB><84><84><EB> <A2>+V<9A>^R<9E><90>_p<AB>^F^Z<A3>i<E0><D0>^E??<CE>^D6LN4L<82><FE>^E<EA>p<F0>6u<A3>VT<94>C9<A7>d[dL1^D<BF><86><8F>3^M<BB><96>S<A8><A3>^^?kO <F7>}Q;<<E6>M<A9>N,AE-F<9A><AE><A1>g<FB>w<95> ?^U^Q_<EF><E2><8F><EC>m&<F3>^^<EF><F4>^[<B8><91>e9#<A7>(<82>^Y<EF><83>^O{<8B><A3><B3>(K_ <EA>- <CE>^F<E3>T<DD><FA><B6><C6><C0>R<B6><AE>mhs^T^G<8F><FF><E9><<F8><8A>|i<A3>? qf<C3>^^G7<C7>ub<F0>&^R^D<C7>^R?<91><BC>uV<9D><F5>^[<F5><AF>w6 <93><98>`<B5>t7D<B1><E1><C5>^\<E3>6O<FC><84><9F><F1>y<E8>!v<9F><C1>;<AD><AA>x<AA><B6>^Z<A6>P<8E>Y<BA>^\<9D><A2><A6><A6><9E>3}70^K<CC>-<EA>h <DB>^R^O2<D7>H+m:<A4><F5>??<BA><9B>^\<AD><B1><85><DF>c<FE><U+05FA><C0>,<87>a&^Z^U^V<A6>4<B0><A8>?<A9>?<F5>3<9E><D1>^[<E7><9D><F7>+<90>P<DA> <E7>^^<D3>WO<ED><97><EF><B4>1<BA>?1<B7><B1><9F>X Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)Thanks, Misi
2011-08-11 15:38 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
E2E ACK is getting to configuration file routing block. With the latest stable version default config file, it is handled in the route[WITHINDLG]. Be sure you call sip trace function there. This will capture the incoming E2E ACK. For outgoing version, set the flag and it should be captured in TM callback, iirc.
SL module is filtering the ACKs that are a result of negative replies sent with SL module.
Cheers, Daniel
On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály <misi@niif.hu mailto:misi@niif.hu> wrote:
Hi, I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way. I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table. I opened a ticket with the details: http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1 <http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1> Many Thanks, Misi _______________________________________________ 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-- Daniel-Constantin Mierla http://www.asipto.com
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
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
Hello,
ok, seems that there is no actual callback for outgoing ACK -- the same seems to be in 1.x, based on a quick look there -- the callback for TM outgoing requests is useless since the ACK is forwarded in stateless mode.
The great thing with 3.x is that we have onsend_route where the outgoing message content is available, so I just need to code a bit in siptrace module and have it working properly to store the outgoing ACKs. I will try to do it asap.
Cheers, Daniel
On 8/11/11 9:23 PM, MÉSZÁROS Mihály wrote:
Hello Daniel,
I appreciate highly your help!
Cheers, Misi
2011-08-11 20:41 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I will look to see what happens with the outgoing ACK, probably tomorrow or so. Btw, there is no need to apologize, here are open discussions, reporting issues, throwing ideas, bad or good, the conclusion comes after some analysis and help from the others. It's hard to know everything and who does not care does not participate.
Cheers, Daniel
On 8/11/11 4:32 PM, MÉSZÁROS Mihály wrote:
Hi Daniel,
I put on setflag before WITHINDLG, so AFAIK the ACK as a new transaction is executing this step. The root of my problem is that I can see the incoming E2E ACK, but i couldn't see the "outgoing"!
route { #pike flood detection if (!pike_check_req()) { exit; }; # per request initial checks route(REQINIT); #siptrace setflag(22); sip_trace(); xdbg("SIP Request: \n $mb \n"); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG);And in debug i can't find where want kamailio log/trace the _outgoing_ message. I can see only that it will be forwarded in stateless way. This is why i started to dig in sl modul. But thank You, now i see it was a mistake. sorrrrrrrry.
Sorry for the early case opening, you are right not sl causing that. I thought i find something. sorry again.
But i can see only incoming E2E ACK and I can't see the outgoing pair in siptrace. In TM modul i can't see where it is calling back siptrace in case of E2E ack.
Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 14==14 && [195.11 1.192.14] == [195.111.192.14] Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5061 matches port 5061 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:257]: No next Route HF found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:834]: no next URI found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=68 , global msg id=67 , T on entrance= 0xffffffff Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=63155, isACK=1 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_reply.c:301]: DEBUG: totag for e2e ACK found: 0 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb2954a38, callback type 4, id 0 entered Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:2437]: create_via_hf: id added: <;i=01>, rcv proto=2 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:204]: check_via_address(195.111.192.7, 195.111.192.7, 0) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:599]: Sending: ACK sip:193.225.95.130:5061;transport=tls SIP/2.0^M Via: SIP/2.0/TLS 195.111.192.14:5061;branch=0;i=01^M Via: SIP/2.0/TCP 195.111.192.7;branch=0;i=5fb^M Via: SIP/2.0/TLS 193.6.222.62:5061;bra nch=z9hG4bK2619604118-1823^M Max-Forwards: 68^M Proxy-Authorization: Digest username="niif-tartalek",realm="195.111.192.7",nonce="TkOk+05Do 8/4J70CauQqX2GiwryZl/Do",uri="sip:9999@rmx.vvc.niif.hu",response="00e9a9991a2f93c44c25de309022cee8",algorithm=md5^M From: niif-tartalek <si p:niif-tartalek@195.111.192.7>;tag=plcm_2618225217-1823;epid=8210210CA530CG^M To: <sip:9999@rmx.vvc.niif.hu>;tag=rmx2k_2618766049-17745-RMX -0000000006-0080871424^M Call-ID: 2618224581-1823^M CSeq: 2 ACK^M Contact: niif-tartalek <sip:niif-tartalek@193.6.222.62:5061;transport=tls >;proxy=replace;+sip.instance="<urn:uuid:615fd9bb-1986-52eb-9084-681c290b7e3a>"^M User-Agent:Polycom HDX 8000 HD (Release - 3.0.2-11176)^M Supported: ms-forking^M Content-Length: 0^M ^M . Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:601]: orig. len=973, new_len=918, proto=3 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2299]: tcp_send: found fd in cache ( 11, 0xb2922e88, 18) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2522]: tcp_send: sending... Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2556]: tcp_send: after real write: c= 0xb2922e88 n=949 fd=11 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2557]: tcp_send: buf= ^W^C^A^C<B0>@<B7>*<D9>^O<B5>-<D2>j<F9>N`<87> lj<F4><8B><B5>B<CE>^VC^_V<FF><F4><D4>h'<ED><CE>sU<92><F8><84>]'<AD>**<EE>H;<94>]'2|<9F><C8>^FNu<CB>!<B0><B6><FC>Y2!<9A> Ue(<E3><9E>M<88>x<8A> <C1><EF><DD>^X<A4><A3>^A<D4><D0>¬f<B1><B0><B9>y^G^] <85>?<86>@<AB><AB>We<C5><EF>4i <84>^B<F2>kf^M<8E><<A7>^\<F3><D5>^U5<AE><AB><84><84><EB> <A2>+V<9A>^R<9E><90>_p<AB>^F^Z<A3>i<E0><D0>^E??<CE>^D6LN4L<82><FE>^E<EA>p<F0>6u<A3>VT<94>C9<A7>d[dL1^D<BF><86><8F>3^M<BB><96>S<A8><A3>^^?kO <F7>}Q;<<E6>M<A9>N,AE-F<9A><AE><A1>g<FB>w<95> ?^U^Q_<EF><E2><8F><EC>m&<F3>^^<EF><F4>^[<B8><91>e9#<A7>(<82>^Y<EF><83>^O{<8B><A3><B3>(K_ <EA>- <CE>^F<E3>T<DD><FA><B6><C6><C0>R<B6><AE>mhs^T^G<8F><FF><E9><<F8><8A>|i<A3>? qf<C3>^^G7<C7>ub<F0>&^R^D<C7>^R?<91><BC>uV<9D><F5>^[<F5><AF>w6 <93><98>`<B5>t7D<B1><E1><C5>^\<E3>6O<FC><84><9F><F1>y<E8>!v<9F><C1>;<AD><AA>x<AA><B6>^Z<A6>P<8E>Y<BA>^\<9D><A2><A6><A6><9E>3}70^K<CC>-<EA>h <DB>^R^O2<D7>H+m:<A4><F5>??<BA><9B>^\<AD><B1><85><DF>c<FE><U+05FA><C0>,<87>a&^Z^U^V<A6>4<B0><A8>?<A9>?<F5>3<9E><D1>^[<E7><9D><F7>+<90>P<DA> <E7>^^<D3>WO<ED><97><EF><B4>1<BA>?1<B7><B1><9F>X Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)Thanks, Misi
2011-08-11 15:38 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
E2E ACK is getting to configuration file routing block. With the latest stable version default config file, it is handled in the route[WITHINDLG]. Be sure you call sip trace function there. This will capture the incoming E2E ACK. For outgoing version, set the flag and it should be captured in TM callback, iirc.
SL module is filtering the ACKs that are a result of negative replies sent with SL module.
Cheers, Daniel
On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály <misi@niif.hu mailto:misi@niif.hu> wrote:
Hi, I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way. I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table. I opened a ticket with the details: http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1 <http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1> Many Thanks, Misi _______________________________________________ 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-- Daniel-Constantin Mierla http://www.asipto.com
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
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
Hi Daniel,
Thank you for looking after the issue. Am I understand you correctly: You mean that it couldn't be corrected (or it is not the right solution) in TM to have a callback to messages what are sent out stateless way, and correct the issue in this way. So you mean I will have to add siptrace to call logic in config file to route block onsend_route?
I am looking forward to hear about the fix, after you will be ready with it.
Many Thanks, Misi
On 2011-08-12 15:25, Daniel-Constantin Mierla wrote:
Hello,
ok, seems that there is no actual callback for outgoing ACK -- the same seems to be in 1.x, based on a quick look there -- the callback for TM outgoing requests is useless since the ACK is forwarded in stateless mode.
The great thing with 3.x is that we have onsend_route where the outgoing message content is available, so I just need to code a bit in siptrace module and have it working properly to store the outgoing ACKs. I will try to do it asap.
Cheers, Daniel
On 8/11/11 9:23 PM, MÉSZÁROS Mihály wrote:
Hello Daniel,
I appreciate highly your help!
Cheers, Misi
2011-08-11 20:41 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I will look to see what happens with the outgoing ACK, probably tomorrow or so. Btw, there is no need to apologize, here are open discussions, reporting issues, throwing ideas, bad or good, the conclusion comes after some analysis and help from the others. It's hard to know everything and who does not care does not participate.
Cheers, Daniel
On 8/11/11 4:32 PM, MÉSZÁROS Mihály wrote:
Hi Daniel,
I put on setflag before WITHINDLG, so AFAIK the ACK as a new transaction is executing this step. The root of my problem is that I can see the incoming E2E ACK, but i couldn't see the "outgoing"!
route { #pike flood detection if (!pike_check_req()) { exit; }; # per request initial checks route(REQINIT); #siptrace setflag(22); sip_trace(); xdbg("SIP Request: \n $mb \n"); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG);And in debug i can't find where want kamailio log/trace the _outgoing_ message. I can see only that it will be forwarded in stateless way. This is why i started to dig in sl modul. But thank You, now i see it was a mistake. sorrrrrrrry.
Sorry for the early case opening, you are right not sl causing that. I thought i find something. sorry again.
But i can see only incoming E2E ACK and I can't see the outgoing pair in siptrace. In TM modul i can't see where it is calling back siptrace in case of E2E ack.
Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 14==14 && [195.11 1.192.14] == [195.111.192.14] Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5061 matches port 5061 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:257]: No next Route HF found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:834]: no next URI found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=68 , global msg id=67 , T on entrance= 0xffffffff Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=63155, isACK=1 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_reply.c:301]: DEBUG: totag for e2e ACK found: 0 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb2954a38, callback type 4, id 0 entered Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:2437]: create_via_hf: id added: <;i=01>, rcv proto=2 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:204]: check_via_address(195.111.192.7, 195.111.192.7, 0) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:599]: Sending: ACK sip:193.225.95.130:5061;transport=tls SIP/2.0^M Via: SIP/2.0/TLS 195.111.192.14:5061;branch=0;i=01^M Via: SIP/2.0/TCP 195.111.192.7;branch=0;i=5fb^M Via: SIP/2.0/TLS 193.6.222.62:5061;bra nch=z9hG4bK2619604118-1823^M Max-Forwards: 68^M Proxy-Authorization: Digest username="niif-tartalek",realm="195.111.192.7",nonce="TkOk+05Do 8/4J70CauQqX2GiwryZl/Do",uri="sip:9999@rmx.vvc.niif.hu",response="00e9a9991a2f93c44c25de309022cee8",algorithm=md5^M From: niif-tartalek <si p:niif-tartalek@195.111.192.7>;tag=plcm_2618225217-1823;epid=8210210CA530CG^M To: <sip:9999@rmx.vvc.niif.hu>;tag=rmx2k_2618766049-17745-RMX -0000000006-0080871424^M Call-ID: 2618224581-1823^M CSeq: 2 ACK^M Contact: niif-tartalek <sip:niif-tartalek@193.6.222.62:5061;transport=tls >;proxy=replace;+sip.instance="<urn:uuid:615fd9bb-1986-52eb-9084-681c290b7e3a>"^M User-Agent:Polycom HDX 8000 HD (Release - 3.0.2-11176)^M Supported: ms-forking^M Content-Length: 0^M ^M . Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:601]: orig. len=973, new_len=918, proto=3 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2299]: tcp_send: found fd in cache ( 11, 0xb2922e88, 18) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2522]: tcp_send: sending... Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2556]: tcp_send: after real write: c= 0xb2922e88 n=949 fd=11 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2557]: tcp_send: buf= ^W^C^A^C<B0>@<B7>*<D9>^O<B5>-<D2>j<F9>N`<87> lj<F4><8B><B5>B<CE>^VC^_V<FF><F4><D4>h'<ED><CE>sU<92><F8><84>]'<AD>**<EE>H;<94>]'2|<9F><C8>^FNu<CB>!<B0><B6><FC>Y2!<9A> Ue(<E3><9E>M<88>x<8A> <C1><EF><DD>^X<A4><A3>^A<D4><D0>¬f<B1><B0><B9>y^G^] <85>?<86>@<AB><AB>We<C5><EF>4i <84>^B<F2>kf^M<8E><<A7>^\<F3><D5>^U5<AE><AB><84><84><EB> <A2>+V<9A>^R<9E><90>_p<AB>^F^Z<A3>i<E0><D0>^E??<CE>^D6LN4L<82><FE>^E<EA>p<F0>6u<A3>VT<94>C9<A7>d[dL1^D<BF><86><8F>3^M<BB><96>S<A8><A3>^^?kO <F7>}Q;<<E6>M<A9>N,AE-F<9A><AE><A1>g<FB>w<95> ?^U^Q_<EF><E2><8F><EC>m&<F3>^^<EF><F4>^[<B8><91>e9#<A7>(<82>^Y<EF><83>^O{<8B><A3><B3>(K_ <EA>- <CE>^F<E3>T<DD><FA><B6><C6><C0>R<B6><AE>mhs^T^G<8F><FF><E9><<F8><8A>|i<A3>? qf<C3>^^G7<C7>ub<F0>&^R^D<C7>^R?<91><BC>uV<9D><F5>^[<F5><AF>w6 <93><98>`<B5>t7D<B1><E1><C5>^\<E3>6O<FC><84><9F><F1>y<E8>!v<9F><C1>;<AD><AA>x<AA><B6>^Z<A6>P<8E>Y<BA>^\<9D><A2><A6><A6><9E>3}70^K<CC>-<EA>h <DB>^R^O2<D7>H+m:<A4><F5>??<BA><9B>^\<AD><B1><85><DF>c<FE><U+05FA><C0>,<87>a&^Z^U^V<A6>4<B0><A8>?<A9>?<F5>3<9E><D1>^[<E7><9D><F7>+<90>P<DA> <E7>^^<D3>WO<ED><97><EF><B4>1<BA>?1<B7><B1><9F>X Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)Thanks, Misi
2011-08-11 15:38 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
E2E ACK is getting to configuration file routing block. With the latest stable version default config file, it is handled in the route[WITHINDLG]. Be sure you call sip trace function there. This will capture the incoming E2E ACK. For outgoing version, set the flag and it should be captured in TM callback, iirc.
SL module is filtering the ACKs that are a result of negative replies sent with SL module.
Cheers, Daniel
On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály <misi@niif.hu mailto:misi@niif.hu> wrote:
Hi, I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way. I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table. I opened a ticket with the details: http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1 <http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1> Many Thanks, Misi _______________________________________________ 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-- Daniel-Constantin Mierla http://www.asipto.com
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
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
-- 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
Hello,
I have committed the feature to be able to use sip_trace() from onsend_route, therefore you can catch forwarded ACKs:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9d8df252...
An example of usage would be:
onsend_route { if(method==ACK") sip_trace(); }
Let me know if it works.
Cheers, Daniel
On 8/13/11 9:46 PM, Mészáros Mihály wrote:
Hi Daniel,
Thank you for looking after the issue. Am I understand you correctly: You mean that it couldn't be corrected (or it is not the right solution) in TM to have a callback to messages what are sent out stateless way, and correct the issue in this way. So you mean I will have to add siptrace to call logic in config file to route block onsend_route?
I am looking forward to hear about the fix, after you will be ready with it.
Many Thanks, Misi
On 2011-08-12 15:25, Daniel-Constantin Mierla wrote:
Hello,
ok, seems that there is no actual callback for outgoing ACK -- the same seems to be in 1.x, based on a quick look there -- the callback for TM outgoing requests is useless since the ACK is forwarded in stateless mode.
The great thing with 3.x is that we have onsend_route where the outgoing message content is available, so I just need to code a bit in siptrace module and have it working properly to store the outgoing ACKs. I will try to do it asap.
Cheers, Daniel
On 8/11/11 9:23 PM, MÉSZÁROS Mihály wrote:
Hello Daniel,
I appreciate highly your help!
Cheers, Misi
2011-08-11 20:41 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I will look to see what happens with the outgoing ACK, probably tomorrow or so. Btw, there is no need to apologize, here are open discussions, reporting issues, throwing ideas, bad or good, the conclusion comes after some analysis and help from the others. It's hard to know everything and who does not care does not participate.
Cheers, Daniel
On 8/11/11 4:32 PM, MÉSZÁROS Mihály wrote:
Hi Daniel,
I put on setflag before WITHINDLG, so AFAIK the ACK as a new transaction is executing this step. The root of my problem is that I can see the incoming E2E ACK, but i couldn't see the "outgoing"!
route { #pike flood detection if (!pike_check_req()) { exit; }; # per request initial checks route(REQINIT); #siptrace setflag(22); sip_trace(); xdbg("SIP Request: \n $mb \n"); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG);And in debug i can't find where want kamailio log/trace the _outgoing_ message. I can see only that it will be forwarded in stateless way. This is why i started to dig in sl modul. But thank You, now i see it was a mistake. sorrrrrrrry.
Sorry for the early case opening, you are right not sl causing that. I thought i find something. sorry again.
But i can see only incoming E2E ACK and I can't see the outgoing pair in siptrace. In TM modul i can't see where it is calling back siptrace in case of E2E ack.
Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 14==14 && [195.11 1.192.14] == [195.111.192.14] Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5061 matches port 5061 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:257]: No next Route HF found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:834]: no next URI found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=68 , global msg id=67 , T on entrance= 0xffffffff Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=63155, isACK=1 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_reply.c:301]: DEBUG: totag for e2e ACK found: 0 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb2954a38, callback type 4, id 0 entered Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:2437]: create_via_hf: id added: <;i=01>, rcv proto=2 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:204]: check_via_address(195.111.192.7, 195.111.192.7, 0) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:599]: Sending: ACK sip:193.225.95.130:5061;transport=tls SIP/2.0^M Via: SIP/2.0/TLS 195.111.192.14:5061;branch=0;i=01^M Via: SIP/2.0/TCP 195.111.192.7;branch=0;i=5fb^M Via: SIP/2.0/TLS 193.6.222.62:5061;bra nch=z9hG4bK2619604118-1823^M Max-Forwards: 68^M Proxy-Authorization: Digest username="niif-tartalek",realm="195.111.192.7",nonce="TkOk+05Do 8/4J70CauQqX2GiwryZl/Do",uri="sip:9999@rmx.vvc.niif.hu",response="00e9a9991a2f93c44c25de309022cee8",algorithm=md5^M From: niif-tartalek <si p:niif-tartalek@195.111.192.7>;tag=plcm_2618225217-1823;epid=8210210CA530CG^M To: <sip:9999@rmx.vvc.niif.hu>;tag=rmx2k_2618766049-17745-RMX -0000000006-0080871424^M Call-ID: 2618224581-1823^M CSeq: 2 ACK^M Contact: niif-tartalek <sip:niif-tartalek@193.6.222.62:5061;transport=tls >;proxy=replace;+sip.instance="<urn:uuid:615fd9bb-1986-52eb-9084-681c290b7e3a>"^M User-Agent:Polycom HDX 8000 HD (Release - 3.0.2-11176)^M Supported: ms-forking^M Content-Length: 0^M ^M . Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:601]: orig. len=973, new_len=918, proto=3 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2299]: tcp_send: found fd in cache ( 11, 0xb2922e88, 18) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2522]: tcp_send: sending... Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2556]: tcp_send: after real write: c= 0xb2922e88 n=949 fd=11 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2557]: tcp_send: buf= ^W^C^A^C<B0>@<B7>*<D9>^O<B5>-<D2>j<F9>N`<87> lj<F4><8B><B5>B<CE>^VC^_V<FF><F4><D4>h'<ED><CE>sU<92><F8><84>]'<AD>**<EE>H;<94>]'2|<9F><C8>^FNu<CB>!<B0><B6><FC>Y2!<9A> Ue(<E3><9E>M<88>x<8A> <C1><EF><DD>^X<A4><A3>^A<D4><D0>¬f<B1><B0><B9>y^G^] <85>?<86>@<AB><AB>We<C5><EF>4i <84>^B<F2>kf^M<8E><<A7>^\<F3><D5>^U5<AE><AB><84><84><EB> <A2>+V<9A>^R<9E><90>_p<AB>^F^Z<A3>i<E0><D0>^E??<CE>^D6LN4L<82><FE>^E<EA>p<F0>6u<A3>VT<94>C9<A7>d[dL1^D<BF><86><8F>3^M<BB><96>S<A8><A3>^^?kO <F7>}Q;<<E6>M<A9>N,AE-F<9A><AE><A1>g<FB>w<95> ?^U^Q_<EF><E2><8F><EC>m&<F3>^^<EF><F4>^[<B8><91>e9#<A7>(<82>^Y<EF><83>^O{<8B><A3><B3>(K_ <EA>- <CE>^F<E3>T<DD><FA><B6><C6><C0>R<B6><AE>mhs^T^G<8F><FF><E9><<F8><8A>|i<A3>? qf<C3>^^G7<C7>ub<F0>&^R^D<C7>^R?<91><BC>uV<9D><F5>^[<F5><AF>w6 <93><98>`<B5>t7D<B1><E1><C5>^\<E3>6O<FC><84><9F><F1>y<E8>!v<9F><C1>;<AD><AA>x<AA><B6>^Z<A6>P<8E>Y<BA>^\<9D><A2><A6><A6><9E>3}70^K<CC>-<EA>h <DB>^R^O2<D7>H+m:<A4><F5>??<BA><9B>^\<AD><B1><85><DF>c<FE><U+05FA><C0>,<87>a&^Z^U^V<A6>4<B0><A8>?<A9>?<F5>3<9E><D1>^[<E7><9D><F7>+<90>P<DA> <E7>^^<D3>WO<ED><97><EF><B4>1<BA>?1<B7><B1><9F>X Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)Thanks, Misi
2011-08-11 15:38 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
E2E ACK is getting to configuration file routing block. With the latest stable version default config file, it is handled in the route[WITHINDLG]. Be sure you call sip trace function there. This will capture the incoming E2E ACK. For outgoing version, set the flag and it should be captured in TM callback, iirc.
SL module is filtering the ACKs that are a result of negative replies sent with SL module.
Cheers, Daniel
On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály <misi@niif.hu mailto:misi@niif.hu> wrote:
Hi, I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way. I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table. I opened a ticket with the details: http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1 <http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1> Many Thanks, Misi _______________________________________________ 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-- Daniel-Constantin Mierla http://www.asipto.com
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
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
-- 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
Hi Daniel!
Thank You very much! I tested it, and it seems to be working for me!
Only one typo what i corrected. You have missed out the beginning " from your example. if(method==ACK") sip_trace();
Thank you again!
By the way two problems with git HEAD. I checked out the current git HEAD, and I have experienced these two problems:
1. modul purple is not compiled for me. hal:/usr/local/src/sip-router/modules_k/purple# make CC (gcc) [M purple.so] clientpipe.o In file included from purple.h:23, from clientpipe.c:28: /usr/include/libpurple/status.h:93: error: expected specifier-qualifier-list before 'gpointer' make: *** [clientpipe.o] Error 1
2. htable-create.sql MYSQL table create is giving back error. The problem is VARCHAR without length.
diff --git a/utils/kamctl/mysql/htable-create.sql b/utils/kamctl/mysql/htable-create.sql index 6adfa48..79eb43b 100644 --- a/utils/kamctl/mysql/htable-create.sql +++ b/utils/kamctl/mysql/htable-create.sql @@ -5,6 +5,6 @@ CREATE TABLE htable ( key_type INT DEFAULT 0 NOT NULL, value_type INT DEFAULT 0 NOT NULL, key_value VARCHAR(128) DEFAULT '' NOT NULL, - expires VARCHAR DEFAULT 0 NOT NULL + expires VARCHAR(128) DEFAULT 0 NOT NULL ) ENGINE=MyISAM;
Cheers, Misi
2011-08-17 12:09 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I have committed the feature to be able to use sip_trace() from onsend_route, therefore you can catch forwarded ACKs:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9d8df252...
An example of usage would be:
onsend_route {
}
Let me know if it works.
Cheers, Daniel
On 8/13/11 9:46 PM, Mészáros Mihály wrote:
Hi Daniel,
Thank you for looking after the issue. Am I understand you correctly: You mean that it couldn't be corrected (or it is not the right solution) in TM to have a callback to messages what are sent out stateless way, and correct the issue in this way. So you mean I will have to add siptrace to call logic in config file to route block onsend_route?
I am looking forward to hear about the fix, after you will be ready with it.
Many Thanks, Misi
On 2011-08-12 15:25, Daniel-Constantin Mierla wrote:
Hello,
ok, seems that there is no actual callback for outgoing ACK -- the same seems to be in 1.x, based on a quick look there -- the callback for TM outgoing requests is useless since the ACK is forwarded in stateless mode.
The great thing with 3.x is that we have onsend_route where the outgoing message content is available, so I just need to code a bit in siptrace module and have it working properly to store the outgoing ACKs. I will try to do it asap.
Cheers, Daniel
On 8/11/11 9:23 PM, MÉSZÁROS Mihály wrote:
Hello Daniel,
I appreciate highly your help!
Cheers, Misi
2011-08-11 20:41 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I will look to see what happens with the outgoing ACK, probably tomorrow or so. Btw, there is no need to apologize, here are open discussions, reporting issues, throwing ideas, bad or good, the conclusion comes after some analysis and help from the others. It's hard to know everything and who does not care does not participate.
Cheers, Daniel
On 8/11/11 4:32 PM, MÉSZÁROS Mihály wrote:
Hi Daniel,
I put on setflag before WITHINDLG, so AFAIK the ACK as a new transaction is executing this step. The root of my problem is that I can see the incoming E2E ACK, but i couldn't see the "outgoing"!
route { #pike flood detection if (!pike_check_req()) { exit; }; # per request initial checks route(REQINIT); #siptrace setflag(22); sip_trace(); xdbg("SIP Request: \n $mb \n"); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG);And in debug i can't find where want kamailio log/trace the _outgoing_ message. I can see only that it will be forwarded in stateless way. This is why i started to dig in sl modul. But thank You, now i see it was a mistake. sorrrrrrrry.
Sorry for the early case opening, you are right not sl causing that. I thought i find something. sorry again.
But i can see only incoming E2E ACK and I can't see the outgoing pair in siptrace. In TM modul i can't see where it is calling back siptrace in case of E2E ack.
Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 14==14 && [195.11 1.192.14] == [195.111.192.14] Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5061 matches port 5061 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:257]: No next Route HF found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr [loose.c:834]: no next URI found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=68 , global msg id=67 , T on entrance= 0xffffffff Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=63155, isACK=1 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_reply.c:301]: DEBUG: totag for e2e ACK found: 0 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb2954a38, callback type 4, id 0 entered Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:2437]: create_via_hf: id added: <;i=01>, rcv proto=2 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [msg_translator.c:204]: check_via_address(195.111.192.7, 195.111.192.7, 0) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:599]: Sending: ACK sip:193.225.95.130:5061;transport=tls SIP/2.0^M Via: SIP/2.0/TLS 195.111.192.14:5061;branch=0;i=01^M Via: SIP/2.0/TCP 195.111.192.7;branch=0;i=5fb^M Via: SIP/2.0/TLS 193.6.222.62:5061;bra nch=z9hG4bK2619604118-1823^M Max-Forwards: 68^M Proxy-Authorization: Digest username="niif-tartalek",realm="195.111.192.7",nonce="TkOk+05Do 8/4J70CauQqX2GiwryZl/Do",uri="sip:9999@rmx.vvc.niif.hu",response="00e9a9991a2f93c44c25de309022cee8",algorithm=md5^M From: niif-tartalek <si p:niif-tartalek@195.111.192.7>;tag=plcm_2618225217-1823;epid=8210210CA530CG^M To: <sip:9999@rmx.vvc.niif.hu>;tag=rmx2k_2618766049-17745-RMX -0000000006-0080871424^M Call-ID: 2618224581-1823^M CSeq: 2 ACK^M Contact: niif-tartalek <sip:niif-tartalek@193.6.222.62:5061;transport=tls >;proxy=replace;+sip.instance="<urn:uuid:615fd9bb-1986-52eb-9084-681c290b7e3a>"^M User-Agent:Polycom HDX 8000 HD (Release - 3.0.2-11176)^M Supported: ms-forking^M Content-Length: 0^M ^M . Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [forward.c:601]: orig. len=973, new_len=918, proto=3 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2299]: tcp_send: found fd in cache ( 11, 0xb2922e88, 18) Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2522]: tcp_send: sending... Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2556]: tcp_send: after real write: c= 0xb2922e88 n=949 fd=11 Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [tcp_main.c:2557]: tcp_send: buf= ^W^C^A^C<B0>@<B7>*<D9>^O<B5>-<D2>j<F9>N`<87> lj<F4><8B><B5>B<CE>^VC^_V<FF><F4><D4>h'<ED><CE>sU<92><F8><84>]'<AD>**<EE>H;<94>]'2|<9F><C8>^FNu<CB>!<B0><B6><FC>Y2!<9A> Ue(<E3><9E>M<88>x<8A> <C1><EF><DD>^X<A4><A3>^A<D4><D0>¬f<B1><B0><B9>y^G^] <85>?<86>@<AB><AB>We<C5><EF>4i <84>^B<F2>kf^M<8E><<A7>^\<F3><D5>^U5<AE><AB><84><84><EB> <A2>+V<9A>^R<9E><90>_p<AB>^F^Z<A3>i<E0><D0>^E??<CE>^D6LN4L<82><FE>^E<EA>p<F0>6u<A3>VT<94>C9<A7>d[dL1^D<BF><86><8F>3^M<BB><96>S<A8><A3>^^?kO <F7>}Q;<<E6>M<A9>N,AE-F<9A><AE><A1>g<FB>w<95> ?^U^Q_<EF><E2><8F><EC>m&<F3>^^<EF><F4>^[<B8><91>e9#<A7>(<82>^Y<EF><83>^O{<8B><A3><B3>(K_ <EA>- <CE>^F<E3>T<DD><FA><B6><C6><C0>R<B6><AE>mhs^T^G<8F><FF><E9><<F8><8A>|i<A3>? qf<C3>^^G7<C7>ub<F0>&^R^D<C7>^R?<91><BC>uV<9D><F5>^[<F5><AF>w6 <93><98>`<B5>t7D<B1><E1><C5>^\<E3>6O<FC><84><9F><F1>y<E8>!v<9F><C1>;<AD><AA>x<AA><B6>^Z<A6>P<8E>Y<BA>^\<9D><A2><A6><A6><9E>3}70^K<CC>-<EA>h <DB>^R^O2<D7>H+m:<A4><F5>??<BA><9B>^\<AD><B1><85><DF>c<FE><U+05FA><C0>,<87>a&^Z^U^V<A6>4<B0><A8>?<A9>?<F5>3<9E><D1>^[<E7><9D><F7>+<90>P<DA> <E7>^^<D3>WO<ED><97><EF><B4>1<BA>?1<B7><B1><9F>X Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)Thanks, Misi
2011-08-11 15:38 keltezéssel, Daniel-Constantin Mierla írta: > Hello, > > E2E ACK is getting to configuration file routing block. With the > latest stable version default config file, it is handled in the > route[WITHINDLG]. Be sure you call sip trace function there. > This will capture the incoming E2E ACK. For outgoing version, > set the flag and it should be captured in TM callback, iirc. > > SL module is filtering the ACKs that are a result of negative > replies sent with SL module. > > Cheers, > Daniel > > On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály <misi@niif.hu > mailto:misi@niif.hu> wrote: > > Hi, > > I want to see all incoming and outgoing sip messages in sip > trace table, but i am missing messages. > I am using TLS so i can't see really trace the conversation > only this way. > > I am wondering if it is know limitation, or an issue: > I am experiencing that E2E ACK is not logged in siptrace table. > > I opened a ticket with the details: > http://sip-router.org/tracker/index.php?do=details&task_id=144&proje... > http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1 > > Many Thanks, > Misi > > _______________________________________________ > 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 > > > > > -- > Daniel-Constantin Mierla > http://www.asipto.com > > > _______________________________________________ > 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
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
-- 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
Hello,
On 8/18/11 4:12 PM, MÉSZÁROS Mihály wrote:
Hi Daniel!
Thank You very much! I tested it, and it seems to be working for me!
ok.
Only one typo what i corrected. You have missed out the beginning " from your example. if(method==ACK") sip_trace();
Thank you again!
By the way two problems with git HEAD. I checked out the current git HEAD, and I have experienced these two problems:
modul purple is not compiled for me. hal:/usr/local/src/sip-router/modules_k/purple# make CC (gcc) [M purple.so] clientpipe.o In file included from purple.h:23, from clientpipe.c:28: /usr/include/libpurple/status.h:93: error: expected specifier-qualifier-list before 'gpointer' make: *** [clientpipe.o] Error 1
There was a change in the libpurple API and the module was not updated for latest version of libpurple -- it has no active maintainer. However, this module is not compiled by default, if you need it either update it to latest purple library or use an older version of that library.
htable-create.sql MYSQL table create is giving back error. The problem is VARCHAR without length.
diff --git a/utils/kamctl/mysql/htable-create.sql b/utils/kamctl/mysql/htable-create.sql index 6adfa48..79eb43b 100644 --- a/utils/kamctl/mysql/htable-create.sql +++ b/utils/kamctl/mysql/htable-create.sql @@ -5,6 +5,6 @@ CREATE TABLE htable ( key_type INT DEFAULT 0 NOT NULL, value_type INT DEFAULT 0 NOT NULL, key_value VARCHAR(128) DEFAULT '' NOT NULL,
- expires VARCHAR DEFAULT 0 NOT NULL
- expires VARCHAR(128) DEFAULT 0 NOT NULL
) ENGINE=MyISAM;
This is fixed now, thanks,
Cheers, Daniel
Cheers, Misi
2011-08-17 12:09 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I have committed the feature to be able to use sip_trace() from onsend_route, therefore you can catch forwarded ACKs:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9d8df252...
An example of usage would be:
onsend_route {
}
Let me know if it works.
Cheers, Daniel
On 8/13/11 9:46 PM, Mészáros Mihály wrote:
Hi Daniel,
Thank you for looking after the issue. Am I understand you correctly: You mean that it couldn't be corrected (or it is not the right solution) in TM to have a callback to messages what are sent out stateless way, and correct the issue in this way. So you mean I will have to add siptrace to call logic in config file to route block onsend_route?
I am looking forward to hear about the fix, after you will be ready with it.
Many Thanks, Misi
On 2011-08-12 15:25, Daniel-Constantin Mierla wrote:
Hello,
ok, seems that there is no actual callback for outgoing ACK -- the same seems to be in 1.x, based on a quick look there -- the callback for TM outgoing requests is useless since the ACK is forwarded in stateless mode.
The great thing with 3.x is that we have onsend_route where the outgoing message content is available, so I just need to code a bit in siptrace module and have it working properly to store the outgoing ACKs. I will try to do it asap.
Cheers, Daniel
On 8/11/11 9:23 PM, MÉSZÁROS Mihály wrote:
Hello Daniel,
I appreciate highly your help!
Cheers, Misi
2011-08-11 20:41 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I will look to see what happens with the outgoing ACK, probably tomorrow or so. Btw, there is no need to apologize, here are open discussions, reporting issues, throwing ideas, bad or good, the conclusion comes after some analysis and help from the others. It's hard to know everything and who does not care does not participate.
Cheers, Daniel
On 8/11/11 4:32 PM, MÉSZÁROS Mihály wrote: > Hi Daniel, > > I put on setflag before WITHINDLG, > so AFAIK the ACK as a new transaction is executing this step. > The root of my problem is that I can see the incoming E2E ACK, > but i couldn't see the "outgoing"! > > route { > #pike flood detection > if (!pike_check_req()) { exit; }; > > # per request initial checks > route(REQINIT); > > #siptrace > setflag(22); > sip_trace(); > > xdbg("SIP Request: \n $mb \n"); > > # NAT detection > route(NAT); > > # handle requests within SIP dialogs > route(WITHINDLG); > > > And in debug i can't find where want kamailio log/trace the > _outgoing_ message. > I can see only that it will be forwarded in stateless way. > This is why i started to dig in sl modul. But thank You, now i > see it was a mistake. sorrrrrrrry. > > Sorry for the early case opening, you are right not sl causing > that. I thought i find something. sorry again. > > But i can see only incoming E2E ACK and I can't see the outgoing > pair in siptrace. > In TM modul i can't see where it is calling back siptrace in > case of E2E ack. > > > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [socket_info.c:501]: grep_sock_info - checking if host==us: > 14==14 && [195.11 > 1.192.14] == [195.111.192.14] > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [socket_info.c:504]: grep_sock_info - checking if port 5061 > matches port 5061 > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [parser/msg_parser.c:103]: found end of header > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr > [loose.c:257]: No next Route HF found > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: rr > [loose.c:834]: no next URI found > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm > [t_lookup.c:1379]: DEBUG: t_newtran: msg id=68 , global msg > id=67 , T on entrance= > 0xffffffff > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm > [t_lookup.c:528]: t_lookup_request: start searching: > hash=63155, isACK=1 > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm > [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 > transaction matching > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm > [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm > [t_reply.c:301]: DEBUG: totag for e2e ACK found: 0 > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm > [t_hooks.c:288]: DBG: trans=0xb2954a38, callback type 4, id > 0 entered > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: tm > [t_funcs.c:315]: SER: forwarding ACK statelessly > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [msg_translator.c:2437]: create_via_hf: id added: <;i=01>, > rcv proto=2 > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [msg_translator.c:204]: check_via_address(195.111.192.7, > 195.111.192.7, 0) > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [forward.c:599]: Sending: ACK > sip:193.225.95.130:5061;transport=tls SIP/2.0^M > Via: SIP/2.0/TLS 195.111.192.14:5061;branch=0;i=01^M Via: > SIP/2.0/TCP 195.111.192.7;branch=0;i=5fb^M Via: SIP/2.0/TLS > 193.6.222.62:5061;bra > nch=z9hG4bK2619604118-1823^M Max-Forwards: 68^M > Proxy-Authorization: Digest > username="niif-tartalek",realm="195.111.192.7",nonce="TkOk+05Do > 8/4J70CauQqX2GiwryZl/Do",uri="sip:9999@rmx.vvc.niif.hu",response="00e9a9991a2f93c44c25de309022cee8",algorithm=md5^M > From: niif-tartalek <si > p:niif-tartalek@195.111.192.7>;tag=plcm_2618225217-1823;epid=8210210CA530CG^M > To: sip:9999@rmx.vvc.niif.hu;tag=rmx2k_2618766049-17745-RMX > -0000000006-0080871424^M Call-ID: 2618224581-1823^M CSeq: 2 > ACK^M Contact: niif-tartalek > sip:niif-tartalek@193.6.222.62:5061;transport=tls >;proxy=replace;+sip.instance="urn:uuid:615fd9bb-1986-52eb-9084-681c290b7e3a"^M > User-Agent:Polycom HDX 8000 HD (Release - 3.0.2-11176)^M > Supported: ms-forking^M Content-Length: 0^M ^M . > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [forward.c:601]: orig. len=973, new_len=918, proto=3 > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [tcp_main.c:2299]: tcp_send: found fd in cache ( 11, > 0xb2922e88, 18) > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [tcp_main.c:2522]: tcp_send: sending... > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [tcp_main.c:2556]: tcp_send: after real write: c= 0xb2922e88 > n=949 fd=11 > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [tcp_main.c:2557]: tcp_send: buf= > ^W^C^A^C<B0>@<B7>*<D9>^O<B5>-<D2>j<F9>N`<87> > lj<F4><8B><B5>B<CE>^VC^_V<FF><F4><D4>h'<ED><CE>sU<92><F8><84>]'<AD>**<EE>H;<94>]'2|<9F><C8>^FNu<CB>!<B0><B6><FC>Y2!<9A> > Ue(<E3><9E>M<88>x<8A> > <C1><EF><DD>^X<A4><A3>^A<D4><D0>¬f<B1><B0><B9>y^G^] > <85>?<86>@<AB><AB>We<C5><EF>4i > <84>^B<F2>kf^M<8E><<A7>^<F3><D5>^U5<AE><AB><84><84><EB> > <A2>+V<9A>^R<9E><90>_p<AB>^F^Z<A3>i<E0><D0>^E??<CE>^D6LN4L<82><FE>^E<EA>p<F0>6u<A3>VT<94>C9<A7>d[dL1^D<BF><86><8F>3^M<BB><96>S<A8><A3>^^?kO > <F7>}Q;<<E6>M<A9>N,AE-F<9A><AE><A1>g<FB>w<95> > ?^U^Q_<EF><E2><8F><EC>m&<F3>^^<EF><F4>^[<B8><91>e9#<A7>(<82>^Y<EF><83>^O{<8B><A3><B3>(K_ > <EA>- > <CE>^F<E3>T<DD><FA><B6><C6><C0>R<B6><AE>mhs^T^G<8F><FF><E9><<F8><8A>|i<A3>? > qf<C3>^^G7<C7>ub<F0>&^R^D<C7>^R?<91><BC>uV<9D><F5>^[<F5><AF>w6 > <93><98>`<B5>t7D<B1><E1><C5>^<E3>6O<FC><84><9F><F1>y<E8>!v<9F><C1>;<AD><AA>x<AA><B6>^Z<A6>P<8E>Y<BA>^<9D><A2><A6><A6><9E>3}70^K<CC>-<EA>h > <DB>^R^O2<D7>H+m:<A4><F5>??<BA><9B>^<AD><B1><85><DF>c<FE><U+05FA><C0>,<87>a&^Z^U^V<A6>4<B0><A8>?<A9>?<F5>3<9E><D1>^[<E7><9D><F7>+<90>P<DA> > <E7>^^<D3>WO<ED><97><EF><B4>1<BA>?1<B7><B1><9F>X > Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: <core> > [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) > > > Thanks, > Misi > > 2011-08-11 15:38 keltezéssel, Daniel-Constantin Mierla írta: >> Hello, >> >> E2E ACK is getting to configuration file routing block. With >> the latest stable version default config file, it is handled in >> the route[WITHINDLG]. Be sure you call sip trace function >> there. This will capture the incoming E2E ACK. For outgoing >> version, set the flag and it should be captured in TM callback, >> iirc. >> >> SL module is filtering the ACKs that are a result of negative >> replies sent with SL module. >> >> Cheers, >> Daniel >> >> On Thu, Aug 11, 2011 at 3:29 PM, MÉSZÁROS Mihály <misi@niif.hu >> mailto:misi@niif.hu> wrote: >> >> Hi, >> >> I want to see all incoming and outgoing sip messages in sip >> trace table, but i am missing messages. >> I am using TLS so i can't see really trace the conversation >> only this way. >> >> I am wondering if it is know limitation, or an issue: >> I am experiencing that E2E ACK is not logged in siptrace table. >> >> I opened a ticket with the details: >> http://sip-router.org/tracker/index.php?do=details&task_id=144&proje... >> http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pagenum=1 >> >> Many Thanks, >> Misi >> >> _______________________________________________ >> 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 >> >> >> >> >> -- >> Daniel-Constantin Mierla >> http://www.asipto.com >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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
-- 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
Hi Daniel
modul purple is not compiled for me. hal:/usr/local/src/sip-router/modules_k/purple# make CC (gcc) [M purple.so] clientpipe.o In file included from purple.h:23, from clientpipe.c:28: /usr/include/libpurple/status.h:93: error: expected specifier-qualifier-list before ‘gpointer’ make: *** [clientpipe.o] Error 1
There was a change in the libpurple API and the module was not updated for latest version of libpurple -- it has no active maintainer. However, this module is not compiled by default, if you need it either update it to latest purple library or use an older version of that library.
Can you commit this to the git to avoid default compilation?
diff --git a/pkg/kamailio/deb/debian/rules b/pkg/kamailio/deb/debian/rules index 30feea7..80c23d8 100755 --- a/pkg/kamailio/deb/debian/rules +++ b/pkg/kamailio/deb/debian/rules @@ -41,7 +41,7 @@ MODULES_SP= # Note: the order is important (should be in dependency order, the one # on which other depend first) PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \ - ldap xml perl utils purple memcached tls \ + ldap xml perl utils memcached tls \ snmpstats carrierroute xmpp cpl lua python geoip
Thanks, Misi
El Mon, 22 Aug 2011 22:04:44 +0200 MÉSZÁROS Mihály misi@niif.hu escribió:
Hi Daniel
modul purple is not compiled for me. hal:/usr/local/src/sip-router/modules_k/purple# make CC (gcc) [M purple.so] clientpipe.o In file included from purple.h:23, from clientpipe.c:28: /usr/include/libpurple/status.h:93: error: expected specifier-qualifier-list before ‘gpointer’ make: *** [clientpipe.o] Error 1
There was a change in the libpurple API and the module was not updated for latest version of libpurple -- it has no active maintainer. However, this module is not compiled by default, if you need it either update it to latest purple library or use an older version of that library.
Can you commit this to the git to avoid default compilation?
diff --git a/pkg/kamailio/deb/debian/rules b/pkg/kamailio/deb/debian/rules index 30feea7..80c23d8 100755 --- a/pkg/kamailio/deb/debian/rules +++ b/pkg/kamailio/deb/debian/rules @@ -41,7 +41,7 @@ MODULES_SP= # Note: the order is important (should be in dependency order, the one # on which other depend first) PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \
- ldap xml perl utils purple memcached tls \
- ldap xml perl utils memcached tls \
snmpstats carrierroute xmpp cpl lua python geoip
You have different debian folders based on different debian distros. Take a look to pkg/kamailio/deb/
If you use squeeze, you could perform:
ln -s pkg/kamailio/deb/squeeze debian
and then build kamailio.
By default, if you don't symlink debian to a specific distro folder pkg/kamailio/deb/debian is used, which includes almost all the modules. Works fine in debian lenny and ubuntu lucid.
-
Daniel-Constantin Mierla -
Jon Bonilla -
MÉSZÁROS Mihály