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@openser.org [mailto:users-bounces@openser.org] On Behalf Of tele Sent: Wednesday, June 28, 2006 11:05 AM To: users@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@openser.org [mailto:users-bounces@openser.org] On Behalf Of tele Sent: Wednesday, June 28, 2006 11:05 AM To: users@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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>
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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Hi,
as you can seem the incoming BYE has no Route header. This leads to these cases:
- you do not do record_route - check the outgoing INVITE to see if
your RR hdr is present
yes is present
- the RR set is not properly mirrored in the 200 OK (again, check
the 200 OK reply)
yes there is
- 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@82.215.128.140' and attribute='setup_time'] 3(38040) avpops:ops_dbquery_avps: query [select value from usr_preferences where uuid='895e6709217a9c5c@82.215.128.140' and attribute='connect_time'] 3(38040) avpops:ops_dbquery_avps: query [select value from usr_preferences where uuid='895e6709217a9c5c@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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. .
#
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@82.215.128.140' and attribute='setup_time'] 3(38040) avpops:ops_dbquery_avps: query [select value from usr_preferences where uuid='895e6709217a9c5c@82.215.128.140' and attribute='connect_time'] 3(38040) avpops:ops_dbquery_avps: query [select value from usr_preferences where uuid='895e6709217a9c5c@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>
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
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
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
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
Hi, I wanna know when actualize Display Name. and how to send to all contact list. (what is the message?) best regards Javier Ramirez
Hi, I wanna know when actualize Display Name. and how to send to all contact list. (what is the message?) best regards Javier Ramirez
Hi, I wanna know when actualize Display Name. and how to send to all contact list. (what is the message?) best regards Javier Ramirez
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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
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
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' andavp_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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
Cseke Tamas -
Daniel-Constantin Mierla -
Javier Ramirez -
tele