I'm trying to play around with the current cvs head but can't get it to work. I wonder if somebody could give me a hint!
I built a redirect server: It basically does:
rewritehost("ab5350.node-1.com"); sl_send_reply("302", "Redirect");
I forward to the redirect server setting up a failure block:
if(is_method("INVITE")) { _QLOG(L_INFO, OUTBOUNDCALL, OUT);
t_on_failure("3");
record_route(); setflag(1); setflag(2);
rewritehostport(_QSTR (REDIRECTOBGATEWAYIP:REDIRECTOBGATEWAYPORT));
if(!t_relay()) { sl_reply_error(); } }
The response below comes back from my redirect server:
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 12.46.104.47;branch=z9hG4bKa86.09801851.0 Via: SIP/2.0/UDP 12.46.104.62:5061;branch=z9hG4bKa86.191c2c81.0 Via: SIP/2.0/UDP 12.46.104.59;branch=z9hG4bKa86.dafc0771.0 Via: SIP/2.0/UDP 71.252.176.37:5060;branch=z9hG4bK-d0702751 From: +19722200434 sip:+19722200434@var-2.com;tag=3a553a2b9373c699 To: sip:2143357976@var-2.com;tag=5531b0101f56e37a4889ece4b0eb40fa.417f Call-ID: f27483a5-50532031@71.252.176.37 CSeq: 101 INVITE Contact: sip:+12143357976@ab5350.node-1.com:5060 Content-Length: 0
My failure_route block picks up the routing:
failure_route[3] { _QLOG(L_WARN, FAILUREROUTE, here we are);
if(status =~ "3[0-9][0-9]") { _QLOG(L_WARN, FAILUREROUTE, status is 3xx); get_redirects("*"); serialize_branches(0); } if(next_branches()) { _QLOG(L_WARN, FAILUREROUTE, next branch); t_on_failure("3"); t_relay(); } _QLOG(L_WARN, FAILUREROUTE, no branches left); if(!t_reply("404", "Not Found")) { _QLOG(L_WARN, FAILUREROUTE, Error); } }
My syslog shows QLOG messages. I see the 'status is 3xx' message, which shows the next command to be get_redirects("*");
The next output I see in my syslog is 'no branches left', which indicates that the serialize_branches(0) and next_branches() aren't working as I expected.
I've also tried getting rid of the serialize_branches and next_branches and just doing a t_relay() after the get_redirects(), that doesn't work either.
Since I'm trying to simulate the redirect server, and the redirect client, I'm sure I got one of them wrong. Can somebody give me a hint?
Thanks!
-g
Hi,
I am trying to run the following setup.
Xten<-->Openser<-->Asterisk openser ip = 192.168.1.21:5060 asterisk ip = 192.168.1.21:5070 xten = 192.168.1.35:5070
Xten is registered with openser and calls with particular prefixes are forwarded to asterisk. I record route all messages passing through openser. The initial INVITE and 200 OK messages are exchanged successfully but the associated ACK messages are not processed properly by openser. Part of the 200 OK received by xten is shown below
Via: SIP/2.0/UDP 192.168.1.23:5070;received=192.168.1.35;rport=5070;branch=z9hG4bK5B7D03B5696C9316CD87AB79100D0893 Record-Route: sip:192.168.1.21;lr=on;ftag=386046356 From: 1956 sip:1956@192.168.1.21:5070;tag=386046356 To: sip:1313263@192.168.1.21;tag=as36bd8053 Contact: sip:1313263@192.168.1.21:5070
The ACK sent out by xten is shown below
Request-Line: ACK sip:1313263@192.168.1.21:5070 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.23:5070;rport;branch=z9hG4bK3F391943F7AC4F861033318A443F92D7 From: 1956 sip:1956@192.168.1.21:5070;tag=386046356 To: sip:1313263@192.168.1.21;tag=as36bd8053 Contact: sip:1956@192.168.1.23:5070 Route: sip:192.168.1.21;lr=on;ftag=386046356
As can be seen, xten sets the RURI with the contact value received from 200 OK and Route is populated with the value from Record-Route. When openser receives this ACK message, instead of confirming the Route address as its own it resets the RURI with the Route header value (which happens to be the openser address) and sends it out causing it loop back. It should have confirmed the Route value was its own address and removed it from the Route list. The ACK packet is shown below
Request-Line: ACK sip:192.168.1.21;lr=on;ftag=386046356 SIP/2.0 Message Header Record-Route: sip:192.168.1.21;lr=on;ftag=386046356 Via: SIP/2.0/UDP 192.168.1.21;branch=0 Via: SIP/2.0/UDP 192.168.1.23:5070;received=192.168.1.35;rport=5070;branch=z9hG4bK3F391943F7AC4F861033318A443F92D7 From: 1956 sip:1956@192.168.1.21:5070;tag=386046356 To: sip:1313263@192.168.1.21;tag=as36bd8053 Contact: sip:1956@192.168.1.35:5070
For reference, Iam attaching relevant parts of my cfg and debug output. Kindly guide me if I need to rewrite my cfg in a particular way or is there a bug in openser, since I believe xten is behaving correctly. I am using the latest development version of openser, although I tested on the previous stable release as well, with the same results. BTW BYE messages sent out by xten also suffer the same fate as ACKS.
Regards, Danish
DEBUG OUTPUT 4(17830) SIP Request: 4(17830) method: <ACK> 4(17830) uri: sip:1313263@192.168.1.21:5070 4(17830) version: <SIP/2.0> 4(17830) parse_headers: flags=2 4(17830) Found param type 235, <rport> = <n/a>; state=6 4(17830) Found param type 232, <branch> = <z9hG4bK3F391943F7AC4F861033318A443F92D7>; state=16 4(17830) end of header reached, state=5 4(17830) parse_headers: Via found, flags=2 4(17830) parse_headers: this is the first via 4(17830) After parse_msg... 4(17830) preparing to run routing scripts... 4(17830) DEBUG : sl_filter_ACK: to late to be a local ACK! 4(17830) parse_headers: flags=100 4(17830) DEBUG: add_param: tag=as36bd8053 4(17830) DEBUG:parse_to:end of header reached, state=29 4(17830) DBUG:parse_to: display={}, ruri={sip:1313263@192.168.1.21} 4(17830) DEBUG: get_hdr_field: <To> [47]; uri= [sip:1313263@192.168.1.21] 4(17830) DEBUG: to body [sip:1313263@192.168.1.21] 4(17830) get_hdr_field: cseq <CSeq>: <39751> <ACK> 4(17830) DEBUG:maxfwd:is_maxfwd_present: value = 70 4(17830) DEBUG: add_param: tag=386046356 4(17830) DEBUG:parse_to:end of header reached, state=29 4(17830) DBUG:parse_to: display={1956}, ruri= {sip:1956@192.168.1.21:5070} 4(17830) parse_headers: flags=200 4(17830) is_preloaded: No 4(17830) grep_sock_info - checking if host==us: 12==12 && [192.168.1.21] == [192.168.1.21] 4(17830) grep_sock_info - checking if port 5060 matches port 5070 4(17830) grep_sock_info - checking if host==us: 12==12 && [192.168.1.21] == [192.168.1.21] 4(17830) grep_sock_info - checking if port 5060 matches port 5070 4(17830) after_strict: Next hop: 'sip:192.168.1.21;lr=on;ftag=386046356' is loose router 4(17830) parse_headers: flags=ffffffffffffffff 4(17830) DEBUG: get_hdr_body : content_length=0 4(17830) found end of header 4(17830) rewrite_uri: Rewriting Request-URI with 'sip:192.168.1.21;lr=on;ftag=386046356' 4(17830) after_strict: The last route URI: 'sip:192.168.1.21;lr=on;ftag=386046356' 4(17830) Danish: Entering loose route for method [ACK] 4(17830) DEBUG: has_totag: totag found openser.cfg:
modparam("rr", "enable_full_lr", 1)
route {
# ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); return; };
if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); return; };
# ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (!method=="REGISTER") { record_route(); };
if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); }
# ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) {
if (has_totag() && (method=="INVITE" || method =="ACK" || method=="BYE" || method=="INFO")) {
if (nat_uac_test("2")) {
setflag(6); force_rport(); fix_nated_contact(); }; if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } }; route(1); return; };
route[1] {
# ----------------------------------------------------------------- # Default Message Handler # -----------------------------------------------------------------
if (!t_relay()) {
if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); }; sl_reply_error(); }; }
Hi Danish,
openser sees the sip:1313263@192.168.1.21:5070 RURI from local as local - as the debug info shows, the after_strict routing processing is done.
What aliases and listen do you have set in the script?
regards, bogdan
Danish Samad wrote:
Hi,
I am trying to run the following setup.
Xten<-->Openser<-->Asterisk openser ip = 192.168.1.21:5060 asterisk ip = 192.168.1.21:5070 xten = 192.168.1.35:5070
Xten is registered with openser and calls with particular prefixes are forwarded to asterisk. I record route all messages passing through openser. The initial INVITE and 200 OK messages are exchanged successfully but the associated ACK messages are not processed properly by openser. Part of the 200 OK received by xten is shown below
Via: SIP/2.0/UDP 192.168.1.23:5070;received=192.168.1.35;rport=5070;branch=z9hG4bK5B7D03B5696C9316CD87AB79100D0893 Record-Route: sip:192.168.1.21;lr=on;ftag=386046356 From: 1956 <sip:1956@192.168.1.21 mailto:1956@192.168.1.21:5070>;tag=386046356 To: <sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21>;tag=as36bd8053 Contact: <sip:1313263@192.168.1.21 mailto:1313263@192.168.1.21:5070>
The ACK sent out by xten is shown below
Request-Line: ACK sip:1313263@192.168.1.21:5070 SIP/2.0 Message Header Via: SIP/2.0/UDP192.168.1.23:5070;rport;branch=z9hG4bK3F391943F7AC4F861033318A443F92D7 From: 1956 <sip:1956@192.168.1.21 mailto:1956@192.168.1.21:5070>;tag=386046356 To: <sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21>;tag=as36bd8053 Contact: <sip:1956@192.168.1.23 mailto:1956@192.168.1.23:5070> Route: sip:192.168.1.21;lr=on;ftag=386046356
As can be seen, xten sets the RURI with the contact value received from 200 OK and Route is populated with the value from Record-Route. When openser receives this ACK message, instead of confirming the Route address as its own it resets the RURI with the Route header value (which happens to be the openser address) and sends it out causing it loop back. It should have confirmed the Route value was its own address and removed it from the Route list. The ACK packet is shown below
Request-Line: ACK sip:192.168.1.21;lr=on;ftag=386046356 SIP/2.0 Message Header Record-Route: sip:192.168.1.21;lr=on;ftag=386046356 Via: SIP/2.0/UDP 192.168.1.21;branch=0 Via: SIP/2.0/UDP 192.168.1.23:5070;received=192.168.1.35;rport=5070;branch=z9hG4bK3F391943F7AC4F861033318A443F92D7 From: 1956 <sip:1956@192.168.1.21 mailto:1956@192.168.1.21:5070>;tag=386046356 To: <sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21>;tag=as36bd8053 Contact: <sip:1956@192.168.1.35 mailto:1956@192.168.1.35:5070>
For reference, Iam attaching relevant parts of my cfg and debug output. Kindly guide me if I need to rewrite my cfg in a particular way or is there a bug in openser, since I believe xten is behaving correctly. I am using the latest development version of openser, although I tested on the previous stable release as well, with the same results. BTW BYE messages sent out by xten also suffer the same fate as ACKS.
Regards, Danish
*DEBUG OUTPUT* 4(17830) SIP Request: 4(17830) method: <ACK> 4(17830) uri: <sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21:5070> 4(17830) version: <SIP/2.0> 4(17830) parse_headers: flags=2 4(17830) Found param type 235, <rport> = <n/a>; state=6 4(17830) Found param type 232, <branch> = <z9hG4bK3F391943F7AC4F861033318A443F92D7>; state=16 4(17830) end of header reached, state=5 4(17830) parse_headers: Via found, flags=2 4(17830) parse_headers: this is the first via 4(17830) After parse_msg... 4(17830) preparing to run routing scripts... 4(17830) DEBUG : sl_filter_ACK: to late to be a local ACK! 4(17830) parse_headers: flags=100 4(17830) DEBUG: add_param: tag=as36bd8053 4(17830) DEBUG:parse_to:end of header reached, state=29 4(17830) DBUG:parse_to: display={}, ruri={sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21} 4(17830) DEBUG: get_hdr_field: <To> [47]; uri=[sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21] 4(17830) DEBUG: to body [<sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21>] 4(17830) get_hdr_field: cseq <CSeq>: <39751> <ACK> 4(17830) DEBUG:maxfwd:is_maxfwd_present: value = 70 4(17830) DEBUG: add_param: tag=386046356 4(17830) DEBUG:parse_to:end of header reached, state=29 4(17830) DBUG:parse_to: display={1956}, ruri={sip:1956@192.168.1.21 mailto:1956@192.168.1.21:5070} 4(17830) parse_headers: flags=200 4(17830) is_preloaded: No 4(17830) grep_sock_info - checking if host==us: 12==12 && [192.168.1.21] == [192.168.1.21] 4(17830) grep_sock_info - checking if port 5060 matches port 5070 4(17830) grep_sock_info - checking if host==us: 12==12 && [192.168.1.21] == [192.168.1.21] 4(17830) grep_sock_info - checking if port 5060 matches port 5070 4(17830) after_strict: Next hop: 'sip:192.168.1.21;lr=on;ftag=386046356' is loose router 4(17830) parse_headers: flags=ffffffffffffffff 4(17830) DEBUG: get_hdr_body : content_length=0 4(17830) found end of header 4(17830) rewrite_uri: Rewriting Request-URI with 'sip:192.168.1.21;lr=on;ftag=386046356' 4(17830) after_strict: The last route URI: 'sip:192.168.1.21;lr=on;ftag=386046356' 4(17830) Danish: Entering loose route for method [ACK] 4(17830) DEBUG: has_totag: totag found *openser.cfg:*
modparam("rr", "enable_full_lr", 1)
route {
# ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); return; };
if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); return; };
# ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (!method=="REGISTER") { record_route(); };
if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); }
# ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) {
if (has_totag() && (method=="INVITE" || method =="ACK" || method=="BYE" || method=="INFO")) {
if (nat_uac_test("2")) { setflag(6); force_rport(); fix_nated_contact(); };if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } }; route(1); return; };
route[1] {
# ----------------------------------------------------------------- # Default Message Handler # -----------------------------------------------------------------
if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); }; sl_reply_error(); };}
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi bogdan,
Thanks for your reply. I was surfing through some old mails and found out that record routing is dependent on the alias and listen values. After I added port values to these parameters the problem was solved.
Regards, Danish On Mon, 2006-06-05 at 12:23 +0300, Bogdan-Andrei Iancu wrote:
Hi Danish,
openser sees the sip:1313263@192.168.1.21:5070 RURI from local as local
- as the debug info shows, the after_strict routing processing is done.
What aliases and listen do you have set in the script?
regards, bogdan
Danish Samad wrote:
Hi,
I am trying to run the following setup.
Xten<-->Openser<-->Asterisk openser ip = 192.168.1.21:5060 asterisk ip = 192.168.1.21:5070 xten = 192.168.1.35:5070
Xten is registered with openser and calls with particular prefixes are forwarded to asterisk. I record route all messages passing through openser. The initial INVITE and 200 OK messages are exchanged successfully but the associated ACK messages are not processed properly by openser. Part of the 200 OK received by xten is shown below
Via: SIP/2.0/UDP 192.168.1.23:5070;received=192.168.1.35;rport=5070;branch=z9hG4bK5B7D03B5696C9316CD87AB79100D0893 Record-Route: sip:192.168.1.21;lr=on;ftag=386046356 From: 1956 <sip:1956@192.168.1.21 mailto:1956@192.168.1.21:5070>;tag=386046356 To: <sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21>;tag=as36bd8053 Contact: <sip:1313263@192.168.1.21 mailto:1313263@192.168.1.21:5070>
The ACK sent out by xten is shown below
Request-Line: ACK sip:1313263@192.168.1.21:5070 SIP/2.0 Message Header Via: SIP/2.0/UDP192.168.1.23:5070;rport;branch=z9hG4bK3F391943F7AC4F861033318A443F92D7 From: 1956 <sip:1956@192.168.1.21 mailto:1956@192.168.1.21:5070>;tag=386046356 To: <sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21>;tag=as36bd8053 Contact: <sip:1956@192.168.1.23 mailto:1956@192.168.1.23:5070> Route: sip:192.168.1.21;lr=on;ftag=386046356
As can be seen, xten sets the RURI with the contact value received from 200 OK and Route is populated with the value from Record-Route. When openser receives this ACK message, instead of confirming the Route address as its own it resets the RURI with the Route header value (which happens to be the openser address) and sends it out causing it loop back. It should have confirmed the Route value was its own address and removed it from the Route list. The ACK packet is shown below
Request-Line: ACK sip:192.168.1.21;lr=on;ftag=386046356 SIP/2.0 Message Header Record-Route: sip:192.168.1.21;lr=on;ftag=386046356 Via: SIP/2.0/UDP 192.168.1.21;branch=0 Via: SIP/2.0/UDP 192.168.1.23:5070;received=192.168.1.35;rport=5070;branch=z9hG4bK3F391943F7AC4F861033318A443F92D7 From: 1956 <sip:1956@192.168.1.21 mailto:1956@192.168.1.21:5070>;tag=386046356 To: <sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21>;tag=as36bd8053 Contact: <sip:1956@192.168.1.35 mailto:1956@192.168.1.35:5070>
For reference, Iam attaching relevant parts of my cfg and debug output. Kindly guide me if I need to rewrite my cfg in a particular way or is there a bug in openser, since I believe xten is behaving correctly. I am using the latest development version of openser, although I tested on the previous stable release as well, with the same results. BTW BYE messages sent out by xten also suffer the same fate as ACKS.
Regards, Danish
*DEBUG OUTPUT* 4(17830) SIP Request: 4(17830) method: <ACK> 4(17830) uri: <sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21:5070> 4(17830) version: <SIP/2.0> 4(17830) parse_headers: flags=2 4(17830) Found param type 235, <rport> = <n/a>; state=6 4(17830) Found param type 232, <branch> = <z9hG4bK3F391943F7AC4F861033318A443F92D7>; state=16 4(17830) end of header reached, state=5 4(17830) parse_headers: Via found, flags=2 4(17830) parse_headers: this is the first via 4(17830) After parse_msg... 4(17830) preparing to run routing scripts... 4(17830) DEBUG : sl_filter_ACK: to late to be a local ACK! 4(17830) parse_headers: flags=100 4(17830) DEBUG: add_param: tag=as36bd8053 4(17830) DEBUG:parse_to:end of header reached, state=29 4(17830) DBUG:parse_to: display={}, ruri={sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21} 4(17830) DEBUG: get_hdr_field: <To> [47]; uri=[sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21] 4(17830) DEBUG: to body [<sip:1313263@192.168.1.21 mailto:13132630141@192.168.1.21>] 4(17830) get_hdr_field: cseq <CSeq>: <39751> <ACK> 4(17830) DEBUG:maxfwd:is_maxfwd_present: value = 70 4(17830) DEBUG: add_param: tag=386046356 4(17830) DEBUG:parse_to:end of header reached, state=29 4(17830) DBUG:parse_to: display={1956}, ruri={sip:1956@192.168.1.21 mailto:1956@192.168.1.21:5070} 4(17830) parse_headers: flags=200 4(17830) is_preloaded: No 4(17830) grep_sock_info - checking if host==us: 12==12 && [192.168.1.21] == [192.168.1.21] 4(17830) grep_sock_info - checking if port 5060 matches port 5070 4(17830) grep_sock_info - checking if host==us: 12==12 && [192.168.1.21] == [192.168.1.21] 4(17830) grep_sock_info - checking if port 5060 matches port 5070 4(17830) after_strict: Next hop: 'sip:192.168.1.21;lr=on;ftag=386046356' is loose router 4(17830) parse_headers: flags=ffffffffffffffff 4(17830) DEBUG: get_hdr_body : content_length=0 4(17830) found end of header 4(17830) rewrite_uri: Rewriting Request-URI with 'sip:192.168.1.21;lr=on;ftag=386046356' 4(17830) after_strict: The last route URI: 'sip:192.168.1.21;lr=on;ftag=386046356' 4(17830) Danish: Entering loose route for method [ACK] 4(17830) DEBUG: has_totag: totag found *openser.cfg:*
modparam("rr", "enable_full_lr", 1)
route {
# ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); return; };
if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); return; };
# ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (!method=="REGISTER") { record_route(); };
if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); }
# ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) {
if (has_totag() && (method=="INVITE" || method =="ACK" || method=="BYE" || method=="INFO")) {
if (nat_uac_test("2")) { setflag(6); force_rport(); fix_nated_contact(); };if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } }; route(1); return; };
route[1] {
# ----------------------------------------------------------------- # Default Message Handler # -----------------------------------------------------------------
if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); }; sl_reply_error(); };}
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Danish,
yes that's the problem - if you set an IP as alias, the lack of a port number will be interpreted as a wildcard...
regards, bogdan
Danish Samad wrote:
Hi bogdan,
Thanks for your reply. I was surfing through some old mails and found out that record routing is dependent on the alias and listen values. After I added port values to these parameters the problem was solved.
Regards, Danish On Mon, 2006-06-05 at 12:23 +0300, Bogdan-Andrei Iancu wrote:
Hi Danish,
openser sees the sip:1313263@192.168.1.21:5070 RURI from local as local
- as the debug info shows, the after_strict routing processing is done.
What aliases and listen do you have set in the script?
regards, bogdan
Danish Samad wrote:
Hi,
I am trying to run the following setup.
Xten<-->Openser<-->Asterisk openser ip = 192.168.1.21:5060 asterisk ip = 192.168.1.21:5070 xten = 192.168.1.35:5070
Xten is registered with openser and calls with particular prefixes are forwarded to asterisk. I record route all messages passing through openser. The initial INVITE and 200 OK messages are exchanged successfully but the associated ACK messages are not processed properly by openser. Part of the 200 OK received by xten is shown below
Reply to my own message!
I've been working on this all weekend. Had an issue with a firewall which was blocking redirect packets, that cleared up a bunch.
Now, I have the get_redirects("*") working, serialize_branches(0) is working (kinda, it says it has nothing to do because all data has the same q value), and I see a debug message when I call next_branches() which says DEBUG:next_branches: no AVPs -- we are done!
My ser.cfg file is below. How do I get rid of 'no AVPs' error? I thought the domain modparam would activate them?
-g # 1 "config.pre" # 32 "config.pre" # 1 "/usr/local/etc/ser/include/opensererror.pre" 1 # 33 "config.pre" 2 # 140 "config.pre" mpath="/usr/local/lib/openser/modules"
loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "dbtext.so" loadmodule "domain.so" loadmodule "uac_redirect.so"
log_stderror=no log_facility=LOG_LOCAL5 listen=12.46.104.47 port=5060 children=4 disable_tcp=yes dns_try_ipv6=no server_signature=no sip_warning=0
alias="redirect.node-1.com" alias="proxy.redirect.node-1.com" alias="12.46.104.47"
fifo="/tmp/ser_fifo/proxy"
modparam("tm","fr_inv_timer",180) modparam("domain", "db_url", "dbtext:///var/openserdb")
route {
if (!mf_process_maxfwd_header("13")) { xlog("L_WARN","redirect.node-1.com-483: time_t=$Ts ^LINE=184 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Too many hops"); sl_send_reply("483", "Too many hops"); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=186 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(loose_route()) { xlog("L_WARN","redirect.node-1.com-LOOSE: time_t=$Ts ^LINE=188 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Doing it"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=190 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(!uri==myself) { xlog("L_WARN","redirect.node-1.com-NOTUS: time_t=$Ts ^LINE=192 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=forward packet"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=194 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(src_ip==12.46.104.62) { � xlog("L_INFO","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=201 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT"); � if(is_method("INVITE")) � { �� xlog("L_WARN","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=204 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT");
�� t_on_failure("3");
�� record_route();
�� rewritehostport("198.212.169.6:5060");
�� if(!t_relay()) �� { � � sl_reply_error(); �� } �� return; � } }
xlog("L_WARN","redirect.node-1.com-404: time_t=$Ts ^LINE=224 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no route found"); sl_send_reply("404", "no route found"); return; } # 235 "config.pre" failure_route[3] { xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=237 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=here we are");
if(t_check_status("3[0-9][0-9]")) { � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=241 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=status is 3xx"); � get_redirects("*"); � serialize_branches(0); } next_branches(); � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=246 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=next branch"); � t_on_failure("3"); � t_relay(); � return; xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=250 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no branches left"); t_reply("404", "No branches left"); }
On 6/3/06, Greg Fausak lgfausak@gmail.com wrote:
I'm trying to play around with the current cvs head but can't get it to work. I wonder if somebody could give me a hint!
I built a redirect server: It basically does:
rewritehost("ab5350.node-1.com"); sl_send_reply("302", "Redirect");
I forward to the redirect server setting up a failure block:
if(is_method("INVITE")) { _QLOG(L_INFO, OUTBOUNDCALL, OUT); t_on_failure("3"); record_route(); setflag(1); setflag(2); rewritehostport(_QSTR(REDIRECTOBGATEWAYIP:REDIRECTOBGATEWAYPORT));
if(!t_relay()) { sl_reply_error(); } }The response below comes back from my redirect server:
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 12.46.104.47;branch=z9hG4bKa86.09801851.0 Via: SIP/2.0/UDP 12.46.104.62:5061;branch=z9hG4bKa86.191c2c81.0 Via: SIP/2.0/UDP 12.46.104.59;branch=z9hG4bKa86.dafc0771.0 Via: SIP/2.0/UDP 71.252.176.37:5060;branch=z9hG4bK-d0702751 From: +19722200434 sip:+19722200434@var-2.com;tag=3a553a2b9373c699 To: sip:2143357976@var-2.com;tag=5531b0101f56e37a4889ece4b0eb40fa.417f Call-ID: f27483a5-50532031@71.252.176.37 CSeq: 101 INVITE Contact: sip:+12143357976@ab5350.node-1.com:5060 Content-Length: 0
My failure_route block picks up the routing:
failure_route[3] { _QLOG(L_WARN, FAILUREROUTE, here we are);
if(status =~ "3[0-9][0-9]") { _QLOG(L_WARN, FAILUREROUTE, status is 3xx); get_redirects("*"); serialize_branches(0); } if(next_branches()) { _QLOG(L_WARN, FAILUREROUTE, next branch); t_on_failure("3"); t_relay(); } _QLOG(L_WARN, FAILUREROUTE, no branches left); if(!t_reply("404", "Not Found")) { _QLOG(L_WARN, FAILUREROUTE, Error); }}
My syslog shows QLOG messages. I see the 'status is 3xx' message, which shows the next command to be get_redirects("*");
The next output I see in my syslog is 'no branches left', which indicates that the serialize_branches(0) and next_branches() aren't working as I expected.
I've also tried getting rid of the serialize_branches and next_branches and just doing a t_relay() after the get_redirects(), that doesn't work either.
Since I'm trying to simulate the redirect server, and the redirect client, I'm sure I got one of them wrong. Can somebody give me a hint?
Thanks!
-g
-- Greg Fausak greg@thursday.com
Hi Greg,
message "DEBUG:next_branches: no AVPs -- we are done!" is generated by next_branches() function if no AVP is found to get a new branch.
in debug mode you may see what branches are loaded into AVPS by serialize_branches(). Also you may use avp_print() to see what are the current AVPs.
regards, bogdan
Greg Fausak wrote:
Reply to my own message!
I've been working on this all weekend. Had an issue with a firewall which was blocking redirect packets, that cleared up a bunch.
Now, I have the get_redirects("*") working, serialize_branches(0) is working (kinda, it says it has nothing to do because all data has the same q value), and I see a debug message when I call next_branches() which says DEBUG:next_branches: no AVPs -- we are done!
My ser.cfg file is below. How do I get rid of 'no AVPs' error? I thought the domain modparam would activate them?
-g # 1 "config.pre" # 32 "config.pre" # 1 "/usr/local/etc/ser/include/opensererror.pre" 1 # 33 "config.pre" 2 # 140 "config.pre" mpath="/usr/local/lib/openser/modules"
loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "dbtext.so" loadmodule "domain.so" loadmodule "uac_redirect.so"
log_stderror=no log_facility=LOG_LOCAL5 listen=12.46.104.47 port=5060 children=4 disable_tcp=yes dns_try_ipv6=no server_signature=no sip_warning=0
alias="redirect.node-1.com" alias="proxy.redirect.node-1.com" alias="12.46.104.47"
fifo="/tmp/ser_fifo/proxy"
modparam("tm","fr_inv_timer",180) modparam("domain", "db_url", "dbtext:///var/openserdb")
route {
if (!mf_process_maxfwd_header("13")) { xlog("L_WARN","redirect.node-1.com-483: time_t=$Ts ^LINE=184 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Too many hops"); sl_send_reply("483", "Too many hops"); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=186 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(loose_route()) { xlog("L_WARN","redirect.node-1.com-LOOSE: time_t=$Ts ^LINE=188 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Doing it"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=190 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(!uri==myself) { xlog("L_WARN","redirect.node-1.com-NOTUS: time_t=$Ts ^LINE=192 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=forward packet"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=194 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(src_ip==12.46.104.62) { � xlog("L_INFO","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=201 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT"); � if(is_method("INVITE")) � { �� xlog("L_WARN","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=204 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT");
�� t_on_failure("3");
�� record_route();
�� rewritehostport("198.212.169.6:5060");
�� if(!t_relay()) �� { � � sl_reply_error(); �� } �� return; � } }
xlog("L_WARN","redirect.node-1.com-404: time_t=$Ts ^LINE=224 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no route found"); sl_send_reply("404", "no route found"); return; } # 235 "config.pre" failure_route[3] { xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=237 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=here we are");
if(t_check_status("3[0-9][0-9]")) { � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=241 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=status is 3xx"); � get_redirects("*"); � serialize_branches(0); } next_branches(); � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=246 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=next branch"); � t_on_failure("3"); � t_relay(); � return; xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=250 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no branches left"); t_reply("404", "No branches left"); }
On 6/3/06, Greg Fausak lgfausak@gmail.com wrote:
I'm trying to play around with the current cvs head but can't get it to work. I wonder if somebody could give me a hint!
I built a redirect server: It basically does:
rewritehost("ab5350.node-1.com"); sl_send_reply("302", "Redirect");
I forward to the redirect server setting up a failure block:
if(is_method("INVITE")) { _QLOG(L_INFO, OUTBOUNDCALL, OUT);
t_on_failure("3");
record_route(); setflag(1); setflag(2);
rewritehostport(_QSTR (REDIRECTOBGATEWAYIP:REDIRECTOBGATEWAYPORT));
if(!t_relay()) { sl_reply_error(); } }
The response below comes back from my redirect server:
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 12.46.104.47;branch=z9hG4bKa86.09801851.0 Via: SIP/2.0/UDP 12.46.104.62:5061;branch=z9hG4bKa86.191c2c81.0 Via: SIP/2.0/UDP 12.46.104.59;branch=z9hG4bKa86.dafc0771.0 Via: SIP/2.0/UDP 71.252.176.37:5060;branch=z9hG4bK-d0702751 From: +19722200434 sip:+19722200434@var-2.com;tag=3a553a2b9373c699 To: sip:2143357976@var-2.com;tag=5531b0101f56e37a4889ece4b0eb40fa.417f Call-ID: f27483a5-50532031@71.252.176.37 CSeq: 101 INVITE Contact: sip:+12143357976@ab5350.node-1.com:5060 Content-Length: 0
My failure_route block picks up the routing:
failure_route[3] { _QLOG(L_WARN, FAILUREROUTE, here we are);
if(status =~ "3[0-9][0-9]") { _QLOG(L_WARN, FAILUREROUTE, status is 3xx); get_redirects("*"); serialize_branches(0); } if(next_branches()) { _QLOG(L_WARN, FAILUREROUTE, next branch); t_on_failure("3"); t_relay(); } _QLOG(L_WARN, FAILUREROUTE, no branches left); if(!t_reply("404", "Not Found")) { _QLOG(L_WARN, FAILUREROUTE, Error); } }
My syslog shows QLOG messages. I see the 'status is 3xx' message, which shows the next command to be get_redirects("*");
The next output I see in my syslog is 'no branches left', which indicates that the serialize_branches(0) and next_branches() aren't working as I expected.
I've also tried getting rid of the serialize_branches and next_branches and just doing a t_relay() after the get_redirects(), that doesn't work either.
Since I'm trying to simulate the redirect server, and the redirect client, I'm sure I got one of them wrong. Can somebody give me a hint?
Thanks!
-g
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan,
Thanks,
I thought the serialize_branches(0) loaded up the AVP?
-g
On 6/5/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Greg,
message "DEBUG:next_branches: no AVPs -- we are done!" is generated by next_branches() function if no AVP is found to get a new branch.
in debug mode you may see what branches are loaded into AVPS by serialize_branches(). Also you may use avp_print() to see what are the current AVPs.
regards, bogdan
Greg Fausak wrote:
Reply to my own message!
I've been working on this all weekend. Had an issue with a firewall which was blocking redirect packets, that cleared up a bunch.
Now, I have the get_redirects("*") working, serialize_branches(0) is working (kinda, it says it has nothing to do because all data has the same q value), and I see a debug message when I call next_branches() which says DEBUG:next_branches: no AVPs -- we are done!
My ser.cfg file is below. How do I get rid of 'no AVPs' error? I thought the domain modparam would activate them?
-g # 1 "config.pre" # 32 "config.pre" # 1 "/usr/local/etc/ser/include/opensererror.pre" 1 # 33 "config.pre" 2 # 140 "config.pre" mpath="/usr/local/lib/openser/modules"
loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "dbtext.so" loadmodule "domain.so" loadmodule "uac_redirect.so"
log_stderror=no log_facility=LOG_LOCAL5 listen=12.46.104.47 port=5060 children=4 disable_tcp=yes dns_try_ipv6=no server_signature=no sip_warning=0
alias="redirect.node-1.com" alias="proxy.redirect.node-1.com" alias="12.46.104.47"
fifo="/tmp/ser_fifo/proxy"
modparam("tm","fr_inv_timer",180) modparam("domain", "db_url", "dbtext:///var/openserdb")
route {
if (!mf_process_maxfwd_header("13")) { xlog("L_WARN","redirect.node-1.com-483: time_t=$Ts ^LINE=184 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Too many hops"); sl_send_reply("483", "Too many hops"); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=186 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(loose_route()) { xlog("L_WARN","redirect.node-1.com-LOOSE: time_t=$Ts ^LINE=188 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Doing it"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=190 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(!uri==myself) { xlog("L_WARN","redirect.node-1.com-NOTUS: time_t=$Ts ^LINE=192 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=forward packet"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=194 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(src_ip==12.46.104.62) { � xlog("L_INFO","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=201 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT"); � if(is_method("INVITE")) � { �� xlog("L_WARN","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=204 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT");
�� t_on_failure("3");
�� record_route();
�� rewritehostport("198.212.169.6:5060");
�� if(!t_relay()) �� { � � sl_reply_error(); �� } �� return; � } }
xlog("L_WARN","redirect.node-1.com-404: time_t=$Ts ^LINE=224 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no route found"); sl_send_reply("404", "no route found"); return; } # 235 "config.pre" failure_route[3] { xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=237 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=here we are");
if(t_check_status("3[0-9][0-9]")) { � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=241 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=status is 3xx"); � get_redirects("*"); � serialize_branches(0); } next_branches(); � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=246 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=next branch"); � t_on_failure("3"); � t_relay(); � return; xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=250 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no branches left"); t_reply("404", "No branches left"); }
On 6/3/06, Greg Fausak lgfausak@gmail.com wrote:
I'm trying to play around with the current cvs head but can't get it to work. I wonder if somebody could give me a hint!
I built a redirect server: It basically does:
rewritehost("ab5350.node-1.com"); sl_send_reply("302", "Redirect");
I forward to the redirect server setting up a failure block:
if(is_method("INVITE")) { _QLOG(L_INFO, OUTBOUNDCALL, OUT);
t_on_failure("3");
record_route(); setflag(1); setflag(2);
rewritehostport(_QSTR (REDIRECTOBGATEWAYIP:REDIRECTOBGATEWAYPORT));
if(!t_relay()) { sl_reply_error(); } }
The response below comes back from my redirect server:
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 12.46.104.47;branch=z9hG4bKa86.09801851.0 Via: SIP/2.0/UDP 12.46.104.62:5061;branch=z9hG4bKa86.191c2c81.0 Via: SIP/2.0/UDP 12.46.104.59;branch=z9hG4bKa86.dafc0771.0 Via: SIP/2.0/UDP 71.252.176.37:5060;branch=z9hG4bK-d0702751 From: +19722200434 sip:+19722200434@var-2.com;tag=3a553a2b9373c699 To: sip:2143357976@var-2.com;tag=5531b0101f56e37a4889ece4b0eb40fa.417f Call-ID: f27483a5-50532031@71.252.176.37 CSeq: 101 INVITE Contact: sip:+12143357976@ab5350.node-1.com:5060 Content-Length: 0
My failure_route block picks up the routing:
failure_route[3] { _QLOG(L_WARN, FAILUREROUTE, here we are);
if(status =~ "3[0-9][0-9]") { _QLOG(L_WARN, FAILUREROUTE, status is 3xx); get_redirects("*"); serialize_branches(0); } if(next_branches()) { _QLOG(L_WARN, FAILUREROUTE, next branch); t_on_failure("3"); t_relay(); } _QLOG(L_WARN, FAILUREROUTE, no branches left); if(!t_reply("404", "Not Found")) { _QLOG(L_WARN, FAILUREROUTE, Error); } }
My syslog shows QLOG messages. I see the 'status is 3xx' message, which shows the next command to be get_redirects("*");
The next output I see in my syslog is 'no branches left', which indicates that the serialize_branches(0) and next_branches() aren't working as I expected.
I've also tried getting rid of the serialize_branches and next_branches and just doing a t_relay() after the get_redirects(), that doesn't work either.
Since I'm trying to simulate the redirect server, and the redirect client, I'm sure I got one of them wrong. Can somebody give me a hint?
Thanks!
-g
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
yes - get_redirects("*") loads the contacts from 3xx reply into branches (as for parallel forking) ; serialize_branches(0) converts the branches into AVPs for serial forking ; next_branches() gets the first AVP for serial forking and push it as branch.
the message from next_branches() says all AVPs fro serial branches were consumed - or none was present from the beginning.
regards, Bogdan
Greg Fausak wrote:
Bogdan,
Thanks,
I thought the serialize_branches(0) loaded up the AVP?
-g
On 6/5/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Greg,
message "DEBUG:next_branches: no AVPs -- we are done!" is generated by next_branches() function if no AVP is found to get a new branch.
in debug mode you may see what branches are loaded into AVPS by serialize_branches(). Also you may use avp_print() to see what are the current AVPs.
regards, bogdan
Greg Fausak wrote:
Reply to my own message!
I've been working on this all weekend. Had an issue with a firewall which was blocking redirect packets, that cleared up a bunch.
Now, I have the get_redirects("*") working, serialize_branches(0) is working (kinda, it says it has nothing to do because all data has the same q value), and I see a debug message when I call next_branches() which says DEBUG:next_branches: no AVPs -- we are done!
My ser.cfg file is below. How do I get rid of 'no AVPs' error? I thought the domain modparam would activate them?
-g # 1 "config.pre" # 32 "config.pre" # 1 "/usr/local/etc/ser/include/opensererror.pre" 1 # 33 "config.pre" 2 # 140 "config.pre" mpath="/usr/local/lib/openser/modules"
loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "dbtext.so" loadmodule "domain.so" loadmodule "uac_redirect.so"
log_stderror=no log_facility=LOG_LOCAL5 listen=12.46.104.47 port=5060 children=4 disable_tcp=yes dns_try_ipv6=no server_signature=no sip_warning=0
alias="redirect.node-1.com" alias="proxy.redirect.node-1.com" alias="12.46.104.47"
fifo="/tmp/ser_fifo/proxy"
modparam("tm","fr_inv_timer",180) modparam("domain", "db_url", "dbtext:///var/openserdb")
route {
if (!mf_process_maxfwd_header("13")) { xlog("L_WARN","redirect.node-1.com-483: time_t=$Ts ^LINE=184 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Too many hops"); sl_send_reply("483", "Too many hops"); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=186 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(loose_route()) { xlog("L_WARN","redirect.node-1.com-LOOSE: time_t=$Ts ^LINE=188 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Doing it"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=190 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(!uri==myself) { xlog("L_WARN","redirect.node-1.com-NOTUS: time_t=$Ts ^LINE=192 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=forward packet"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=194 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(src_ip==12.46.104.62) { � xlog("L_INFO","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=201 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT"); � if(is_method("INVITE")) � { �� xlog("L_WARN","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=204 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT");
�� t_on_failure("3");
�� record_route();
�� rewritehostport("198.212.169.6:5060");
�� if(!t_relay()) �� { � � sl_reply_error(); �� } �� return; � } }
xlog("L_WARN","redirect.node-1.com-404: time_t=$Ts ^LINE=224 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no route found"); sl_send_reply("404", "no route found"); return; } # 235 "config.pre" failure_route[3] { xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=237 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=here we are");
if(t_check_status("3[0-9][0-9]")) { � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=241 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=status is 3xx"); � get_redirects("*"); � serialize_branches(0); } next_branches(); � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=246 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=next branch"); � t_on_failure("3"); � t_relay(); � return; xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=250 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no branches left"); t_reply("404", "No branches left"); }
On 6/3/06, Greg Fausak lgfausak@gmail.com wrote:
I'm trying to play around with the current cvs head but can't get
it to
work. I wonder if somebody could give me a hint!
I built a redirect server: It basically does:
rewritehost("ab5350.node-1.com"); sl_send_reply("302", "Redirect");
I forward to the redirect server setting up a failure block:
if(is_method("INVITE")) { _QLOG(L_INFO, OUTBOUNDCALL, OUT);
t_on_failure("3");
record_route(); setflag(1); setflag(2);
rewritehostport(_QSTR (REDIRECTOBGATEWAYIP:REDIRECTOBGATEWAYPORT));
if(!t_relay()) { sl_reply_error(); } }
The response below comes back from my redirect server:
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 12.46.104.47;branch=z9hG4bKa86.09801851.0 Via: SIP/2.0/UDP 12.46.104.62:5061;branch=z9hG4bKa86.191c2c81.0 Via: SIP/2.0/UDP 12.46.104.59;branch=z9hG4bKa86.dafc0771.0 Via: SIP/2.0/UDP 71.252.176.37:5060;branch=z9hG4bK-d0702751 From: +19722200434 sip:+19722200434@var-2.com;tag=3a553a2b9373c699 To:
sip:2143357976@var-2.com;tag=5531b0101f56e37a4889ece4b0eb40fa.417f
Call-ID: f27483a5-50532031@71.252.176.37 CSeq: 101 INVITE Contact: sip:+12143357976@ab5350.node-1.com:5060 Content-Length: 0
My failure_route block picks up the routing:
failure_route[3] { _QLOG(L_WARN, FAILUREROUTE, here we are);
if(status =~ "3[0-9][0-9]") { _QLOG(L_WARN, FAILUREROUTE, status is 3xx); get_redirects("*"); serialize_branches(0); } if(next_branches()) { _QLOG(L_WARN, FAILUREROUTE, next branch); t_on_failure("3"); t_relay(); } _QLOG(L_WARN, FAILUREROUTE, no branches left); if(!t_reply("404", "Not Found")) { _QLOG(L_WARN, FAILUREROUTE, Error); } }
My syslog shows QLOG messages. I see the 'status is 3xx' message, which shows the next command to be get_redirects("*");
The next output I see in my syslog is 'no branches left', which indicates that the serialize_branches(0) and next_branches() aren't working as I
expected.
I've also tried getting rid of the serialize_branches and next_branches and just doing a t_relay() after the get_redirects(), that doesn't work
either.
Since I'm trying to simulate the redirect server, and the redirect client, I'm sure I got one of them wrong. Can somebody give me a hint?
Thanks!
-g
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan,
I recompiled openser and reinstalled, it's working for me now. I think I hacked something up and caused it to break!
One thing I still am curious about. I've got a domain name with an SRV record: ab5350.node-1.com, the SRV (_sip._udp.ab5350.node-1.com) points to a single A record proxy.ab5350.node-1.com. When I make that the Contact in the redirect I get this in the syslog:
Jun 5 09:39:51 www openser: DEBUG: mk_proxy: doing DNS lookup... Jun 5 09:39:51 www openser: DEBUG:sip_resolvehost2: has port -> do A record lookup! Jun 5 09:39:51 www openser: ERROR: mk_proxy: could not resolve hostname: "ab5350.node-1.com" Jun 5 09:39:51 www openser: ERROR: uri2proxy: bad host name in URI sip:+12143357976@ab5350.node-1.com:5060 Jun 5 09:39:51 www openser: ERROR:tm:t_forward_nonack: failure to add branches Jun 5 09:39:51 www openser: ERROR:tm:w_t_relay: t_forward_nonack failed Jun 5 09:39:51 www openser: DEBUG:tm:relay_reply: branch=0, save=0, relay=0
My code does a next_branches() followed by t_relay(). I thought that t_relay() did the necessary SRV lookups?
If I change my redirect to return proxy.ab5350.node-1.com in the Contact list, everything works as expected.
-g
On 6/5/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
yes - get_redirects("*") loads the contacts from 3xx reply into branches (as for parallel forking) ; serialize_branches(0) converts the branches into AVPs for serial forking ; next_branches() gets the first AVP for serial forking and push it as branch.
the message from next_branches() says all AVPs fro serial branches were consumed - or none was present from the beginning.
regards, Bogdan
Greg Fausak wrote:
Bogdan,
Thanks,
I thought the serialize_branches(0) loaded up the AVP?
-g
On 6/5/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Greg,
message "DEBUG:next_branches: no AVPs -- we are done!" is generated by next_branches() function if no AVP is found to get a new branch.
in debug mode you may see what branches are loaded into AVPS by serialize_branches(). Also you may use avp_print() to see what are the current AVPs.
regards, bogdan
Greg Fausak wrote:
Reply to my own message!
I've been working on this all weekend. Had an issue with a firewall which was blocking redirect packets, that cleared up a bunch.
Now, I have the get_redirects("*") working, serialize_branches(0) is working (kinda, it says it has nothing to do because all data has the same q value), and I see a debug message when I call next_branches() which says DEBUG:next_branches: no AVPs -- we are done!
My ser.cfg file is below. How do I get rid of 'no AVPs' error? I thought the domain modparam would activate them?
-g # 1 "config.pre" # 32 "config.pre" # 1 "/usr/local/etc/ser/include/opensererror.pre" 1 # 33 "config.pre" 2 # 140 "config.pre" mpath="/usr/local/lib/openser/modules"
loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "dbtext.so" loadmodule "domain.so" loadmodule "uac_redirect.so"
log_stderror=no log_facility=LOG_LOCAL5 listen=12.46.104.47 port=5060 children=4 disable_tcp=yes dns_try_ipv6=no server_signature=no sip_warning=0
alias="redirect.node-1.com" alias="proxy.redirect.node-1.com" alias="12.46.104.47"
fifo="/tmp/ser_fifo/proxy"
modparam("tm","fr_inv_timer",180) modparam("domain", "db_url", "dbtext:///var/openserdb")
route {
if (!mf_process_maxfwd_header("13")) { xlog("L_WARN","redirect.node-1.com-483: time_t=$Ts ^LINE=184 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Too many hops"); sl_send_reply("483", "Too many hops"); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=186 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(loose_route()) { xlog("L_WARN","redirect.node-1.com-LOOSE: time_t=$Ts ^LINE=188 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Doing it"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=190 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(!uri==myself) { xlog("L_WARN","redirect.node-1.com-NOTUS: time_t=$Ts ^LINE=192 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=forward packet"); record_route(); t_relay(); return; };
xlog("L_WARN","redirect.node-1.com-REDIRECTOR: time_t=$Ts ^LINE=194 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=Starting");
if(src_ip==12.46.104.62) { � xlog("L_INFO","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=201 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT"); � if(is_method("INVITE")) � { �� xlog("L_WARN","redirect.node-1.com-OUTBOUNDCALL: time_t=$Ts ^LINE=204 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=OUT");
�� t_on_failure("3");
�� record_route();
�� rewritehostport("198.212.169.6:5060");
�� if(!t_relay()) �� { � � sl_reply_error(); �� } �� return; � } }
xlog("L_WARN","redirect.node-1.com-404: time_t=$Ts ^LINE=224 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no route found"); sl_send_reply("404", "no route found"); return; } # 235 "config.pre" failure_route[3] { xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=237 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=here we are");
if(t_check_status("3[0-9][0-9]")) { � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=241 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=status is 3xx"); � get_redirects("*"); � serialize_branches(0); } next_branches(); � xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=246 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=next branch"); � t_on_failure("3"); � t_relay(); � return; xlog("L_WARN","redirect.node-1.com-FAILUREROUTE: time_t=$Ts ^LINE=250 ^FILE=config.pre ^call_id=$ci ^cseq=$cs ^contact=$ct ^from=$fu ^fromtag=$ft ^to=$tu ^totag=$tt ^method=$rm ^ruri=$ru ^messageid=$mi^remark=no branches left"); t_reply("404", "No branches left"); }
On 6/3/06, Greg Fausak lgfausak@gmail.com wrote:
I'm trying to play around with the current cvs head but can't get
it to
work. I wonder if somebody could give me a hint!
I built a redirect server: It basically does:
rewritehost("ab5350.node-1.com"); sl_send_reply("302", "Redirect");
I forward to the redirect server setting up a failure block:
if(is_method("INVITE")) { _QLOG(L_INFO, OUTBOUNDCALL, OUT);
t_on_failure("3");
record_route(); setflag(1); setflag(2);
rewritehostport(_QSTR (REDIRECTOBGATEWAYIP:REDIRECTOBGATEWAYPORT));
if(!t_relay()) { sl_reply_error(); } }
The response below comes back from my redirect server:
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 12.46.104.47;branch=z9hG4bKa86.09801851.0 Via: SIP/2.0/UDP 12.46.104.62:5061;branch=z9hG4bKa86.191c2c81.0 Via: SIP/2.0/UDP 12.46.104.59;branch=z9hG4bKa86.dafc0771.0 Via: SIP/2.0/UDP 71.252.176.37:5060;branch=z9hG4bK-d0702751 From: +19722200434 sip:+19722200434@var-2.com;tag=3a553a2b9373c699 To:
sip:2143357976@var-2.com;tag=5531b0101f56e37a4889ece4b0eb40fa.417f
Call-ID: f27483a5-50532031@71.252.176.37 CSeq: 101 INVITE Contact: sip:+12143357976@ab5350.node-1.com:5060 Content-Length: 0
My failure_route block picks up the routing:
failure_route[3] { _QLOG(L_WARN, FAILUREROUTE, here we are);
if(status =~ "3[0-9][0-9]") { _QLOG(L_WARN, FAILUREROUTE, status is 3xx); get_redirects("*"); serialize_branches(0); } if(next_branches()) { _QLOG(L_WARN, FAILUREROUTE, next branch); t_on_failure("3"); t_relay(); } _QLOG(L_WARN, FAILUREROUTE, no branches left); if(!t_reply("404", "Not Found")) { _QLOG(L_WARN, FAILUREROUTE, Error); } }
My syslog shows QLOG messages. I see the 'status is 3xx' message, which shows the next command to be get_redirects("*");
The next output I see in my syslog is 'no branches left', which indicates that the serialize_branches(0) and next_branches() aren't working as I
expected.
I've also tried getting rid of the serialize_branches and next_branches and just doing a t_relay() after the get_redirects(), that doesn't work
either.
Since I'm trying to simulate the redirect server, and the redirect client, I'm sure I got one of them wrong. Can somebody give me a hint?
Thanks!
-g
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Greg,
that's great if it works now.. regarding the SRV lookup - as the log says, no SRV and NAPTR lookups are done since the SIP URI specify a port. Get rid of the port number from the contact uri if you want to have naptr / srv lookup also.
regards, bogdan
Greg Fausak wrote:
Bogdan,
I recompiled openser and reinstalled, it's working for me now. I think I hacked something up and caused it to break!
One thing I still am curious about. I've got a domain name with an SRV record: ab5350.node-1.com, the SRV (_sip._udp.ab5350.node-1.com) points to a single A record proxy.ab5350.node-1.com. When I make that the Contact in the redirect I get this in the syslog:
Jun 5 09:39:51 www openser: DEBUG: mk_proxy: doing DNS lookup... Jun 5 09:39:51 www openser: DEBUG:sip_resolvehost2: has port -> do A record lookup! Jun 5 09:39:51 www openser: ERROR: mk_proxy: could not resolve hostname: "ab5350.node-1.com" Jun 5 09:39:51 www openser: ERROR: uri2proxy: bad host name in URI sip:+12143357976@ab5350.node-1.com:5060 Jun 5 09:39:51 www openser: ERROR:tm:t_forward_nonack: failure to add branches Jun 5 09:39:51 www openser: ERROR:tm:w_t_relay: t_forward_nonack failed Jun 5 09:39:51 www openser: DEBUG:tm:relay_reply: branch=0, save=0, relay=0
My code does a next_branches() followed by t_relay(). I thought that t_relay() did the necessary SRV lookups?
If I change my redirect to return proxy.ab5350.node-1.com in the Contact list, everything works as expected.
-g
On 6/5/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
yes - get_redirects("*") loads the contacts from 3xx reply into branches (as for parallel forking) ; serialize_branches(0) converts the branches into AVPs for serial forking ; next_branches() gets the first AVP for serial forking and push it as branch.
the message from next_branches() says all AVPs fro serial branches were consumed - or none was present from the beginning.
regards, Bogdan
That did the trick!
I was using rewritehost(), forgot that the port slipped in there. rewritehostport() removed the port from the redirect contact.
Thanks!
-g
On 6/5/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Greg,
that's great if it works now.. regarding the SRV lookup - as the log says, no SRV and NAPTR lookups are done since the SIP URI specify a port. Get rid of the port number from the contact uri if you want to have naptr / srv lookup also.
regards, bogdan
Greg Fausak wrote:
Bogdan,
I recompiled openser and reinstalled, it's working for me now. I think I hacked something up and caused it to break!
One thing I still am curious about. I've got a domain name with an SRV record: ab5350.node-1.com, the SRV (_sip._udp.ab5350.node-1.com) points to a single A record proxy.ab5350.node-1.com. When I make that the Contact in the redirect I get this in the syslog:
Jun 5 09:39:51 www openser: DEBUG: mk_proxy: doing DNS lookup... Jun 5 09:39:51 www openser: DEBUG:sip_resolvehost2: has port -> do A record lookup! Jun 5 09:39:51 www openser: ERROR: mk_proxy: could not resolve hostname: "ab5350.node-1.com" Jun 5 09:39:51 www openser: ERROR: uri2proxy: bad host name in URI sip:+12143357976@ab5350.node-1.com:5060 Jun 5 09:39:51 www openser: ERROR:tm:t_forward_nonack: failure to add branches Jun 5 09:39:51 www openser: ERROR:tm:w_t_relay: t_forward_nonack failed Jun 5 09:39:51 www openser: DEBUG:tm:relay_reply: branch=0, save=0, relay=0
My code does a next_branches() followed by t_relay(). I thought that t_relay() did the necessary SRV lookups?
If I change my redirect to return proxy.ab5350.node-1.com in the Contact list, everything works as expected.
-g
On 6/5/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
yes - get_redirects("*") loads the contacts from 3xx reply into branches (as for parallel forking) ; serialize_branches(0) converts the branches into AVPs for serial forking ; next_branches() gets the first AVP for serial forking and push it as branch.
the message from next_branches() says all AVPs fro serial branches were consumed - or none was present from the beginning.
regards, Bogdan
Hi Greg,
first of all you should not use "status" statement in failure route - it was intended to be used only in reply route. In failure route it access only bogus date - you should use the t_check_status() from TM module
if you run in full debug, you will get additional logs about the processing of both get_redirects() and serialize_branches() - like what contacts are set as branches and later what branches are loaded as AVPs for serial fork.
regards, Bogdan
Greg Fausak wrote:
I'm trying to play around with the current cvs head but can't get it to work. I wonder if somebody could give me a hint!
I built a redirect server: It basically does:
rewritehost("ab5350.node-1.com"); sl_send_reply("302", "Redirect");
I forward to the redirect server setting up a failure block:
if(is_method("INVITE")) { _QLOG(L_INFO, OUTBOUNDCALL, OUT); t_on_failure("3"); record_route(); setflag(1); setflag(2); rewritehostport(_QSTR(REDIRECTOBGATEWAYIP:REDIRECTOBGATEWAYPORT));
if(!t_relay()) { sl_reply_error(); } }The response below comes back from my redirect server:
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 12.46.104.47;branch=z9hG4bKa86.09801851.0 Via: SIP/2.0/UDP 12.46.104.62:5061;branch=z9hG4bKa86.191c2c81.0 Via: SIP/2.0/UDP 12.46.104.59;branch=z9hG4bKa86.dafc0771.0 Via: SIP/2.0/UDP 71.252.176.37:5060;branch=z9hG4bK-d0702751 From: +19722200434 sip:+19722200434@var-2.com;tag=3a553a2b9373c699 To: sip:2143357976@var-2.com;tag=5531b0101f56e37a4889ece4b0eb40fa.417f Call-ID: f27483a5-50532031@71.252.176.37 CSeq: 101 INVITE Contact: sip:+12143357976@ab5350.node-1.com:5060 Content-Length: 0
My failure_route block picks up the routing:
failure_route[3] { _QLOG(L_WARN, FAILUREROUTE, here we are);
if(status =~ "3[0-9][0-9]") { _QLOG(L_WARN, FAILUREROUTE, status is 3xx); get_redirects("*"); serialize_branches(0); } if(next_branches()) { _QLOG(L_WARN, FAILUREROUTE, next branch); t_on_failure("3"); t_relay(); } _QLOG(L_WARN, FAILUREROUTE, no branches left); if(!t_reply("404", "Not Found")) { _QLOG(L_WARN, FAILUREROUTE, Error); }}
My syslog shows QLOG messages. I see the 'status is 3xx' message, which shows the next command to be get_redirects("*");
The next output I see in my syslog is 'no branches left', which indicates that the serialize_branches(0) and next_branches() aren't working as I expected.
I've also tried getting rid of the serialize_branches and next_branches and just doing a t_relay() after the get_redirects(), that doesn't work either.
Since I'm trying to simulate the redirect server, and the redirect client, I'm sure I got one of them wrong. Can somebody give me a hint?
Thanks!
-g
-
Bogdan-Andrei Iancu -
Danish Samad -
Greg Fausak