sr-users March 2006

sr-users@lists.kamailio.org

223 participants
506 discussions

[Serusers] loose_route's bug?
by Ramin Nikaeen 09 Mar '06

09 Mar '06

Hi Everyone, I am really stuck here. I really need help! I receive the following ACK request in SER from a Linksys/PAP user agent that SER should forward to the destination User Agent: 2010000002. ACK sip:2010000002@10.1.10.65:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5fb5b16;rport From: 2224440133 <sip:2224440133@host.domain.com>;tag=692c5bafde7b5655o0 To: <sip:2224449999@host.domain.com>;tag=3b968d2d Call-ID: c813c237-8673e16d(a)172.16.15.51 CSeq: 101 ACK Max-Forwards: 70 Route: <sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr>, <sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr> Contact: 2224440133 <sip:2224440133@172.16.15.51:5060> User-Agent: Linksys/PAP2-3.1.5(LS) Content-Length: 0 But SER's loose_route incorrectly modifies this ACK as follows: ACK sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr SIP/2.0 Record-Route: <sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on> Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5fb5b16;rport=5060 From: 2224440133 <sip:2224440133@host.domain.com>;tag=692c5bafde7b5655o0 To: <sip:2224449999@host.domain.com>;tag=3b968d2d Call-ID: c813c237-8673e16d(a)172.16.15.51 CSeq: 101 ACK Max-Forwards: 16 Route: Contact: 2224440133 <sip:2224440133@172.16.15.51:5060> User-Agent: Linksys/PAP2-3.1.5(LS) Content-Length: 0 Which causes the ACK to keep looping through SER: ACK sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr SIP/2.0 Record-Route: <sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on> Record-Route: <sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on> Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5fb5b16;rport=5060 From: 2224440133 <sip:2224440133@host.domain.com>;tag=692c5bafde7b5655o0 To: <sip:2224449999@host.domain.com>;tag=3b968d2d Call-ID: c813c237-8673e16d(a)172.16.15.51 CSeq: 101 ACK Max-Forwards: 15 Route: Contact: 2224440133 <sip:2224440133@172.16.15.51:5060> User-Agent: Linksys/PAP2-3.1.5(LS) Content-Length: 0 ACK sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr SIP/2.0 Record-Route: <sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on> Record-Route: <sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on> Record-Route: <sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on> Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5fb5b16;rport=5060 From: 2224440133 <sip:2224440133@host.domain.com>;tag=692c5bafde7b5655o0 To: <sip:2224449999@host.domain.com>;tag=3b968d2d Call-ID: c813c237-8673e16d(a)172.16.15.51 CSeq: 101 ACK Max-Forwards: 14 Route: Contact: 2224440133 <sip:2224440133@172.16.15.51:5060> User-Agent: Linksys/PAP2-3.1.5(LS) Content-Length: 0 I am really stuck. Can anyone tell me what is happening?! Thanks ramin

2 1

RE: [Serusers] Radius Accounting encoding issues.
by Vitaly Nikolaev 09 Mar '06

09 Mar '06

That 100% radius... I've been thru it. -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: Thursday, March 09, 2006 2:23 PM To: sip Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] Radius Accounting encoding issues. Are you sure this encoding is done by SER ? I have never seen this, perhaps it is server-side problem ? Can you try to see what is in RADIUS packets sent by SER ? Jan. sip wrote: > I've set up radius accounting in SER 0.9.6 and I'm sure I'm missing something > obvious, but when it encodes the URIs for things like CalledStationID or > UserName, it's encoding the non-standard characters as hex. For instance, * > becomes =2A , so my URI ends up looking like sip:=2A850XXXXXXX@domain.com > where it should be sip:*850XXXXXXX@domain.com > > Is there something I'm missing in the table setup for the radacct table or a > modparam somewhere that I missed in the README? > > N. > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

1 0

[Serusers] Radius Accounting encoding issues.
by sip 09 Mar '06

09 Mar '06

I've set up radius accounting in SER 0.9.6 and I'm sure I'm missing something obvious, but when it encodes the URIs for things like CalledStationID or UserName, it's encoding the non-standard characters as hex. For instance, * becomes =2A , so my URI ends up looking like sip:=2A850XXXXXXX@domain.com where it should be sip:*850XXXXXXX@domain.com Is there something I'm missing in the table setup for the radacct table or a modparam somewhere that I missed in the README? N.

