28 Jun
2006
28 Jun
'06
5:59 p.m.
Glenn Dalgliesh wrote:
This is from previous list
"i Glenn,
For this feature to work, you need to be sure that you do record_route() on
the INVITE and that "append_fromtag" RR module param is not disable.
regards,
bogdan "
Yes i have read that thread. i always record_route all messages before
do things.
if (!method=="REGISTER")
record_route();
by the sample openser.cfg
and for be sure i have also forced:
modparam("rr","append_fromtag",1)
-----Original Message-----
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf
Of tele
Sent: Wednesday, June 28, 2006 11:05 AM
To: users(a)openser.org
Subject: [Users] more on accounting
Hi all,
I'm using OpenSER v1.0.1 and i have done an accounting compatible with
my billing system.
Now i have problem with detection of flow direction for billing reason.
i'm talking about openser 1.0.x:
the problem is when the BYE come from callee.
i know the problem is solved in openser1.1.x with the
modparam("acc", "detect_direction", 1)
i have read in modules documentation of 1.0.x that i can use
is_direction() of RR module for detect call flow direction but it says
that this must be called after loose_route()
so for the accounting i must call setflag before loose_route() but what
can i do if i want detect call flow
before of exec setflag?
Hmmm i think that i must install OpenSER 1.1.x and test with it
:tele
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
28 Jun
28 Jun
7:52 p.m.
New subject: [Users] more on accounting
Hi,
can you post the BYE request and the corresponding debug log for it
(debug=9)? Be sure you have the latest devel (cvs head) version.
regards,
bogdan
tele wrote:
Glenn Dalgliesh wrote:
This is from previous list
"i Glenn,
For this feature to work, you need to be sure that you do
record_route() on
the INVITE and that "append_fromtag" RR module param is not disable.
regards,
bogdan "
Yes i have read that thread. i always record_route all messages before
do things.
if (!method=="REGISTER")
record_route();
by the sample openser.cfg
and for be sure i have also forced:
modparam("rr","append_fromtag",1)
-----Original Message-----
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On
Behalf
Of tele
Sent: Wednesday, June 28, 2006 11:05 AM
To: users(a)openser.org
Subject: [Users] more on accounting
Hi all,
I'm using OpenSER v1.0.1 and i have done an accounting compatible
with my billing system.
Now i have problem with detection of flow direction for billing reason.
i'm talking about openser 1.0.x:
the problem is when the BYE come from callee.
i know the problem is solved in openser1.1.x with the
modparam("acc", "detect_direction", 1)
i have read in modules documentation of 1.0.x that i can use
is_direction() of RR module for detect call flow direction but it
says that this must be called after loose_route()
so for the accounting i must call setflag before loose_route() but
what can i do if i want detect call flow
before of exec setflag?
Hmmm i think that i must install OpenSER 1.1.x and test with it
:tele
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
29 Jun
29 Jun
9:07 a.m.
New subject: [Users] more on accounting
Bogdan-Andrei Iancu wrote:
Hi,
can you post the BYE request and the corresponding debug log for it
(debug=9)? Be sure you have the latest devel (cvs head) version.
yes. the 2(36881) DEBUG:rr:is_direction: param ftag not found appear
after i use setflag() for the
accounting.
U 82.215.163.5:5060 -> 82.215.130.161:5060
BYE sip:0104491009@82.215.130.161 SIP/2.0.
Max-Forwards: 70.
Via: SIP/2.0/UDP 82.215.163.5:5060;branch=z9hG4bK1e956452.
To: <sip:0104491009@dispatcher.plexia.com>;tag=7372d0e2d793fcfa.
From: <sip:3403837435@dispatcher.plexia.com>;tag=447653504.
Call-ID: f0d50109c3af297a(a)82.215.128.140.
CSeq: 22207 BYE.
Content-Length: 0.
2(36881) SIP Request:
2(36881) method: <BYE>
2(36881) uri: <sip:0104491009@82.215.130.161>
2(36881) version: <SIP/2.0>
2(36881) parse_headers: flags=2
2(36881) Found param type 232, <branch> = <z9hG4bK1e8e761a>; state=16
2(36881) end of header reached, state=5
2(36881) parse_headers: Via found, flags=2
2(36881) parse_headers: this is the first via
2(36881) After parse_msg...
2(36881) preparing to run routing scripts...
2(36881) DEBUG:maxfwd:is_maxfwd_present: value = 70
2(36881) parse_headers: flags=10
2(36881) DEBUG: add_param: tag=ed4d2ead2aad9cfd
2(36881) DEBUG:parse_to:end of header reached, state=29
2(36881) DBUG:parse_to: display={},
ruri={sip:0104491009@dispatcher.plexia.com}
2(36881) DEBUG: get_hdr_field: <To> [61];
uri=[sip:0104491009@dispatcher.plexia.com]
2(36881) DEBUG: to body [<sip:0104491009@dispatcher.plexia.com>]
2(36881) DEBUG: add_param: tag=447653504
2(36881) DEBUG:parse_to:end of header reached, state=29
2(36881) DBUG:parse_to: display={},
ruri={sip:3403837435@dispatcher.plexia.com}
2(36881) DEBUG:avpops:dbstore_avps: 1 avps were stored
2(36881) DEBUG:avpops:load_avps: loaded avps = 0
2(36881) DEBUG:avpops:load_avps: loaded avps = 0
2(36881) db_flags=1, flags=4
2(36881) db_flags=1, flags=4
2(36881) DEBUG:avpops:load_avps: loaded avps = 2
2(36881) db_flags=3, flags=4
2(36881) DEBUG:avpops:load_avps: loaded avps = 1
2(36881) parse_headers: flags=ffffffffffffffff
2(36881) get_hdr_field: cseq <CSeq>: <46820> <BYE>
2(36881) DEBUG: get_hdr_body : content_length=0
2(36881) found end of header
2(36881) [CLI/LID] Add prefix 39 to request uri
sip:390104491009@82.215.130.161 to
<sip:0104491009@dispatcher.plexia.com>;tag=ed4d2ead2aad9cfd
2(36881) DEBUG:avpops:load_avps: loaded avps = 1
2(36881) [CLI/LID] Find association: sip:390104491009@82.215.130.161
396006660009
2(36881) DEBUG:avpops:pushto_avps: 1 avps were processed
2(36881) [CLI/LID] After replace new request-uri:
sip:396006660009@dispatcher.plexia.com
2(36881) rewrite_uri: Rewriting Request-URI with
'sip:396006660009@82.215.128.140'
2(36881) DEBUG: t_newtran: msg id=2 , global msg id=1 , T on
entrance=0xffffffff
2(36881) parse_headers: flags=ffffffffffffffff
2(36881) parse_headers: flags=78
2(36881) t_lookup_request: start searching: hash=16802, isACK=0
2(36881) DEBUG: RFC3261 transaction matching failed
2(36881) DEBUG: t_lookup_request: no transaction found
2(36881) DBG: trans=0x28523ae0, callback type 1, id 0 entered
2(36881) parse_headers: flags=58
2(36881) DEBUG:rr:is_direction: param ftag not found
2(36881) DEBUG: mk_proxy: doing DNS lookup...
2(36881) check_via_address(82.215.163.5, 82.215.163.5, 0)
2(36881) DEBUG: add_to_tail_of_timer[4]: 0x28523bfc
2(36881) DEBUG: add_to_tail_of_timer[0]: 0x28523c0c
2(36881) SER: new transaction fwd'ed
2(36881) DEBUG:tm:UNREF_UNSAFE: after is 0
2(36881) DEBUG:destroy_avp_list: destroying list 0x0
2(36881) receive_msg: cleaning up
5(36884) SIP Reply (status):
5(36884) version: <SIP/2.0>
5(36884) status: <200>
5(36884) reason: <OK>
12:39 p.m.
New subject: [Users] more on accounting
Hi,
as you can seem the incoming BYE has no Route header. This leads to
these cases:
1) you do not do record_route - check the outgoing INVITE to see if
your RR hdr is present
2) the RR set is not properly mirrored in the 200 OK (again, check
the 200 OK reply)
3) the UA that generates the BYE does not use the RR set (which is
bogus)
Regards,
Bogdan
tele wrote:
Bogdan-Andrei Iancu wrote:
Hi,
can you post the BYE request and the corresponding debug log for it
(debug=9)? Be sure you have the latest devel (cvs head) version.
yes. the 2(36881) DEBUG:rr:is_direction: param ftag not found appear
after i use setflag() for the
accounting.
U 82.215.163.5:5060 -> 82.215.130.161:5060
BYE sip:0104491009@82.215.130.161 SIP/2.0.
Max-Forwards: 70.
Via: SIP/2.0/UDP 82.215.163.5:5060;branch=z9hG4bK1e956452.
To: <sip:0104491009@dispatcher.plexia.com>;tag=7372d0e2d793fcfa.
From: <sip:3403837435@dispatcher.plexia.com>;tag=447653504.
Call-ID: f0d50109c3af297a(a)82.215.128.140.
CSeq: 22207 BYE.
Content-Length: 0.
2(36881) SIP Request:
2(36881) method: <BYE>
2(36881) uri: <sip:0104491009@82.215.130.161>
2(36881) version: <SIP/2.0>
2(36881) parse_headers: flags=2
2(36881) Found param type 232, <branch> = <z9hG4bK1e8e761a>; state=16
2(36881) end of header reached, state=5
2(36881) parse_headers: Via found, flags=2
2(36881) parse_headers: this is the first via
2(36881) After parse_msg...
2(36881) preparing to run routing scripts...
2(36881) DEBUG:maxfwd:is_maxfwd_present: value = 70
2(36881) parse_headers: flags=10
2(36881) DEBUG: add_param: tag=ed4d2ead2aad9cfd
2(36881) DEBUG:parse_to:end of header reached, state=29
2(36881) DBUG:parse_to: display={},
ruri={sip:0104491009@dispatcher.plexia.com}
2(36881) DEBUG: get_hdr_field: <To> [61];
uri=[sip:0104491009@dispatcher.plexia.com]
2(36881) DEBUG: to body [<sip:0104491009@dispatcher.plexia.com>]
2(36881) DEBUG: add_param: tag=447653504
2(36881) DEBUG:parse_to:end of header reached, state=29
2(36881) DBUG:parse_to: display={},
ruri={sip:3403837435@dispatcher.plexia.com}
2(36881) DEBUG:avpops:dbstore_avps: 1 avps were stored
2(36881) DEBUG:avpops:load_avps: loaded avps = 0
2(36881) DEBUG:avpops:load_avps: loaded avps = 0
2(36881) db_flags=1, flags=4
2(36881) db_flags=1, flags=4
2(36881) DEBUG:avpops:load_avps: loaded avps = 2
2(36881) db_flags=3, flags=4
2(36881) DEBUG:avpops:load_avps: loaded avps = 1
2(36881) parse_headers: flags=ffffffffffffffff
2(36881) get_hdr_field: cseq <CSeq>: <46820> <BYE>
2(36881) DEBUG: get_hdr_body : content_length=0
2(36881) found end of header
2(36881) [CLI/LID] Add prefix 39 to request uri
sip:390104491009@82.215.130.161 to
<sip:0104491009@dispatcher.plexia.com>;tag=ed4d2ead2aad9cfd
2(36881) DEBUG:avpops:load_avps: loaded avps = 1
2(36881) [CLI/LID] Find association: sip:390104491009@82.215.130.161
396006660009
2(36881) DEBUG:avpops:pushto_avps: 1 avps were processed
2(36881) [CLI/LID] After replace new request-uri:
sip:396006660009@dispatcher.plexia.com
2(36881) rewrite_uri: Rewriting Request-URI with
'sip:396006660009@82.215.128.140'
2(36881) DEBUG: t_newtran: msg id=2 , global msg id=1 , T on
entrance=0xffffffff
2(36881) parse_headers: flags=ffffffffffffffff
2(36881) parse_headers: flags=78
2(36881) t_lookup_request: start searching: hash=16802, isACK=0
2(36881) DEBUG: RFC3261 transaction matching failed
2(36881) DEBUG: t_lookup_request: no transaction found
2(36881) DBG: trans=0x28523ae0, callback type 1, id 0 entered
2(36881) parse_headers: flags=58
2(36881) DEBUG:rr:is_direction: param ftag not found
2(36881) DEBUG: mk_proxy: doing DNS lookup...
2(36881) check_via_address(82.215.163.5, 82.215.163.5, 0)
2(36881) DEBUG: add_to_tail_of_timer[4]: 0x28523bfc
2(36881) DEBUG: add_to_tail_of_timer[0]: 0x28523c0c
2(36881) SER: new transaction fwd'ed
2(36881) DEBUG:tm:UNREF_UNSAFE: after is 0
2(36881) DEBUG:destroy_avp_list: destroying list 0x0
2(36881) receive_msg: cleaning up
5(36884) SIP Reply (status):
5(36884) version: <SIP/2.0>
5(36884) status: <200>
5(36884) reason: <OK>
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1:39 p.m.
New subject: [Users] more on accounting
Bogdan-Andrei Iancu wrote:
Hi,
as you can seem the incoming BYE has no Route header. This leads to
these cases:
1) you do not do record_route - check the outgoing INVITE to see if
your RR hdr is present
yes is present
2) the RR set is not properly mirrored in the 200
OK (again, check
the 200 OK reply)
yes there is
3) the UA that generates the BYE does not use the
RR set (which is
bogus)
yes. the call to PSTN pass for a softswitch. i contact the vendor. thanks
I've also tried with call UA --> UA that pass only from proxy and there
is the same problem on accounting.
To/From not swapped ,if the callee hangup phone, before send accounting
and yes there is RR present in the BYE message.
you can find attached here the full dump.
UA1 - 82.215.128.140
UA2 - 82.215.128.141
PROXY - 82.215.130.161
3(38040) udp_rcv_loop: probing packet received from 82.215.128.140 50195
3(38040) SIP Request:
3(38040) method: <BYE>
3(38040) uri: <sip:396006660009@82.215.128.140>
3(38040) version: <SIP/2.0>
3(38040) parse_headers: flags=2
3(38040) Found param type 232, <branch> = <z9hG4bK2b3078b2d0c5e3bd>;
state=16
3(38040) end of header reached, state=5
3(38040) parse_headers: Via found, flags=2
3(38040) parse_headers: this is the first via
3(38040) After parse_msg...
3(38040) preparing to run routing scripts...
3(38040) parse_headers: flags=100
3(38040) DEBUG: add_param: tag=bdb21d1b47a3e954
3(38040) DEBUG:parse_to:end of header reached, state=29
3(38040) DBUG:parse_to: display={"0104491009"},
ruri={sip:0104491009@dispatcher.plexia.com}
3(38040) DEBUG: get_hdr_field: <To> [74];
uri=[sip:0104491009@dispatcher.plexia.com]
3(38040) DEBUG: to body ["0104491009"
<sip:0104491009@dispatcher.plexia.com>]
3(38040) get_hdr_field: cseq <CSeq>: <201> <BYE>
3(38040) DEBUG:maxfwd:is_maxfwd_present: value = 70
3(38040) DEBUG: add_param: tag=5539c21944091059
3(38040) DEBUG:parse_to:end of header reached, state=29
3(38040) DBUG:parse_to: display={},
ruri={sip:0104491002@dispatcher.plexia.com}
3(38040) DEBUG:avpops:dbstore_avps: 1 avps were stored
3(38040) DEBUG:avpops:dbstore_avps: 1 avps were stored
3(38040) RETURN CODE: <null> <null>
3(38040) avpops:ops_dbquery_avps: query [select value from
usr_preferences where uuid='895e6709217a9c5c(a)82.215.128.140' and
attribute='setup_time']
3(38040) avpops:ops_dbquery_avps: query [select value from
usr_preferences where uuid='895e6709217a9c5c(a)82.215.128.140' and
attribute='connect_time']
3(38040) avpops:ops_dbquery_avps: query [select value from
usr_preferences where uuid='895e6709217a9c5c(a)82.215.128.140' and
attribute='disconnect_time']
3(38040) db_flags=3, flags=4
3(38040) DEBUG:avpops:load_avps: loaded avps = 1
3(38040) parse_headers: flags=200
3(38040) is_preloaded: No
3(38040) grep_sock_info - checking if host==us: 14==14 &&
[82.215.128.140] == [82.215.130.161]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) grep_sock_info - checking if host==us: 14==9 &&
[82.215.128.140] == [127.0.0.1]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) grep_sock_info - checking if host==us: 14==14 &&
[82.215.128.140] == [82.215.130.161]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) grep_sock_info - checking if host==us: 14==9 &&
[82.215.128.140] == [127.0.0.1]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) check_self: host != me
3(38040) grep_sock_info - checking if host==us: 14==14 &&
[82.215.130.161] == [82.215.130.161]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) after_loose: Topmost route URI:
'sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20-'
is me
3(38040) parse_headers: flags=200
3(38040) DEBUG: get_hdr_body : content_length=0
3(38040) found end of header
3(38040) find_next_route: No next Route HF found
3(38040) after_loose: No next URI found
3(38040) DBG:rr:run_rr_callbacks: callback id 0 entered
3(38040) DEBUG:uac:restore_from: getting 'vsf' Route param
3(38040) DEBUG:uac:restore_from: Route param is
'AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20-' (len=52)
3(38040) DEBUG:uac:restore_from: decoded uris are:
new=[sip:396006660009@dispatcher.plexia.com]
old=[sip:0104491009@dispatcher.plexia.com]
3(38040) DEBUG: t_check: msg id=2 global id=1 T start=0xffffffff
3(38040) parse_headers: flags=ffffffffffffffff
3(38040) parse_headers: flags=78
3(38040) t_lookup_request: start searching: hash=16278, isACK=0
3(38040) DEBUG: RFC3261 transaction matching failed
3(38040) DEBUG: t_lookup_request: no transaction found
3(38040) DEBUG: t_check: msg id=2 global id=2 T end=0x0
3(38040) parse_headers: flags=ffffffffffffffff
3(38040) DEBUG: t_newtran: msg id=2 , global msg id=2 , T on entrance=0x0
3(38040) parse_headers: flags=ffffffffffffffff
3(38040) parse_headers: flags=78
3(38040) t_lookup_request: start searching: hash=16278, isACK=0
3(38040) DEBUG: RFC3261 transaction matching failed
3(38040) DEBUG: t_lookup_request: no transaction found
3(38040) DBG: trans=0x28523c48, callback type 1, id 0 entered
3(38040) parse_headers: flags=58
3(38040) DEBUG: mk_proxy: doing DNS lookup...
3(38040) check_via_address(82.215.128.141, 82.215.128.141, 0)
3(38040) DEBUG: add_to_tail_of_timer[4]: 0x28523d64
3(38040) DEBUG: add_to_tail_of_timer[0]: 0x28523d74
3(38040) SER: new transaction fwd'ed
3(38040) DEBUG:tm:UNREF_UNSAFE: after is 0
3(38040) DEBUG:destroy_avp_list: destroying list 0x0
3(38040) receive_msg: cleaning up
4(38041) SIP Reply (status):
4(38041) version: <SIP/2.0>
4(38041) status: <200>
4(38041) reason: <OK>
#
U 82.215.128.140:5060 -> 82.215.130.161:5060
INVITE sip:0104491002@dispatcher.plexia.com SIP/2.0.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bK51821efdeb8b7bf6.
From: "396006660009"
<sip:396006660009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>.
Contact: <sip:396006660009@82.215.128.140>.
Supported: replaces.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 INVITE.
User-Agent: Grandstream HT286 1.0.6.7.
Max-Forwards: 70.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Content-Length: 371.
.
v=0.
o=396006660009 8000 8000 IN IP4 82.215.128.140.
s=SIP Call.
c=IN IP4 82.215.128.140.
t=0 0.
m=audio 5004 RTP/AVP 18 0 4 2 15 98 101.
a=sendrecv.
a=rtpmap:18 G729/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:2 G726-32/8000.
a=rtpmap:15 G728/8000.
a=rtpmap:98 iLBC/8000.
a=fmtp:98 mode=20.
a=ptime:20.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.
#
U 82.215.130.161:5060 -> 82.215.128.140:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bK51821efdeb8b7bf6.
From: "396006660009"
<sip:396006660009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 INVITE.
Server: OpenSer (1.1.0-pre2-notls (i386/freebsd)).
Content-Length: 0.
Warning: 392 82.215.130.161:5060 "Noisy feedback tells: pid=38039
req_src_ip=82.215.128.140 req_src_port=5060 in_uri=sip:0104491002@dispatcher.plexia.com
out_uri=sip:396006660002@82.215.128.141 via_cnt==1".
.
#
U 82.215.130.161:5060 -> 82.215.128.141:5060
INVITE sip:396006660002@82.215.128.141 SIP/2.0.
Record-Route:
<sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20->.
Via: SIP/2.0/UDP 82.215.130.161;branch=z9hG4bK42bc.fa208bf5.0.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bK51821efdeb8b7bf6.
From: "0104491009"
<sip:0104491009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>.
Contact: <sip:396006660009@82.215.128.140>.
Supported: replaces.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 INVITE.
User-Agent: Grandstream HT286 1.0.6.7.
Max-Forwards: 69.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Content-Length: 371.
.
v=0.
o=396006660009 8000 8000 IN IP4 82.215.128.140.
s=SIP Call.
c=IN IP4 82.215.128.140.
t=0 0.
m=audio 5004 RTP/AVP 18 0 4 2 15 98 101.
a=sendrecv.
a=rtpmap:18 G729/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:2 G726-32/8000.
a=rtpmap:15 G728/8000.
a=rtpmap:98 iLBC/8000.
a=fmtp:98 mode=20.
a=ptime:20.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.
#
U 82.215.128.141:5060 -> 82.215.130.161:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 82.215.130.161;branch=z9hG4bK42bc.fa208bf5.0.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bK51821efdeb8b7bf6.
From: "0104491009"
<sip:0104491009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 INVITE.
User-Agent: Grandstream HT286 1.0.6.7.
Content-Length: 0.
.
#
U 82.215.128.141:5060 -> 82.215.130.161:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 82.215.130.161;branch=z9hG4bK42bc.fa208bf5.0.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bK51821efdeb8b7bf6.
Record-Route:
<sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20->.
From: "0104491009"
<sip:0104491009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 INVITE.
User-Agent: Grandstream HT286 1.0.6.7.
Content-Length: 0.
.
#
U 82.215.130.161:5060 -> 82.215.128.140:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bK51821efdeb8b7bf6.
Record-Route:
<sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20->.
From: "396006660009"
<sip:396006660009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 INVITE.
User-Agent: Grandstream HT286 1.0.6.7.
Content-Length: 0.
.
#
U 82.215.128.141:5060 -> 82.215.130.161:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 82.215.130.161;branch=z9hG4bK42bc.fa208bf5.0.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bK51821efdeb8b7bf6.
Record-Route:
<sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20->.
From: "0104491009"
<sip:0104491009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 INVITE.
User-Agent: Grandstream HT286 1.0.6.7.
Contact: <sip:396006660002@82.215.128.141>.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Supported: replaces.
Content-Length: 225.
.
v=0.
o=396006660002 8000 8000 IN IP4 82.215.128.141.
s=SIP Call.
c=IN IP4 82.215.128.141.
t=0 0.
m=audio 5004 RTP/AVP 18 101.
a=sendrecv.
a=rtpmap:18 G729/8000.
a=ptime:20.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.
#
U 82.215.130.161:5060 -> 82.215.128.140:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bK51821efdeb8b7bf6.
Record-Route:
<sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20->.
From: "396006660009"
<sip:396006660009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 INVITE.
User-Agent: Grandstream HT286 1.0.6.7.
Contact: <sip:396006660002@82.215.128.141>.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Supported: replaces.
Content-Length: 225.
.
v=0.
o=396006660002 8000 8000 IN IP4 82.215.128.141.
s=SIP Call.
c=IN IP4 82.215.128.141.
t=0 0.
m=audio 5004 RTP/AVP 18 101.
a=sendrecv.
a=rtpmap:18 G729/8000.
a=ptime:20.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.
#
U 82.215.128.140:5060 -> 82.215.130.161:5060
ACK sip:396006660002@82.215.128.141 SIP/2.0.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bKbb42b55628a978bd.
Route:
<sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20->.
From: "396006660009"
<sip:396006660009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
Contact: <sip:396006660009@82.215.128.140>.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 ACK.
User-Agent: Grandstream HT286 1.0.6.7.
Max-Forwards: 70.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
.
#
U 82.215.130.161:5060 -> 82.215.128.141:5060
ACK sip:396006660002@82.215.128.141 SIP/2.0.
Record-Route: <sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954>.
Via: SIP/2.0/UDP 82.215.130.161;branch=z9hG4bK42bc.fa208bf5.2.
Via: SIP/2.0/UDP 82.215.128.140;branch=z9hG4bKbb42b55628a978bd.
From: "396006660009"
<sip:0104491009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
To: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
Contact: <sip:396006660009@82.215.128.140>.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 34276 ACK.
User-Agent: Grandstream HT286 1.0.6.7.
Max-Forwards: 69.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
P-hint: rr-enforced.
.
#
U 82.215.128.140:5060 -> 82.215.130.161:5060
....
#
U 82.215.128.141:5060 -> 82.215.130.161:5060
BYE sip:396006660009@82.215.128.140 SIP/2.0.
Via: SIP/2.0/UDP 82.215.128.141;branch=z9hG4bK2b3078b2d0c5e3bd.
Route:
<sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20->.
From: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
To: "0104491009"
<sip:0104491009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 201 BYE.
User-Agent: Grandstream HT286 1.0.6.7.
Max-Forwards: 70.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
.
#
U 82.215.130.161:5060 -> 82.215.128.140:5060
BYE sip:396006660009@82.215.128.140 SIP/2.0.
Record-Route: <sip:82.215.130.161;lr=on;ftag=5539c21944091059>.
Via: SIP/2.0/UDP 82.215.130.161;branch=z9hG4bK69f3.adfb9657.0.
Via: SIP/2.0/UDP 82.215.128.141;branch=z9hG4bK2b3078b2d0c5e3bd.
From: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
To: "0104491009"
<sip:396006660009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 201 BYE.
User-Agent: Grandstream HT286 1.0.6.7.
Max-Forwards: 69.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
P-hint: rr-enforced.
.
#
U 82.215.128.140:5060 -> 82.215.130.161:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 82.215.130.161;branch=z9hG4bK69f3.adfb9657.0.
Via: SIP/2.0/UDP 82.215.128.141;branch=z9hG4bK2b3078b2d0c5e3bd.
Record-Route: <sip:82.215.130.161;lr=on;ftag=5539c21944091059>.
From: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
To: "0104491009"
<sip:396006660009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 201 BYE.
User-Agent: Grandstream HT286 1.0.6.7.
Contact: <sip:396006660009@82.215.128.140>.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Supported: replaces.
Content-Length: 0.
.
#
U 82.215.130.161:5060 -> 82.215.128.141:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 82.215.128.141;branch=z9hG4bK2b3078b2d0c5e3bd.
Record-Route: <sip:82.215.130.161;lr=on;ftag=5539c21944091059>.
From: <sip:0104491002@dispatcher.plexia.com>;tag=5539c21944091059.
To: "0104491009"
<sip:0104491009@dispatcher.plexia.com>;tag=bdb21d1b47a3e954.
Call-ID: 895e6709217a9c5c(a)82.215.128.140.
CSeq: 201 BYE.
User-Agent: Grandstream HT286 1.0.6.7.
Contact: <sip:396006660009@82.215.128.140>.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Supported: replaces.
Content-Length: 0.
.
#
30 Jun
30 Jun
8:08 p.m.
New subject: [Users] more on accounting
Hi,
as I saw in the log, the FROM restoring in BYE works properly, so
RR/Route processing is fine. Are you sure you enabled the accounting for
BYE?
just in case, I added some more debug messages about this on cvs -
please update and see the output. You should get:
DBUG:acc:acc_onreq: UPSTREAM req detected -> flaging it
and
DBUG:acc:fmt2strar: UPSTREAM flag set -> swap F/T
regards,
bogdan
tele wrote:
I've also tried with call UA --> UA that pass only from proxy and
there is the same problem on accounting.
To/From not swapped ,if the callee hangup phone, before send
accounting and yes there is RR present in the BYE message.
you can find attached here the full dump.
UA1 - 82.215.128.140
UA2 - 82.215.128.141
PROXY - 82.215.130.161
3(38040) udp_rcv_loop: probing packet received from 82.215.128.140 50195
3(38040) SIP Request:
3(38040) method: <BYE>
3(38040) uri: <sip:396006660009@82.215.128.140>
3(38040) version: <SIP/2.0>
3(38040) parse_headers: flags=2
3(38040) Found param type 232, <branch> = <z9hG4bK2b3078b2d0c5e3bd>;
state=16
3(38040) end of header reached, state=5
3(38040) parse_headers: Via found, flags=2
3(38040) parse_headers: this is the first via
3(38040) After parse_msg...
3(38040) preparing to run routing scripts...
3(38040) parse_headers: flags=100
3(38040) DEBUG: add_param: tag=bdb21d1b47a3e954
3(38040) DEBUG:parse_to:end of header reached, state=29
3(38040) DBUG:parse_to: display={"0104491009"},
ruri={sip:0104491009@dispatcher.plexia.com}
3(38040) DEBUG: get_hdr_field: <To> [74];
uri=[sip:0104491009@dispatcher.plexia.com]
3(38040) DEBUG: to body ["0104491009"
<sip:0104491009@dispatcher.plexia.com>]
3(38040) get_hdr_field: cseq <CSeq>: <201> <BYE>
3(38040) DEBUG:maxfwd:is_maxfwd_present: value = 70
3(38040) DEBUG: add_param: tag=5539c21944091059
3(38040) DEBUG:parse_to:end of header reached, state=29
3(38040) DBUG:parse_to: display={},
ruri={sip:0104491002@dispatcher.plexia.com}
3(38040) DEBUG:avpops:dbstore_avps: 1 avps were stored
3(38040) DEBUG:avpops:dbstore_avps: 1 avps were stored
3(38040) RETURN CODE: <null> <null>
3(38040) avpops:ops_dbquery_avps: query [select value from
usr_preferences where uuid='895e6709217a9c5c(a)82.215.128.140' and
attribute='setup_time']
3(38040) avpops:ops_dbquery_avps: query [select value from
usr_preferences where uuid='895e6709217a9c5c(a)82.215.128.140' and
attribute='connect_time']
3(38040) avpops:ops_dbquery_avps: query [select value from
usr_preferences where uuid='895e6709217a9c5c(a)82.215.128.140' and
attribute='disconnect_time']
3(38040) db_flags=3, flags=4
3(38040) DEBUG:avpops:load_avps: loaded avps = 1
3(38040) parse_headers: flags=200
3(38040) is_preloaded: No
3(38040) grep_sock_info - checking if host==us: 14==14 &&
[82.215.128.140] == [82.215.130.161]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) grep_sock_info - checking if host==us: 14==9 &&
[82.215.128.140] == [127.0.0.1]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) grep_sock_info - checking if host==us: 14==14 &&
[82.215.128.140] == [82.215.130.161]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) grep_sock_info - checking if host==us: 14==9 &&
[82.215.128.140] == [127.0.0.1]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) check_self: host != me
3(38040) grep_sock_info - checking if host==us: 14==14 &&
[82.215.130.161] == [82.215.130.161]
3(38040) grep_sock_info - checking if port 5060 matches port 5060
3(38040) after_loose: Topmost route URI:
'sip:82.215.130.161;lr=on;ftag=bdb21d1b47a3e954;vsf=AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20-'
is me
3(38040) parse_headers: flags=200
3(38040) DEBUG: get_hdr_body : content_length=0
3(38040) found end of header
3(38040) find_next_route: No next Route HF found
3(38040) after_loose: No next URI found
3(38040) DBG:rr:run_rr_callbacks: callback id 0 entered
3(38040) DEBUG:uac:restore_from: getting 'vsf' Route param
3(38040) DEBUG:uac:restore_from: Route param is
'AAAAAAMIBgQEDwcGAAlwXSkXGRIEAhwGGksCQhUUDBlHAkEOb20-' (len=52)
3(38040) DEBUG:uac:restore_from: decoded uris are:
new=[sip:396006660009@dispatcher.plexia.com]
old=[sip:0104491009@dispatcher.plexia.com]
3(38040) DEBUG: t_check: msg id=2 global id=1 T start=0xffffffff
3(38040) parse_headers: flags=ffffffffffffffff
3(38040) parse_headers: flags=78
3(38040) t_lookup_request: start searching: hash=16278, isACK=0
3(38040) DEBUG: RFC3261 transaction matching failed
3(38040) DEBUG: t_lookup_request: no transaction found
3(38040) DEBUG: t_check: msg id=2 global id=2 T end=0x0
3(38040) parse_headers: flags=ffffffffffffffff
3(38040) DEBUG: t_newtran: msg id=2 , global msg id=2 , T on entrance=0x0
3(38040) parse_headers: flags=ffffffffffffffff
3(38040) parse_headers: flags=78
3(38040) t_lookup_request: start searching: hash=16278, isACK=0
3(38040) DEBUG: RFC3261 transaction matching failed
3(38040) DEBUG: t_lookup_request: no transaction found
3(38040) DBG: trans=0x28523c48, callback type 1, id 0 entered
3(38040) parse_headers: flags=58
3(38040) DEBUG: mk_proxy: doing DNS lookup...
3(38040) check_via_address(82.215.128.141, 82.215.128.141, 0)
3(38040) DEBUG: add_to_tail_of_timer[4]: 0x28523d64
3(38040) DEBUG: add_to_tail_of_timer[0]: 0x28523d74
3(38040) SER: new transaction fwd'ed
3(38040) DEBUG:tm:UNREF_UNSAFE: after is 0
3(38040) DEBUG:destroy_avp_list: destroying list 0x0
3(38040) receive_msg: cleaning up
4(38041) SIP Reply (status):
4(38041) version: <SIP/2.0>
4(38041) status: <200>
4(38041) reason: <OK>
3 Jul
3 Jul
9:44 a.m.
New subject: [Users] more on accounting
Hi Bogdan,
I've updated to last CVS-head version. but in the log i can't see debug
messages.
maybe there is an error in my accounting configuration. pls have a look:
modparam("acc", "log_level", 2)
modparam("acc", "log_fmt", "cdfimorstup")
modparam("acc", "report_ack", 0)
modparam("acc", "detect_direction", 1)
modparam("acc", "radius_flag", 3)
modparam("acc", "radius_missed_flag", 5)
modparam("acc", "radius_config",
"/usr/local/etc/radiusclient-ng/radiusclient_auth.conf")
modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
h323-connect-time=$avp(connect_time);
h323-disconnect-time=$avp(disconnect_time);
h323-remote-address=$avp(remote_address)")
and before loose_route() i have:
if (is_method("BYE"))
{
setflag(3);
setflag(5);
};
is it correct?
Bogdan-Andrei Iancu wrote:
Hi,
as I saw in the log, the FROM restoring in BYE works properly, so
RR/Route processing is fine. Are you sure you enabled the accounting
for BYE?
just in case, I added some more debug messages about this on cvs -
please update and see the output. You should get:
DBUG:acc:acc_onreq: UPSTREAM req detected -> flaging it
and
DBUG:acc:fmt2strar: UPSTREAM flag set -> swap F/T
7 Jul
7 Jul
7:26 p.m.
New subject: [Users] more on accounting
Hi bogdan,
now it works i can see the debug messages and OpenSER correctly swap
From/To for the accounting.
But i didn't change the config, the only thing is that now signalling
message come from another proxy and not directly from UA.
thank you for the support.
On Mon, 2006-07-03 at 09:44 +0200, tele wrote:
Hi Bogdan,
I've updated to last CVS-head version. but in the log i can't see debug
messages.
maybe there is an error in my accounting configuration. pls have a look:
modparam("acc", "log_level", 2)
modparam("acc", "log_fmt", "cdfimorstup")
modparam("acc", "report_ack", 0)
modparam("acc", "detect_direction", 1)
modparam("acc", "radius_flag", 3)
modparam("acc", "radius_missed_flag", 5)
modparam("acc", "radius_config",
"/usr/local/etc/radiusclient-ng/radiusclient_auth.conf")
modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
h323-connect-time=$avp(connect_time);
h323-disconnect-time=$avp(disconnect_time);
h323-remote-address=$avp(remote_address)")
and before loose_route() i have:
if (is_method("BYE"))
{
setflag(3);
setflag(5);
};
is it correct?
Bogdan-Andrei Iancu wrote:
Hi,
as I saw in the log, the FROM restoring in BYE works properly, so
RR/Route processing is fine. Are you sure you enabled the accounting
for BYE?
just in case, I added some more debug messages about this on cvs -
please update and see the output. You should get:
DBUG:acc:acc_onreq: UPSTREAM req detected -> flaging it
and
DBUG:acc:fmt2strar: UPSTREAM flag set -> swap F/T
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
10 Jul
10 Jul
1:44 p.m.
New subject: [Users] more on accounting
Hi,
in this case it means that the UA you were using was not correctly using
via the RR/Route headers and the RR header inserted by OpenSER was not
correctly mirrored into a Route hdr - this header is used to determine
the direction of the sequential requests.
regards,
bogdan
tele wrote:
Hi bogdan,
now it works i can see the debug messages and OpenSER correctly swap
From/To for the accounting.
But i didn't change the config, the only thing is that now signalling
message come from another proxy and not directly from UA.
thank you for the support.
On Mon, 2006-07-03 at 09:44 +0200, tele wrote:
Hi Bogdan,
I've updated to last CVS-head version. but in the log i can't see debug
messages.
maybe there is an error in my accounting configuration. pls have a look:
modparam("acc", "log_level", 2)
modparam("acc", "log_fmt", "cdfimorstup")
modparam("acc", "report_ack", 0)
modparam("acc", "detect_direction", 1)
modparam("acc", "radius_flag", 3)
modparam("acc", "radius_missed_flag", 5)
modparam("acc", "radius_config",
"/usr/local/etc/radiusclient-ng/radiusclient_auth.conf")
modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
h323-connect-time=$avp(connect_time);
h323-disconnect-time=$avp(disconnect_time);
h323-remote-address=$avp(remote_address)")
and before loose_route() i have:
if (is_method("BYE"))
{
setflag(3);
setflag(5);
};
is it correct?
Bogdan-Andrei Iancu wrote:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Hi,
as I saw in the log, the FROM restoring in BYE works properly, so
RR/Route processing is fine. Are you sure you enabled the accounting
for BYE?
just in case, I added some more debug messages about this on cvs -
please update and see the output. You should get:
DBUG:acc:acc_onreq: UPSTREAM req detected -> flaging it
and
DBUG:acc:fmt2strar: UPSTREAM flag set -> swap F/T
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
4:33 p.m.
New subject: [Users] more on accounting
Hi,
Can you point me to some documentation about the ftag parameter in the
RR/Route header?
I've search in the RFCs but not found any informations about.
thank you
On Mon, 2006-07-10 at 14:44 +0300, Bogdan-Andrei Iancu wrote:
Hi,
in this case it means that the UA you were using was not correctly using
via the RR/Route headers and the RR header inserted by OpenSER was not
correctly mirrored into a Route hdr - this header is used to determine
the direction of the sequential requests.
regards,
bogdan
tele wrote:
Hi bogdan,
now it works i can see the debug messages and OpenSER correctly swap
From/To for the accounting.
But i didn't change the config, the only thing is that now signalling
message come from another proxy and not directly from UA.
thank you for the support.
On Mon, 2006-07-03 at 09:44 +0200, tele wrote:
Hi Bogdan,
I've updated to last CVS-head version. but in the log i can't see debug
messages.
maybe there is an error in my accounting configuration. pls have a look:
modparam("acc", "log_level", 2)
modparam("acc", "log_fmt", "cdfimorstup")
modparam("acc", "report_ack", 0)
modparam("acc", "detect_direction", 1)
modparam("acc", "radius_flag", 3)
modparam("acc", "radius_missed_flag", 5)
modparam("acc", "radius_config",
"/usr/local/etc/radiusclient-ng/radiusclient_auth.conf")
modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
h323-connect-time=$avp(connect_time);
h323-disconnect-time=$avp(disconnect_time);
h323-remote-address=$avp(remote_address)")
and before loose_route() i have:
if (is_method("BYE"))
{
setflag(3);
setflag(5);
};
is it correct?
Bogdan-Andrei Iancu wrote:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Hi,
as I saw in the log, the FROM restoring in BYE works properly, so
RR/Route processing is fine. Are you sure you enabled the accounting
for BYE?
just in case, I added some more debug messages about this on cvs -
please update and see the output. You should get:
DBUG:acc:acc_onreq: UPSTREAM req detected -> flaging it
and
DBUG:acc:fmt2strar: UPSTREAM flag set -> swap F/T
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11 Jul
11 Jul
8:30 a.m.
New subject: [Users] more on accounting
Hi,
ftag is something specific to OpenSER/SER, there is no standard doc/spec
about it. The idea behind is to add the from tag to the Record-Route
header when the initial request passes. by comparing this value (the tag
of original from hdr) with the from tag of the sequential requests you
can figure out the direction of this request.
regards,
bogdan
tele wrote:
Hi,
Can you point me to some documentation about the ftag parameter in the
RR/Route header?
I've search in the RFCs but not found any informations about.
thank you
On Mon, 2006-07-10 at 14:44 +0300, Bogdan-Andrei Iancu wrote:
>Hi,
>
>in this case it means that the UA you were using was not correctly using
>via the RR/Route headers and the RR header inserted by OpenSER was not
>correctly mirrored into a Route hdr - this header is used to determine
>the direction of the sequential requests.
>
>regards,
>bogdan
>
>tele wrote:
>
>
>
>>Hi bogdan,
>>
>>now it works i can see the debug messages and OpenSER correctly swap
>>From/To for the accounting.
>>
>>But i didn't change the config, the only thing is that now signalling
>>message come from another proxy and not directly from UA.
>>
>>thank you for the support.
>>
>>On Mon, 2006-07-03 at 09:44 +0200, tele wrote:
>>
>>
>>
>>
>>>Hi Bogdan,
>>>
>>>I've updated to last CVS-head version. but in the log i can't see
debug
>>>messages.
>>>maybe there is an error in my accounting configuration. pls have a look:
>>>
>>>modparam("acc", "log_level", 2)
>>>modparam("acc", "log_fmt", "cdfimorstup")
>>>modparam("acc", "report_ack", 0)
>>>modparam("acc", "detect_direction", 1)
>>>modparam("acc", "radius_flag", 3)
>>>modparam("acc", "radius_missed_flag", 5)
>>>modparam("acc", "radius_config",
>>>"/usr/local/etc/radiusclient-ng/radiusclient_auth.conf")
>>>modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
>>>h323-connect-time=$avp(connect_time);
>>>h323-disconnect-time=$avp(disconnect_time);
>>>h323-remote-address=$avp(remote_address)")
>>>
>>>and before loose_route() i have:
>>>
>>>if (is_method("BYE"))
>>>{
>>> setflag(3);
>>> setflag(5);
>>>};
>>>
>>>is it correct?
>>>
>>>Bogdan-Andrei Iancu wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>as I saw in the log, the FROM restoring in BYE works properly, so
>>>>RR/Route processing is fine. Are you sure you enabled the accounting
>>>>for BYE?
>>>>
>>>>just in case, I added some more debug messages about this on cvs -
>>>>please update and see the output. You should get:
>>>> DBUG:acc:acc_onreq: UPSTREAM req detected -> flaging it
>>>>and
>>>> DBUG:acc:fmt2strar: UPSTREAM flag set -> swap F/T
>>>>
>>>>
1:03 p.m.
New subject: [Users] more on accounting
Hi bogdan,
Unfortunaly the BYE come from my SoftSwitch is without route header.
I'm try to do something like that:
SS ------> OpenSER(acct) ----> OpenSER
BYE BYE BYE
OpenSER(acct) <----
maybe if the BYE come from another proxy it can recognize the ftag
paramater and do the correct accounting.
Or do have you others idea?
On Tue, 2006-07-11 at 09:30 +0300, Bogdan-Andrei Iancu wrote:
Hi,
ftag is something specific to OpenSER/SER, there is no standard doc/spec
about it. The idea behind is to add the from tag to the Record-Route
header when the initial request passes. by comparing this value (the tag
of original from hdr) with the from tag of the sequential requests you
can figure out the direction of this request.
regards,
bogdan
tele wrote:
>Hi,
>
>Can you point me to some documentation about the ftag parameter in the
>RR/Route header?
>I've search in the RFCs but not found any informations about.
>
>thank you
>
>On Mon, 2006-07-10 at 14:44 +0300, Bogdan-Andrei Iancu wrote:
>
>
>>Hi,
>>
>>in this case it means that the UA you were using was not correctly using
>>via the RR/Route headers and the RR header inserted by OpenSER was not
>>correctly mirrored into a Route hdr - this header is used to determine
>>the direction of the sequential requests.
>>
>>regards,
>>bogdan
>>
>>tele wrote:
>>
>>
>>
>>>Hi bogdan,
>>>
>>>now it works i can see the debug messages and OpenSER correctly swap
>>>From/To for the accounting.
>>>
>>>But i didn't change the config, the only thing is that now signalling
>>>message come from another proxy and not directly from UA.
>>>
>>>thank you for the support.
>>>
>>>On Mon, 2006-07-03 at 09:44 +0200, tele wrote:
>>>
>>>
>>>
>>>
>>>>Hi Bogdan,
>>>>
>>>>I've updated to last CVS-head version. but in the log i can't see
debug
>>>>messages.
>>>>maybe there is an error in my accounting configuration. pls have a look:
>>>>
>>>>modparam("acc", "log_level", 2)
>>>>modparam("acc", "log_fmt", "cdfimorstup")
>>>>modparam("acc", "report_ack", 0)
>>>>modparam("acc", "detect_direction", 1)
>>>>modparam("acc", "radius_flag", 3)
>>>>modparam("acc", "radius_missed_flag", 5)
>>>>modparam("acc", "radius_config",
>>>>"/usr/local/etc/radiusclient-ng/radiusclient_auth.conf")
>>>>modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
>>>>h323-connect-time=$avp(connect_time);
>>>>h323-disconnect-time=$avp(disconnect_time);
>>>>h323-remote-address=$avp(remote_address)")
>>>>
>>>>and before loose_route() i have:
>>>>
>>>>if (is_method("BYE"))
>>>>{
>>>> setflag(3);
>>>> setflag(5);
>>>>};
>>>>
>>>>is it correct?
>>>>
>>>>Bogdan-Andrei Iancu wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>as I saw in the log, the FROM restoring in BYE works properly, so
>>>>>RR/Route processing is fine. Are you sure you enabled the accounting
>>>>>for BYE?
>>>>>
>>>>>just in case, I added some more debug messages about this on cvs -
>>>>>please update and see the output. You should get:
>>>>> DBUG:acc:acc_onreq: UPSTREAM req detected -> flaging it
>>>>>and
>>>>> DBUG:acc:fmt2strar: UPSTREAM flag set -> swap F/T
>>>>>
>>>>>
14 Jul
14 Jul
7:55 p.m.
New subject: [Users] more on accounting
Hi,
if a RR hdr is present in INVITE/200 OK, it must be present in all
sequential request of that dialog, including the BYE. If your SS doesn't
do so, it means it is nor RFC SIP compliant and you should report the
bug to the vendor.
I don't thing is any way around as it generates the BYE.
regards,
bogdan
tele wrote:
Hi bogdan,
Unfortunaly the BYE come from my SoftSwitch is without route header.
I'm try to do something like that:
SS ------> OpenSER(acct) ----> OpenSER
BYE BYE BYE
OpenSER(acct) <----
maybe if the BYE come from another proxy it can recognize the ftag
paramater and do the correct accounting.
Or do have you others idea?
On Tue, 2006-07-11 at 09:30 +0300, Bogdan-Andrei Iancu wrote:
>Hi,
>
>ftag is something specific to OpenSER/SER, there is no standard doc/spec
>about it. The idea behind is to add the from tag to the Record-Route
>header when the initial request passes. by comparing this value (the tag
>of original from hdr) with the from tag of the sequential requests you
>can figure out the direction of this request.
>
>regards,
>bogdan
>
>tele wrote:
>
>
>
>>Hi,
>>
>>Can you point me to some documentation about the ftag parameter in the
>>RR/Route header?
>>I've search in the RFCs but not found any informations about.
>>
>>thank you
>>
>>On Mon, 2006-07-10 at 14:44 +0300, Bogdan-Andrei Iancu wrote:
>>
>>
>>
>>
>>>Hi,
>>>
>>>in this case it means that the UA you were using was not correctly using
>>>via the RR/Route headers and the RR header inserted by OpenSER was not
>>>correctly mirrored into a Route hdr - this header is used to determine
>>>the direction of the sequential requests.
>>>
>>>regards,
>>>bogdan
>>>
>>>
8:43 p.m.
New subject: [Users] Display Name
Hi, I wanna know when actualize Display Name.
and how to send to all contact list. (what is the message?)
best regards
Javier Ramirez
17 Jul
17 Jul
4:37 p.m.
New subject: [Users] Display Name
Hi, I wanna know when actualize Display Name.
and how to send to all contact list. (what is the message?)
best regards
Javier Ramirez
19 Jul
19 Jul
7:11 p.m.
New subject: [Users] Display Name
Hi, I wanna know when actualize Display Name.
and how to send to all contact list. (what is the message?)
best regards
Javier Ramirez
7:47 p.m.
New subject: [Users] Display Name
marco ...... ( polo?)
----- Original Message -----
From: Javier Ramirez
To: users
Sent: Wednesday, July 19, 2006 2:11 PM
Subject: Re: [Users] Display Name
Hi, I wanna know when actualize Display Name.
and how to send to all contact list. (what is the message?)
best regards
Javier Ramirez
------------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:53 p.m.
New subject: [Users] Display Name
Mork calling Mindi.....
----- Original Message -----
From: Javier Ramirez
To: Javier Ramirez ; users
Sent: Wednesday, July 19, 2006 2:47 PM
Subject: Re: [Users] Display Name
marco ...... ( polo?)
----- Original Message -----
From: Javier Ramirez
To: users
Sent: Wednesday, July 19, 2006 2:11 PM
Subject: Re: [Users] Display Name
Hi, I wanna know when actualize Display Name.
and how to send to all contact list. (what is the message?)
best regards
Javier Ramirez
----------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
20 Jul
20 Jul
8:59 a.m.
New subject: [Users] Display Name
Hello,
to get an answer, people must understand your question, otherwise they
cannot help. Also, to not reply to another message from the list since
it will go to the old thread.
On 07/19/06 20:11, Javier Ramirez wrote:
Hi, I wanna know when actualize Display Name.
when you want it, display name is set on your SIP phone.
and how to send to all contact list. (what is the
message?)
which contact list? from your sip client? what to send? A message? A
call?
Cheers,
Daniel
best regards
Javier Ramirez
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
12 Jul
12 Jul
2:53 p.m.
New subject: [Users] more on accounting
modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
h323-connect-time=$avp(connect_time);
h323-disconnect-time=$avp(disconnect_time);
Hello,
I need this time informations for radius accounting, and i must decide
to make this avps in openser, or manage this times in radius server
(in BSDRadius it's not so difficult...)
I quess it'is not so easy to make this avps in openser,
-create timestamp for particular messages (invite, ack, bye)
-store the avps in database
-and send to radius this attributes on accounting-request
Do you use this method, or is there any better solution?
Thanks any help,
Tamas
13 Jul
13 Jul
9:15 a.m.
New subject: [Users] more on accounting
Hi tamas,
Contact me if you need more information.
What you can do depend on your billing system.
This is what i have done from OpenSER:
# avpops params
modparam("avpops","avp_url","mysql://openser:openserrw@localhost/openser")
modparam("avpops", "avp_table", "usr_preferences")
# avp for accounting
modparam("avpops","avp_aliases","setup_time=s:setup_time")
modparam("avpops","avp_aliases","connect_time=s:connect_time")
modparam("avpops","avp_aliases","disconnect_time=s:disconnect_time")
modparam("avpops","avp_aliases","remote_address=s:remote_address")
modparam("avpops","avp_aliases","valid_call=s:valid_call")
if (!method=="REGISTER")
record_route();
# ACCOUNTING
if (is_method("INVITE"))
{
avp_write("$Ts","$avp(setup_time)");
avp_db_store("$ci","$avp(setup_time)");
# invite come from PSTN this call should not be accounted
if (src_ip=='PSTNGW')
{
avp_write("no","$avp(valid_call)");
avp_db_store("$ci","$avp(valid_call)");
} else {
# valid call this must accounted
avp_write("yes","$avp(valid_call)");
avp_db_store("$ci","$avp(valid_call)");
};
} else if (is_method("ACK")) {
avp_write("$Ts","$avp(connect_time)");
avp_db_store("$ci","$avp(connect_time)");
} else if (is_method("BYE")) {
avp_write("$Ts","$avp(disconnect_time)");
avp_db_store("$ci","$avp(disconnect_time)");
avp_write("82.215.163.5","$avp(remote_address)");
avp_db_store("$ci","$avp(remote_address)");
};
if (is_method("BYE"))
{
avp_db_query("select value from usr_preferences where uuid='$ci'
and attribute='setup_time'","$avp(setup_time)");
avp_db_query("select value from usr_preferences where uuid='$ci'
and attribute='connect_time'","$avp(connect_time)");
avp_db_query("select value from usr_preferences where uuid='$ci'
and attribute='disconnect_time'","$avp(disconnect_time)");
avp_db_query("select value from usr_preferences where uuid='$ci'
and attribute='valid_call'","$avp(valid_call)");
avp_db_load("$ci","$avp(remote_address)");
avp_print();
# BYE from announcement server or valid call
# not account this call
if (!src_ip=='ANNSERVER' and
avp_check("$avp(valid_call)","eq/yes/g"))
{
# send radius acct
setflag(3);
setflag(5);
};
};
# clean avps from db
if (is_method("BYE|CANCEL"))
{
avp_db_delete("$ci","$avp(setup_time)");
avp_db_delete("$ci","$avp(connect_time)");
avp_db_delete("$ci","$avp(disconnect_time)");
avp_db_delete("$ci","$avp(remote_address)");
avp_db_delete("$ci","$avp(valid_call)");
};
On Wed, 2006-07-12 at 14:53 +0200, Cseke Tamas wrote:
modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
h323-connect-time=$avp(connect_time);
h323-disconnect-time=$avp(disconnect_time);
Hello,
I need this time informations for radius accounting, and i must decide
to make this avps in openser, or manage this times in radius server
(in BSDRadius it's not so difficult...)
I quess it'is not so easy to make this avps in openser,
-create timestamp for particular messages (invite, ack, bye)
-store the avps in database
-and send to radius this attributes on accounting-request
Do you use this method, or is there any better solution?
Thanks any help,
Tamas
6 Sep
6 Sep
10:11 a.m.
New subject: [Users] more on accounting
Hi
I've an accounting problem, i think you could maybe help me.
we'd like to use radius accounting with openser.
We'd like to set setuptime, connecttime, endtime in Cdr-s for rating.
Our openser has no database connection, so ew can't use your solution(
store avps in database)
i planned to send accounting packets to radius on INVITE , ACK and BYE.
And in radius module (BSDRadius) store the system time into database on
INVITE for setuptime , on ACK for connecttime and on
BYE for endtime,
But the accounting packet for INVITE (Sip-Method: INVITE,
Acct-Status-Type: Start) radius doest' receive
correct in time, openser send it almost in the same time as the packet
for ACK, so setuptime is not correct, it is almost equal to connecttime,
however the phone was ringing long.
And we would like some reliable method for storing the time informations.
Because of the network delay between openser and radius the time
information can be not correct exactly.
Please let me know, why the accounting packets for INVITE is sent in
incorrect way, and
if someone know a better solution for storing a setuptime, connecttime
and endtime for a cdr please let me know.
Is there any radius attributes for example in which we can send this
time informations to radius server?
Thanks any help
Tamas
Hi tamas,
Contact me if you need more information.
What you can do depend on your billing system.
This is what i have done from OpenSER:
# avpops params
modparam("avpops","avp_url","mysql://openser:openserrw@localhost/openser")
modparam("avpops", "avp_table", "usr_preferences")
# avp for accounting
modparam("avpops","avp_aliases","setup_time=s:setup_time")
modparam("avpops","avp_aliases","connect_time=s:connect_time")
modparam("avpops","avp_aliases","disconnect_time=s:disconnect_time")
modparam("avpops","avp_aliases","remote_address=s:remote_address")
modparam("avpops","avp_aliases","valid_call=s:valid_call")
if (!method=="REGISTER")
record_route();
# ACCOUNTING
if (is_method("INVITE"))
{
avp_write("$Ts","$avp(setup_time)");
avp_db_store("$ci","$avp(setup_time)");
# invite come from PSTN this call should not be accounted
if (src_ip=='PSTNGW')
{
avp_write("no","$avp(valid_call)");
avp_db_store("$ci","$avp(valid_call)");
} else {
# valid call this must accounted
avp_write("yes","$avp(valid_call)");
avp_db_store("$ci","$avp(valid_call)");
};
} else if (is_method("ACK")) {
avp_write("$Ts","$avp(connect_time)");
avp_db_store("$ci","$avp(connect_time)");
} else if (is_method("BYE")) {
avp_write("$Ts","$avp(disconnect_time)");
avp_db_store("$ci","$avp(disconnect_time)");
avp_write("82.215.163.5","$avp(remote_address)");
avp_db_store("$ci","$avp(remote_address)");
};
if (is_method("BYE"))
{
avp_db_query("select value from usr_preferences where uuid='$ci'
and attribute='setup_time'","$avp(setup_time)");
avp_db_query("select value from usr_preferences where uuid='$ci'
and attribute='connect_time'","$avp(connect_time)");
avp_db_query("select value from usr_preferences where uuid='$ci'
and attribute='disconnect_time'","$avp(disconnect_time)");
avp_db_query("select value from usr_preferences where uuid='$ci'
and attribute='valid_call'","$avp(valid_call)");
avp_db_load("$ci","$avp(remote_address)");
avp_print();
# BYE from announcement server or valid call
# not account this call
if (!src_ip=='ANNSERVER' and
avp_check("$avp(valid_call)","eq/yes/g"))
{
# send radius acct
setflag(3);
setflag(5);
};
};
# clean avps from db
if (is_method("BYE|CANCEL"))
{
avp_db_delete("$ci","$avp(setup_time)");
avp_db_delete("$ci","$avp(connect_time)");
avp_db_delete("$ci","$avp(disconnect_time)");
avp_db_delete("$ci","$avp(remote_address)");
avp_db_delete("$ci","$avp(valid_call)");
};
On Wed, 2006-07-12 at 14:53 +0200, Cseke Tamas wrote:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
modparam("acc", "radius_extra",
"h323-setup-time=$avp(setup_time);
h323-connect-time=$avp(connect_time);
h323-disconnect-time=$avp(disconnect_time);
Hello,
I need this time informations for radius accounting, and i must decide
to make this avps in openser, or manage this times in radius server
(in BSDRadius it's not so difficult...)
I quess it'is not so easy to make this avps in openser,
-create timestamp for particular messages (invite, ack, bye)
-store the avps in database
-and send to radius this attributes on accounting-request
Do you use this method, or is there any better solution?
Thanks any help,
Tamas
6439
days inactive
6509
days old
21 comments
5 participants
participants (5)
-
Bogdan-Andrei Iancu -
Cseke Tamas -
Daniel-Constantin Mierla -
Javier Ramirez -
tele