i have been wondering why my proxy is not forwarding 180 ringing reply to caller that it receives from callee. invite was forwarded to callee by t_relay(). proxy does not print any error messages to syslog. the only thing i get is the message i have in onreply_route:
onreply_route [REPLY] { xlog("L_INFO", "Received reply\n"); return; }
level 3 debug of 180 reply processing is below. does it tell anything to tm gurus that would explain why kamailio does nothing to the reply?
180 reply itself looks like this:
Session Initiation Protocol Status-Line: SIP/2.0 180 Ringing Message Header Record-Route: sip:192.98.102.30;transport=tcp;r2=on;lr Record-Route: sip:192.98.102.30;r2=on;lr Via: SIP/2.0/TCP 192.98.102.30;branch=z9hG4bK84cf.498ea35cdde08fdfad989b 9212a2a9a5.0 Via: SIP/2.0/UDP 192.98.102.31:55419;branch=z9hG4bKd6e2f0db78e2df94;rpor t=55419 To: sip:test@test.tutpro.com;tag=8e143c1b780cfb1b From: sip:jh@test.tutpro.com;tag=630450233fa9bc92 Call-ID: d0b328ba01bcc483 CSeq: 22643 INVITE Server: baresip v0.4.6 (i586/linux) Contact: sip:0x94fa6e8@192.98.102.30:49240;transport=tcp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REFER,NOTIFY,SUBSCRIBE,INFO Content-Length: 0
-- juha
Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [tcp_read.c:1510]: handle_io(): received n=4 con=0xb4252638, fd=15 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [tcp_read.c:1317]: tcp_read_req(): tcp_read_req: content-length= 0 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply (status): Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0> Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:637]: parse_msg(): status: <180> Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:639]: parse_msg(): reason: <Ringing> Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK84cf.498ea35cdde08fdfad989b9212a2a9a5.0>; state=16 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [receive.c:151]: receive_msg(): After parse_msg... Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=5 global id=4 T start=0xffffffff Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKd6e2f0db78e2df94>; state=6 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, <rport> = <55419>; state=16 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=62 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:526]: parse_headers(): parse_headers: this is the second via Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=8e143c1b780cfb1b Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_addr_spec.c:885]: parse_addr_spec(): end of header reached, state=29 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [49]; uri=[sip:test@test.tutpro.com] Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [sip:test@test.tutpro.com] Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <22643> <INVITE> Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 64584 label 0 branch 0 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:1003]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0xb4256d88)! Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0xb4256d88, callback type 2, id 0 entered Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: acc [acc_logic.c:538]: tmcb_func(): acc callback called for t(0xb4256d88) event type 2, reply code 180 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=5 global id=5 T end=0xb4256d88 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_reply.c:2258]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=1) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: INFO: Received reply Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [receive.c:295]: receive_msg(): receive_msg: cleaning up Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [io_wait.h:390]: io_watch_add(): DBG: io_watch_add(0x82ca540, 15, 2, 0xb4252638), fd_no=1
i compared debug of failing 180 reply to working one and i don't see any other difference except in working one reply gets relayed:
... Oct 23 18:07:43 rautu /usr/sbin/sip-proxy[8738]: DEBUG: tm [t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=11 global id=11 T end=0xb425e168 Oct 23 18:07:43 rautu /usr/sbin/sip-proxy[8738]: DEBUG: tm [t_reply.c:2258]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=1) Oct 23 18:07:43 rautu /usr/sbin/sip-proxy[8738]: INFO: Received reply Oct 23 18:07:43 rautu /usr/sbin/sip-proxy[8738]: DEBUG: tm [t_reply.c:1362]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=180 Oct 23 18:07:43 rautu /usr/sbin/sip-proxy[8738]: DEBUG: tm [t_reply.c:1879]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0 ...
in failing one it does not happen and things are cleaned up:
... Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=5 global id=5 T end=0xb4256d88 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_reply.c:2258]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=1) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: INFO: Received reply Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) ...
in both cases the reply code is the same and debug shows that the status of the reply is the same.
why reply is not relayed in the failing test? why does kamailio think that it should not relay the reply?
-- juha
i added some INFO calls to t_reply.c:
INFO("==== testing suspended\n"); if (unlikely(p_msg->flags&FL_RPL_SUSPENDED)) { INFO("==== skip sending of reply\n"); goto skip_send_reply; /* suspend the reply (async), no error */ } INFO("==== done with testing suspended\n");
for some reason tm thinks that the reply is suspended and tm skips sending it:
Oct 23 20:40:50 rautu /usr/sbin/sip-proxy[11616]: INFO: tm [t_reply.c:2527]: reply_received(): ==== testing suspended Oct 23 20:40:50 rautu /usr/sbin/sip-proxy[11616]: INFO: tm [t_reply.c:2529]: reply_received(): ==== skip sending of reply
what could cause the flag FL_RPL_SUSPENDED being set and reply being suspended?
-- juha
Juha Heinanen writes:
what could cause the flag FL_RPL_SUSPENDED being set and reply being suspended?
by reading t_suspend.c, i got the impression that t_suspend() needs to be called in order to suspend the transaction.
if so, i'm not calling t_suspend() or t_continue() in my config.
was there recently some commits to master on async processing? if so, could it be that the flag codes got mixed up?
-- juha
Do a search for FL_RPL_SUSPENDED and add some DBG probes where is set. There were some enhancements to allow t-suspend for replies: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=16e763c3...
Regards, Ovidiu Sas
On Wed, Oct 23, 2013 at 1:54 PM, Juha Heinanen jh@tutpro.com wrote:
Juha Heinanen writes:
what could cause the flag FL_RPL_SUSPENDED being set and reply being suspended?
by reading t_suspend.c, i got the impression that t_suspend() needs to be called in order to suspend the transaction.
if so, i'm not calling t_suspend() or t_continue() in my config.
was there recently some commits to master on async processing? if so, could it be that the flag codes got mixed up?
-- juha
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
Ovidiu Sas writes:
Do a search for FL_RPL_SUSPENDED and add some DBG probes where is set.
ovidiu,
i already did. the flag is only set in t_suspend.c:
tm$ egrep RPL_SUSP *.c t_reply.c: if (unlikely(p_msg->flags&FL_RPL_SUSPENDED)) { t_suspend.c: msg->flags |= FL_RPL_SUSPENDED; t_suspend.c: t->uac[branch].reply->flags &= ~FL_RPL_SUSPENDED; t_suspend.c: if (t->uas.request) t->uas.request->flags&= ~FL_RPL_SUSPENDED; t_suspend.c: t->uac[branch].reply->flags &= ~FL_RPL_SUSPENDED; t_suspend.c: if (t->uas.request) t->uas.request->flags&= ~FL_RPL_SUSPENDED;
that file contains three functions t_suspend(), t_continue, and t_cancel_suspend and my script is not calling any of them.
that is why i suspected that some other flag may have become FL_RPL_SUSPENDED flag.
-- juha
in the test where reply is not relayed, i set flag 16:
setflag(16);
then see this:
msg_parser.h:#define FL_RPL_SUSPENDED (1<<16) /* for async reply processing */
could this explain what is happening?
i have always thought that message flags can be freely used in the script. is it now so that flag 16 is reserved for suspend/resume feature?
if so, what other flags i'm not able to use in my script without messing everything up?
-- juha
Hello,
On 10/23/13 8:31 PM, Juha Heinanen wrote:
in the test where reply is not relayed, i set flag 16:
setflag(16);then see this:
msg_parser.h:#define FL_RPL_SUSPENDED (1<<16) /* for async reply processing */
could this explain what is happening?
i have always thought that message flags can be freely used in the script. is it now so that flag 16 is reserved for suspend/resume feature?
if so, what other flags i'm not able to use in my script without messing everything up?
Looks like a mistaken usage of the internal flags, FL_RPL_SUSPENDED being actually on the script flags. Script accessible flags should be always at the will of script writer.
I will look over it.
Cheers, Daniel
-- juha
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,
can you give a test to latest master branch? I pushed a patch there.
Cheers, Daniel
On 10/24/13 7:39 AM, Daniel-Constantin Mierla wrote:
Hello,
On 10/23/13 8:31 PM, Juha Heinanen wrote:
in the test where reply is not relayed, i set flag 16:
setflag(16);then see this:
msg_parser.h:#define FL_RPL_SUSPENDED (1<<16) /* for async reply processing */
could this explain what is happening?
i have always thought that message flags can be freely used in the script. is it now so that flag 16 is reserved for suspend/resume feature?
if so, what other flags i'm not able to use in my script without messing everything up?
Looks like a mistaken usage of the internal flags, FL_RPL_SUSPENDED being actually on the script flags. Script accessible flags should be always at the will of script writer.
I will look over it.
Cheers, Daniel
-- juha
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
Apologies for this guys. This was our mistake. Thanks Daniel for resolving. We will test the async replies in master today.
--- This mail was sent using my phone and may be brief, to the point, or contain typos --- On 24 Oct 2013 08:17, "Daniel-Constantin Mierla" miconda@gmail.com wrote:
Hello,
can you give a test to latest master branch? I pushed a patch there.
Cheers, Daniel
On 10/24/13 7:39 AM, Daniel-Constantin Mierla wrote:
Hello,
On 10/23/13 8:31 PM, Juha Heinanen wrote:
in the test where reply is not relayed, i set flag 16:
setflag(16);then see this:
msg_parser.h:#define FL_RPL_SUSPENDED (1<<16) /* for async reply processing */
could this explain what is happening?
i have always thought that message flags can be freely used in the script. is it now so that flag 16 is reserved for suspend/resume feature?
if so, what other flags i'm not able to use in my script without messing everything up?
Looks like a mistaken usage of the internal flags, FL_RPL_SUSPENDED being actually on the script flags. Script accessible flags should be always at the will of script writer.
I will look over it.
Cheers, Daniel
-- juha
______________________________**_________________ 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
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/**micondahttp://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at 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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
It is a bit strange -- can you remove the 'return' (which doesn't do anything useful there) to see if that is the cause?
Cheers, Daniel
On 10/23/13 4:50 PM, Juha Heinanen wrote:
i have been wondering why my proxy is not forwarding 180 ringing reply to caller that it receives from callee. invite was forwarded to callee by t_relay(). proxy does not print any error messages to syslog. the only thing i get is the message i have in onreply_route:
onreply_route [REPLY] { xlog("L_INFO", "Received reply\n"); return; }
level 3 debug of 180 reply processing is below. does it tell anything to tm gurus that would explain why kamailio does nothing to the reply?
180 reply itself looks like this:
Session Initiation Protocol Status-Line: SIP/2.0 180 Ringing Message Header Record-Route: sip:192.98.102.30;transport=tcp;r2=on;lr Record-Route: sip:192.98.102.30;r2=on;lr Via: SIP/2.0/TCP 192.98.102.30;branch=z9hG4bK84cf.498ea35cdde08fdfad989b 9212a2a9a5.0 Via: SIP/2.0/UDP 192.98.102.31:55419;branch=z9hG4bKd6e2f0db78e2df94;rpor t=55419 To: sip:test@test.tutpro.com;tag=8e143c1b780cfb1b From: sip:jh@test.tutpro.com;tag=630450233fa9bc92 Call-ID: d0b328ba01bcc483 CSeq: 22643 INVITE Server: baresip v0.4.6 (i586/linux) Contact: sip:0x94fa6e8@192.98.102.30:49240;transport=tcp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REFER,NOTIFY,SUBSCRIBE,INFO Content-Length: 0
-- juha
Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [tcp_read.c:1510]: handle_io(): received n=4 con=0xb4252638, fd=15 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [tcp_read.c:1317]: tcp_read_req(): tcp_read_req: content-length= 0 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply (status): Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0> Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:637]: parse_msg(): status: <180> Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:639]: parse_msg(): reason: <Ringing> Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK84cf.498ea35cdde08fdfad989b9212a2a9a5.0>; state=16 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [receive.c:151]: receive_msg(): After parse_msg... Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=5 global id=4 T start=0xffffffff Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKd6e2f0db78e2df94>; state=6 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, <rport> = <55419>; state=16 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=62 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:526]: parse_headers(): parse_headers: this is the second via Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=8e143c1b780cfb1b Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/parse_addr_spec.c:885]: parse_addr_spec(): end of header reached, state=29 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [49]; uri=[sip:test@test.tutpro.com] Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [sip:test@test.tutpro.com] Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <22643> <INVITE> Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 64584 label 0 branch 0 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:1003]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0xb4256d88)! Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0xb4256d88, callback type 2, id 0 entered Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: acc [acc_logic.c:538]: tmcb_func(): acc callback called for t(0xb4256d88) event type 2, reply code 180 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=5 global id=5 T end=0xb4256d88 Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: tm [t_reply.c:2258]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=1) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: INFO: Received reply Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil) Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [receive.c:295]: receive_msg(): receive_msg: cleaning up Oct 23 17:40:51 rautu /usr/sbin/sip-proxy[8730]: DEBUG: <core> [io_wait.h:390]: io_watch_add(): DBG: io_watch_add(0x82ca540, 15, 2, 0xb4252638), fd_no=1
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 writes:
It is a bit strange -- can you remove the 'return' (which doesn't do anything useful there) to see if that is the cause?
it cannot be the reason, because with exactly same config, some 180s are relayed. in all tests, the called party is the same and the same baresip ua is used at both as UAC and UAS. the only difference is the source of the invite, i.e., first part of invite request processing differs, but once config knows that the destination is local user, the rest of invite processing is the same.
-- juha
-
Daniel-Constantin Mierla -
Jason Penton -
Juha Heinanen -
Ovidiu Sas