2 1

[Serusers] possible rr bug
by Ramin Nikaeen 09 Mar '06

09 Mar '06

Hi Everyone, I am really stuck here. I really need help! I receive the following ACK request in SER from a Linksys/PAP user agent that SER should forward to the destination User Agent: 1234560133. ------------------------------------------------------------------------ --------------------------------------------------- ACK sip:10.1.10.65;ftag=cff8d63370ff3ed5o0 SIP/2.0 Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5b186b5;rport From: 1234560133 <sip:2224440133@host.domain.name>;tag=cff8d63370ff3ed5o0 To: <sip:1234560131@host.domain.name>;tag=26001139010904 Call-ID: 9b54d80b-81b366dd(a)172.16.15.51 CSeq: 101 ACK Max-Forwards: 70 Route: <sip:1234569999@10.1.10.65:5060> Contact: 1234560133 <sip:1234560133@172.16.15.51:5060> User-Agent: Linksys/PAP2-3.1.5(LS) Content-Length: 0 ------------------------------------------------------------------------ --------------------------------------------------- But the loose_route function transforms it to the following and as a result it is routed back to SER and therefore falls into an infinite loop as shown by the couple of ACKs that get looped through SER: ------------------------------------------------------------------------ --------------------------------------------------- ACK sip:10.1.10.65;ftag=cff8d63370ff3ed5o0 SIP/2.0 Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on> Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5b186b5;rport=5060 From: 2224440133 <sip:2224440133@cl1.glphone.com>;tag=cff8d63370ff3ed5o0 To: <sip:2224440131@cl1.glphone.com>;tag=26001139010904 Call-ID: 9b54d80b-81b366dd(a)172.16.15.51 CSeq: 101 ACK Max-Forwards: 16 Contact: 2224440133 <sip:2224440133@172.16.15.51:5060> User-Agent: Linksys/PAP2-3.1.5(LS) Content-Length: 0 ------------------------------------------------------------------------ --------------------------------------------------- ACK sip:10.1.10.65;ftag=cff8d63370ff3ed5o0 SIP/2.0 Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on> Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on> Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5b186b5;rport=5060 From: 2224440133 <sip:2224440133@cl1.glphone.com>;tag=cff8d63370ff3ed5o0 To: <sip:2224440131@cl1.glphone.com>;tag=26001139010904 Call-ID: 9b54d80b-81b366dd(a)172.16.15.51 CSeq: 101 ACK Max-Forwards: 15 Contact: 2224440133 <sip:2224440133@172.16.15.51:5060> User-Agent: Linksys/PAP2-3.1.5(LS) Content-Length: 0 ------------------------------------------------------------------------ --------------------------------------------------- ACK sip:10.1.10.65;ftag=cff8d63370ff3ed5o0 SIP/2.0 Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on> Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on> Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on> Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 10.1.10.65;branch=0 Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5b186b5;rport=5060 From: 2224440133 <sip:2224440133@cl1.glphone.com>;tag=cff8d63370ff3ed5o0 To: <sip:2224440131@cl1.glphone.com>;tag=26001139010904 Call-ID: 9b54d80b-81b366dd(a)172.16.15.51 CSeq: 101 ACK Max-Forwards: 14 Contact: 2224440133 <sip:2224440133@172.16.15.51:5060> User-Agent: Linksys/PAP2-3.1.5(LS) Content-Length: 0 I put some debug messages in rr and this is what I get: DEBUG: -ramin- modules/rr/loose_route: jumping to after_strict after_strict: No next URI found It seems as if the after_strict is invoked and it can not find the next URI! Can you please tell me why SER can not route this properly! Thank you so much for your kind help ramin

1 0

RE: [Serusers] g729
by Vitaly Nikolaev 09 Mar '06

09 Mar '06

