23 Oct
2013
23 Oct
'13
4:50 p.m.
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
23 Oct
23 Oct
5:25 p.m.
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
7:43 p.m.
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
7:54 p.m.
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
8:53 p.m.
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=16e763c…
Regards,
Ovidiu Sas
On Wed, Oct 23, 2013 at 1:54 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Juha Heinanen writes:
--
VoIP Embedded, Inc.
http://www.voipembedded.com
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8:07 p.m.
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
8:31 p.m.
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
24 Oct
24 Oct
7:39 a.m.
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(a)lists.sip-router.org
http://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/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
8:17 a.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://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 -
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8:37 a.m.
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(a)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:
This email is subject to the disclaimer of Smile Communications at
http://www.smilecoms.com/disclaimer
Hello,
On 10/23/13 8:31 PM, Juha Heinanen wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/**miconda<http://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(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http:/…
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(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http:/…
23 Oct
23 Oct
7:15 p.m.
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(a)lists.sip-router.org
http://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/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
6:33 p.m.
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
3857
days inactive
3858
days old
12 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Jason Penton -
Juha Heinanen -
Ovidiu Sas