[OpenSIPS-Users] BYE msg not inserted into sip_trace
rad bogdan
bogdan_rad2004 at yahoo.com
Mon Jan 24 11:39:39 CET 2011
Hi Bogdan,
I added
local_route {
xlog("================LOCAL_ROUTE============\n");
setflag(22);
sip_trace();
if (is_method("BYE") ) {
xlog("================BYE============\n");
}
}
to the script but I'm running into a crash (see bellow the log excerpt) caused by the null value returned by ip_addr2a.
Please advise,
Bogdan
Jan 24 12:25:21 P4237 cdrtool[3919]: DebitBalance Duration=12 CallId=1378020100 From=sip:1000 at localhost Gateway=127.0.0.1 To=sip:01234 at localhost
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:mi_datagram:mi_datagram_parse_node: 2 data->len is 1
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:mi_datagram:mi_datagram_parse_tree: adding node <> ; val <1093323345>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:mi_datagram:mi_datagram_parse_tree: the remaining datagram has 1 bytes
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:mi_datagram:mi_datagram_parse_node: the remaining datagram to be parsed is and 1 in length
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:mi_datagram:mi_datagram_server: done parsing the mi tree
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:dialog:mi_terminate_dlg: h_entry 692 h_id 1093323345
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:dialog:lookup_dlg: ref dlg 0xb5ae81dc with 1 -> 3
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:dialog:lookup_dlg: dialog id=1093323345 found on entry 692
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:dialog:send_leg_bye: sending BYE to caller (0)
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:dialog:ref_dlg: ref dlg 0xb5ae81dc with 1 -> 4
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:tm:t_uac: next_hop=<sip:1000 at 127.0.0.1:5061>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_uri: parsed uri: type=1 user=<1000>(4) passwd=<>(0) host=<127.0.0.1>(9) port=<5061>(4): 5061 params=<>(0) headers=<>(0)
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_uri: uri params: transport=<>, val=<>, proto=0
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_uri: user-param=<>, val=<>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_uri: method=<>, val=<>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_uri: ttl=<>, val=<>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_uri: maddr=<>, val=<>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_uri: lr=<>, val=<>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_uri: r2=<>, val=<>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:mk_proxy: doing DNS lookup...
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:tm:dlg2hash: 18228
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:tm:print_request_uri: sip:1000 at 127.0.0.1:5061
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:tm:t_uac: building sip_msg from buffer
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_msg: SIP Request:
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_msg: method: <BYE>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_msg: uri: <sip:1000 at 127.0.0.1:5061>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_msg: version: <SIP/2.0>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: flags=2
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK4374.083fa773.0>; state=16
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_via: end of header reached, state=5
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: via found, flags=2
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: this is the first via
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: header field type 1, name=<Via>, body=<SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK4374.083fa773.0>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_msg: first via: <SIP/2.0/UDP> <127.0.0.1:(0)>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_msg: ;<>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_msg:
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_msg: exiting
Jan 24 12:25:21 P4237 ./opensips[6821]: INFO:core:buf_init: initializing...
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:pv_printf: final buffer length 40
Jan 24 12:25:21 P4237 ./opensips[6821]: ================LOCAL_ROUTE============
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: flags=10
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_to_param: tag=1779764692
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_to: end of header reached, state=29
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_to: display={}, ruri={sip:1000 at localhost}
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:get_hdr_field: <To> [37]; uri=[sip:1000 at localhost]
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:get_hdr_field: to body [<sip:1000 at localhost>]
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: header field type 3, name=<To>, body=<<sip:1000 at localhost>;tag=1779764692>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: header field type 4, name=<From>, body=<<sip:01234 at localhost>;tag=1130602078>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_to_param: tag=1130602078
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_to: end of header reached, state=29
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_to: display={}, ruri={sip:01234 at localhost}
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: flags=40
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:get_hdr_field: cseq <CSeq>: <21> <BYE>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: header field type 5, name=<CSeq>, body=<21 BYE>
Jan 24 12:25:21 P4237 ./opensips[6821]: DBG:core:parse_headers: header field type 6, name=<Call-ID>, body=<1378020100>
Jan 24 12:25:21 P4237 ./opensips[6821]: CRITICAL:siptrace:ip_addr2a: unknown address family 0
Jan 24 12:25:21 P4237 cdrtool[3919]: ConnectFee=0.0000 CallId=1378020100 Span=1 Duration=12 DestId=31 default Profile=grn_premium Period=weekday Rate=grn_premium Interval=0-24 Cost=0.1000/6 Price=0.2000 PriceIn=0.0000
Jan 24 12:25:21 P4237 cdrtool[3919]: Price=0.2000 Duration=12 CallId=1378020100 BillingParty=1000 at localhost DestId=31 MaxSessionTime=0
Jan 24 12:25:21 P4237 call-control[3909]: Call id 1378020100 of 1000 at localhost to sip:01234 at localhost disconnected by call control after 12 seconds, call price is 0.2000
Jan 24 12:25:21 P4237 kernel: [10135.307026] opensips[6821]: segfault at 0 ip b7dd7bb9 sp bf800d08 error 4 in libc-2.11.2.so[b7d65000+140000]
Jan 24 12:25:21 P4237 ./opensips[6850]: CRITICAL:core:receive_fd: EOF on 11
--- On Fri, 1/21/11, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Subject: Re: [OpenSIPS-Users] BYE msg not inserted into sip_trace
To: "OpenSIPS users mailling list" <users at lists.opensips.org>
Date: Friday, January 21, 2011, 7:31 PM
take care that the BYEs which are generated by opensips do not go
through the opensips main route, you need to configure a local_route{}
to get them...and make there a sip_trace()
Regards,
Bogdan
rad bogdan wrote:
> Bogdan,
>
> The lines related to siptrace are these:
> modparam("siptrace", "db_url", "mysql://user:password@localhost/opensips")
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "trace_flag",22)
> modparam("siptrace", "trace_local_ip", "localhost")
> modparam("siptrace", "traced_user_avp", "$avp(s:traced_user)")
>
> route{
> setflag(22);
> sip_trace();
>
> Thanks,
> Bogdan
>
> --- On *Fri, 1/21/11, Bogdan-Andrei Iancu /<bogdan at opensips.org>/* wrote:
>
>
> From: Bogdan-Andrei Iancu <bogdan at opensips.org>
> Subject: Re: [OpenSIPS-Users] BYE msg not inserted into sip_trace
> To: "OpenSIPS users mailling list" <users at lists.opensips.org>
> Date: Friday, January 21, 2011, 6:38 PM
>
> Hi Bogdan,
>
> What kind of tracing do you do? dialog based? with flags ?
>
> Regards,
> Bogdan
>
> rad bogdan wrote:
> > Hi Bogdan,
> >
> > I've seen that when CallControl notifies OpenSIPS (1.6.4) that a
> call must be interrupted because the balance is 0, OpenSIPS sends
> BYE to both the caller and the callee but the messages are not
> being written into sip_trace.
> >
> > Is this a normal behavior or it is a bug ?
> >
> > Thanks,
> > Bogdan
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org </mc/compose?to=Users at lists.opensips.org>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
> -- Bogdan-Andrei Iancu
> OpenSIPS Event - expo, conf, social, bootcamp
> 2 - 4 February 2011, ITExpo, Miami, USA
> OpenSIPS solutions and "know-how"
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org </mc/compose?to=Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Bogdan-Andrei Iancu
OpenSIPS Event - expo, conf, social, bootcamp
2 - 4 February 2011, ITExpo, Miami, USA
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110124/4c635b64/attachment-0001.htm>
More information about the Users
mailing list