Hehe.. still u have to go to digium and/or search for asterisk documentation or/and go to asterisk mailing list to get answer to ur question, Ser is signaling only PROXY/REGISTRAR server, all conference/codec issues will be done on asterisk, ser can only forward the call to asterisk. I do not think here is educational license... but u can buy real one for 10$ only, or there is some information about g729 that provided by Intel as demo/test of their processors that can be hacked to work with asterisk, looks for that keywords on Google or ask on asterisk forums, SER has nothing with it. -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Kapil Dhawan Sent: Thursday, March 09, 2006 12:26 PM To: rjgonzale(a)gmail.com Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] g729 Hi Rodrigo Thx for the reply. Well i am aware of this fact so i mentioned that i need it for Conferencing. >From: Rodrigo Gonzalez <rjgonzale(a)gmail.com> >To: Kapil Dhawan <sersavvy(a)hotmail.com> >CC: serusers(a)lists.iptel.org >Subject: Re: [Serusers] g729 >Date: Thu, 09 Mar 2006 14:14:40 -0300 > >http://www.digium.com/ > >SER does not know about codecs, this is for Asterisk > >Kapil Dhawan wrote: > >>Hi Guys >> >>I want to try g729 with SER + Asterisk with conferencing. Where can i get >>an educational license from. >> >>_________________________________________________________________ >>All that you wanted to know about Ms Beautiful Lips >>http://server1.msn.co.in/Profile/katrina.asp >> >>_______________________________________________ >>Serusers mailing list >>serusers(a)lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> _________________________________________________________________ STILL SINGLE? Get married through MSN Matrimony. Join now for FREE! http://www.shaadi.com/msn/matrimonials.php _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

1 0

RE: [Users] forcing rtpproxy on a call
by Vitaly Nikolaev 09 Mar '06

09 Mar '06

1. I never used forward, see my example, I do not know if it actually relay call or not 2. if you do not have NAT between client and server you do not need force_rport, and try to avoid any nat_uac_test, etc if you are actually working on private ips without nat 3. you MUST enable proxy also for reply route[x] { ..... force_rtp_proxy(); t_on_reply("1"); rewritehostport("x.x.x.x:5060"); if (!t_relay()) { sl_reply_error(); }; } onreply_route[1] { if (!(status=~"183" || status=~"200")) break; force_rtp_proxy(""); } ________________________________ From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf Of Script Head Sent: Wednesday, March 08, 2006 6:29 PM To: users(a)openser.org Subject: [Users] forcing rtpproxy on a call Hello everyone, I am trying to debug why my rtpproxy isn't working. I have the following setup, on my LAN. softphone (192.168.1.100) -> openser/rtpproxy ( 192.168.1.10 <http://192.168.1.10> ) -> asterisk (192.168.1.12) The rtpproxy is running and I see commands flying thru it. the following route works if(method=="INVITE") { if(uri=~"^sip:[0-9]{6}1[0-9]*{10}@") { forward(192.168.1.12,5060); }; } when I replace it with this route if(method=="INVITE") { if(uri=~"^sip:[0-9]{6}1[0-9]*{10}@") { forward(192.168.1.12,5060); }; force_rport(); force_rtp_proxy(); } I get dead air while asterisk logs show that my test message is playing. How should I proceed to debug this? ScriptHead

2 1

[Serusers] g729
by Kapil Dhawan 09 Mar '06

09 Mar '06

Hi Guys I want to try g729 with SER + Asterisk with conferencing. Where can i get an educational license from. _________________________________________________________________ All that you wanted to know about Ms Beautiful Lips http://server1.msn.co.in/Profile/katrina.asp

2 2

[Serusers] calls returning from hold not utilizing mediaproxy
by Brett N 09 Mar '06

09 Mar '06

