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 &lt;misi(a)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&proj… >>>> <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(a)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(a)lists.sip-router.org >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> 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(a)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