Ok, I've roughly used the examples that are included in the modules/mediaproxy/ser.cfg file to use mediaproxy. The initial call is set up very nicely. However reinvites don't seem to be processsed right. When I place the call on hold, I can see that mediaproxy sees the call on hold (with the sessions tool). However, when I return to the call from hold, the reinvite just sets the devices up to each other direct without the mediaproxy. Mediaproxy will for about 1 second show the call come back to "ACTIVE" and then to "IDLE". I'm sure the rtp isn't being proxied because 1. I can kill the proxy, and still pass audio 2. the sessions tool doesn't show packets being transmitted 3. the SDP isn't pointing to the mediaproxy. I can't figure out what I'm doing wrong. However, mediaproxy sees to be very sensitive on how it's called. Per the example, use_media_proxy() will be called TWICE for a new call. This works for the initial call.. However, I removed the initial call to use_media_proxy and only left the one in the on_reply route. Doing this totally broke it and routed the calls without media proxy. **** Oh, something that is worth mentioning. In the example file, there is an end_media_session() at the begining of the on_reply block. If this is in there, no calls will goto the mediaproxy ever. I get an error message: 3(3114) error: use_media_proxy(): empty response from mediaproxy So I removed it to get where I am now. Here are the relevant parts of my config: # $Id: openser.cfg,v 1.6 2006/02/15 18:23:46 bogdan_iancu Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ debug=2 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) /* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/openser_fifo" fifo_db_url="mysql://ser:xxxxx@172.16.10.103:3306/ser" # # uncomment the following lines for TLS support #disable_tls = 0 #listen = tls:your_IP:5061 listen=192.168.1.10:5060 #tls_verify = 1 #tls_require_certificate = 0 #tls_method = TLSv1 #tls_certificate = "/usr/local/etc/openser/tls/user/user-cert.pem" #tls_private_key = "/usr/local/etc/openser/tls/user/user-privkey.pem" #tls_ca_list = "/usr/local/etc/openser/tls/user/user-calist.pem" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database loadmodule "/usr/local/lib/openser/modules/mysql.so" loadmodule "/usr/local/lib/openser/modules/sl.so" loadmodule "/usr/local/lib/openser/modules/tm.so" loadmodule "/usr/local/lib/openser/modules/rr.so" loadmodule "/usr/local/lib/openser/modules/maxfwd.so" loadmodule "/usr/local/lib/openser/modules/usrloc.so" loadmodule "/usr/local/lib/openser/modules/textops.so" loadmodule "/usr/local/lib/openser/modules/uri.so" loadmodule "/usr/local/lib/openser/modules/uri_db.so" loadmodule "/usr/local/lib/openser/modules/registrar.so" loadmodule "/usr/local/lib/openser/modules/mediaproxy.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib/openser/modules/auth.so" loadmodule "/usr/local/lib/openser/modules/auth_db.so" loadmodule "/usr/local/lib/openser/modules/domain.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("auth_db","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser") modparam("uri_db","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser") modparam("domain","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser") modparam("dip","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser") modparam("usrloc","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser") modparam("domain","domain_table","domain") modparam("domain","domain_col","domain") modparam("domain","db_mode",0) modparam("auth_db","use_domain",1) # modparam("usrloc", "db_mode", 2) # Uncomment this if you want to use SQL database # for persistent storage and comment the previous line #modparam("usrloc", "db_mode", 2) # -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "load_credentials", "rpid,vm_timer") modparam("tm", "fr_inv_timer_avp", "vm_timer") # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # modparam("auth_db", "password_column", "password") # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) modparam("mediaproxy", "natping_interval", 60) modparam("registrar" , "nat_flag", 2) # ------------------------- request routing logic ------------------- # main routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); return; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); return; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol ### Fix natted requests if (client_nat_test("3")) { log(1,"***** PERFORMING NAT FIXUP\n"); setflag(2); force_rport(); fix_contact(); }; record_route(); if (client_nat_test("3") && !search("^Record-Route:")) { # Mark call as being natted force_rport(); fix_contact(); }; #### Process registrations if (method=="REGISTER") { log(1,"***** REGISTERING\n"); if (is_from_local()) { log(1,"**** IS FROM LOCAL\n"); # Mark as NAT'ed if (client_nat_test("3")) { log(1,"***** PERFORMING NAT FIXUP\n"); setflag(2); force_rport(); fix_contact(); }; if (!www_authorize("", "subscriber")) { log(1,"**** ASKING FOR CREDS\n"); www_challenge("", "0"); return; } else if (!check_to()) { sl_send_reply("403", "Username!=To not allowed"); return; }; log(1,"*** ATTEMPTING TO SAVE CONTACT\n"); if (!save("location")) { sl_reply_error(); }; } else { sl_send_reply("403", "This domain is not served here"); }; return; }; ### All invites must be authenticated.. do this first if (method=="INVITE") { if(!www_authorize("","subscriber")) { log(1,"**** ASKING FOR CREDS\n"); www_challenge("","0"); return; } else if (!check_from()) { sl_send_reply("403", "Username must equal the from address"); return; }; log(1,"**** APPENDING RPID\n"); append_rpid_hf("<sip:", "@192.168.1.10>;privacy=off"); } # make sure a leg is local somewhere if (method=="INVITE") { if (!(is_from_local() || is_uri_host_local())) { sl_send_reply("403", "Relaying is forbidden"); return; } t_on_failure("1"); } else if (method == "BYE" || method == "CANCEL") { log(1,"Ending session sec-1\n"); end_media_session(); }; # resolve aliases if (!lookup("aliases")) { log(1,"*** Call is not in aliases table\n"); } # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { log(2,"**** PERFORMING LOOSE ROUTE\n"); if (method=="INVITE" || method=="ACK"){ use_media_proxy(); }; append_hf("P-hint: rr-enforced\r\n"); log(1," *** USE MEDIA PROXY\n"); t_relay(); return; }; if (method == "INVITE") { t_on_reply("1"); }; if (is_uri_host_local()) { if (!lookup("location")) { log(1," **** location lookup failed\n"); # lookup failed.. probably a pstn call use_media_proxy(); rewritehostport("voip_gw"); if (!t_relay()) { sl_reply_error(); return; } return; } } if (method=="INVITE" || method =="ACK") { log(1," *** USE MEDIA PROXY\n"); use_media_proxy(); } if (method=="OPTIONS") { sl_send_reply("404", "Pong - Go away"); return; } if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); log (1," Ending session sec-2\n"); }; sl_reply_error(); return; } } failure_route[1] { end_media_session(); log(1,"Ending session sec-3\n"); } onreply_route[1] { end_media_session(); log(1,"******* In onreply route block\n"); if (status=~"(183)|(2[09][09])") { if (client_nat_test("1")) { fix_contact(); }; use_media_proxy(); } }

1 0

[Serusers] calls returning from hold not utilizing mediaproxy
by Brett N 09 Mar '06

09 Mar '06

1 0

RE: [Serusers] SER + Asterisk; BYE gets 404
by Bart J. Smit 09 Mar '06

09 Mar '06

I suspect that asterisk is not seeing the ACK and BYE as part of the session, since the original INVITE was sent to XXXX(a)pbx.nexusmgmt.com and all other SIP messages are forwarded to 65.126.236.148. I have tried to change the forward from the IP to the FQDN, but the invite no longer reaches the internal UA if I do. Is there a setting to instruct ser to do a lookup on a forward, or is forward limited to IP address? Bart... -----Original Message----- From: Dr. Rodney G. McDuff [mailto:mcduff@its.uq.edu.au] Sent: 09 March 2006 00:43 To: Bart J. Smit Subject: Re: [Serusers] SER + Asterisk; BYE gets 404 Hi Bart Bart J. Smit wrote: > Hi Rodney, > > The entire conversation is in UDP. I've attached the SIP packets from > the ethereal trace. > > Firstly it seems that the ACKs from SJPhone in response to the 200 OK from your asterisk box arn't getting thru to the asterisk box. Thats why the asterisk box continues to send the 200 OKs. Eventually the SJPhone send a BYE (is that you or a timeout?). What is strange is the SER box authored the 404 Not found response. If the SER and asterisk is on the same box can you run ethereal this box and can change the capture filter to get the both sides of the conversation. Maybe something like 'port 5060 or port 5065'. Also what is 80.176.149.91? > Bart... > > -----Original Message----- > From: Dr. Rodney G. McDuff [mailto:mcduff@its.uq.edu.au] > Sent: 07 March 2006 23:38 > To: Bart J. Smit; serusers(a)lists.iptel.org > Subject: Re: [Serusers] SER + Asterisk; BYE gets 404 > > Hi Bart > Have you got the SER box doing any (TCP/UDP) protocol conversion. > Ie is your phone using TCP (as * only does UDP). > > Bart J. Smit wrote: > >> I am running ser 0.9.6 on CentOS 4.2 with asterisk on the same box >> listening on 5065. >> >> When I register a phone with ser, I can call XXXX(a)pbx.nexusmgmt.com >> > and > >> these calls are forwarded to the asterisk on a forward(<external >> IP>,5065). I've attached my full routing block below. >> >> After hanging up from either phone, the BYE packet never gets >> > delivered. > >> It shows up in ethereal as being addressed to the external IP address >> > of > >> the box and it gets a 404 in reply. >> >> When I register a phone directly with the Asterisk, I can hang up from >> either end as normal, so the issue must be with ser. >> >> Any hints on how I can route the BYE packets correctly? >> >> Thanks, >> >> Bart... >> >> >> route { >> >> # >> ----------------------------------------------------------------- >> # Sanity Check Section >> # >> ----------------------------------------------------------------- >> if (!mf_process_maxfwd_header("10")) { >> sl_send_reply("483", "Too Many Hops"); >> break; >> }; >> >> if (msg:len > max_len) { >> sl_send_reply("513", "Message Overflow"); >> break; >> }; >> # >> ----------------------------------------------------------------- >> # Record Route Section >> # >> ----------------------------------------------------------------- >> if (method!="REGISTER") { >> record_route(); >> }; >> >> # >> ----------------------------------------------------------------- >> # Loose Route Section >> # >> ----------------------------------------------------------------- >> if (loose_route()) { >> t_relay(); >> break; >> }; >> >> # >> ----------------------------------------------------------------- >> # Call Type Processing Section >> # >> ----------------------------------------------------------------- >> if (uri=~"sip:[0-9]{4}@pbx\.nexusmgmt\.com") { >> forward(65.126.236.148,5065); >> break; >> }; >> if (uri!=myself) { >> route(1); >> break; >> }; >> >> if (method=="CANCEL") { >> route(1); >> break; >> } else if (method=="INVITE") { >> route(3); >> break; >> } else if (method=="REGISTER") { >> route(2); >> break; >> }; >> >> lookup("aliases"); >> if (uri!=myself) { >> route(1); >> break; >> }; >> >> if (!lookup("location")) { >> sl_send_reply("404", "User Not Found"); >> break; >> }; >> >> route(1); >> } >> >> route[1] { >> >> # >> ----------------------------------------------------------------- >> # Default Message Handler >> # >> ----------------------------------------------------------------- >> >> t_on_reply("1"); >> >> if (!t_relay()) { >> sl_reply_error(); >> }; >> } >> >> route[2] { >> >> # >> ----------------------------------------------------------------- >> # REGISTER Message Handler >> # >> ---------------------------------------------------------------- >> >> sl_send_reply("100", "Trying"); >> >> if (!www_authorize("","subscriber")) { >> www_challenge("","0"); >> break; >> }; >> >> if (!check_to()) { >> sl_send_reply("401", "Unauthorized"); >> break; >> }; >> >> consume_credentials(); >> >> if (!save("location")) { >> sl_reply_error(); >> }; >> } >> >> route[3] { >> >> # >> ----------------------------------------------------------------- >> # INVITE Message Handler >> # >> ----------------------------------------------------------------- >> >> if (!proxy_authorize("","subscriber")) { >> proxy_challenge("","0"); >> log(1,"authenticate please\n"); >> break; >> } else if (!check_from()) { >> sl_send_reply("403", "Use From=ID"); >> break; >> }; >> >> lookup("aliases"); >> if (uri!=myself) { >> route(1); >> break; >> }; >> >> if (!lookup("location")) { >> sl_send_reply("404", "User Not Found"); >> break; >> }; >> >> route(1); >> } >> >> _______________________________________________ >> Serusers mailing list >> serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> >> > > > -- Dr. Rodney G. McDuff |Ex ignorantia ad sapientiam Manager, Strategic Technologies Group| Ex luce ad tenebras Information Technology Services | The University of Queensland | EMAIL: mcduff(a)its.uq.edu.au | TELEPHONE: +61 7 3365 8220 |

1 0

← Newer
1
...
35
36
37
38
39
40
41
...
51
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users March 2006