hi guys!
can somebody explain me how SEMS works with SER/OpenSER.
As I conceive proxy sends requests to SEMS via unix socket. Then SEMS needs constructs reply or new request and ask proxy to send it. But where reply come to proxy? into onreply_route[0] block? is it possible to use t_on_reply() function when initial request writing to SEMS to ask proxy to use specific onreply_route[] block?
Thanks for advise!
Hello,
SER directly sends out the reply message to next_hop without going through the route script. If you need to process outgoing messages from SEMS, either modify them directly in SEMS, or use one SER instance as SIP stack for SEMS on e.g. port 5070, and have one SER proxy record-route. This way you get replies and followup requests on your record-routing proxy.
Stefan
Victor Gamov wrote:
hi guys!
can somebody explain me how SEMS works with SER/OpenSER.
As I conceive proxy sends requests to SEMS via unix socket. Then SEMS needs constructs reply or new request and ask proxy to send it. But where reply come to proxy? into onreply_route[0] block? is it possible to use t_on_reply() function when initial request writing to SEMS to ask proxy to use specific onreply_route[] block?
Thanks for advise!
Stefan Sayer wrote:
Hello,
SER directly sends out the reply message to next_hop without going through the route script. If you need to process outgoing messages from SEMS, either modify them directly in SEMS, or use one SER instance as SIP stack for SEMS on e.g. port 5070, and have one SER proxy record-route. This way you get replies and followup requests on your record-routing proxy.
ok, I see
thanks
Hello,
my Openser is looping whenever an external call comes in. Internal calls from the same domain (route 1) are ok. Also from internal to external domains. I have set aliases in openser.cfg, I have set the hosts file but it still loops.
Below you'll find the config and at the end an ngrep output on lo which shows that t_relay() is trying to deliver the invite message from 192.168.178.10:5060 -> 192.168.178.10:5060 in an endless loop until the emssage becomes too big due to increasing # of via headers (see last message at the end of the mail).
Just to mention: Openser runs in a virtual environment (VirtualBox Host br0=>tap1=> Client eth0)
Can anybody help? What am I doing wrong?
Here is my conf:
/etc/hostname ============= sip
/etc/hosts ============= 127.0.0.1 localhost 192.168.178.10 sip2.mydomain.de sip.mydomain.de sip
====================================================================== # # $Id: openser.cfg #
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) children=4
log_facility=LOG_LOCAL7 #Add the xlog module: loadmodule "/usr/lib/openser/modules/xlog.so"
# Uncomment these lines to enter debugging mode #fork=no #log_stderror=yes check_via=yes
port=5060 listen=192.168.178.10:5060 #listen=0.0.0.0:5060 alias=udp:192.168.178.10 alias=udp:sip2.mydomain.de:5060 alias=udp:0.0.0.0:5060 alias=udp:127.0.0.1:5060 alias=udp:localhost:5060
# ------------------ module loading ----------------------------------
#set module path mpath="/usr/lib/openser/modules/"
# Uncomment this if you want to use SQL database loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "mi_fifo.so" loadmodule "nathelper.so"
# Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "auth.so" loadmodule "auth_db.so"
#domains loadmodule "domain.so"
#Accounting loadmodule "acc.so"
#siptrace loadmodule "siptrace.so"
#AVP loadmodule "avpops.so"
#Mediaproxy loadmodule "mediaproxy.so"
# ----------------- setting module-specific parameters ---------------
# -- mi_fifo params -- modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
# -- usrloc params -- modparam("usrloc", "nat_bflag", 2) # Nat-Flag=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", 1)
# 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)
# -- Domain Params -- modparam("domain", "db_url", "mysql://openserro:openserro@localhost/openser") modparam("domain", "db_mode", 1) # Use caching
# --Accounting Params -- modparam("acc", "log_flag", 2) # Use Flag #2 modparam("acc", "log_level", 2) # Set log_level to 2 modparam("acc", "log_extra", "ua=$hdr(User-Agent);uuid=$avp(i:123)") modparam("acc", "early_media", 1) modparam("acc", "failed_transaction_flag", 2) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "log_extra", "ua=$hdr(User-Agent);uuid=$avp(i:123)") modparam("acc", "db_flag", 2) modparam("acc", "db_missed_flag", 2) modparam("acc", "db_table_acc", "acc") # Default value is "acc" modparam("acc", "db_table_missed_calls", "missed_calls") # Default value is "missed_calls" modparam("acc", "db_url", "mysql://openser:openserrw@localhost/openser")
# -- siptrace Parameters -- modparam("siptrace", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("siptrace", "trace_on", 1) modparam("siptrace", "traced_user_avp", "$avp(i:123)") # bringt nichts
# -- Mediaproxy params -- modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy.sock") modparam("mediaproxy", "natping_interval", 60) ##modparam("registrar", "nat_flag", 2) #Nat-Flag=2
# -- Nathelper module modparam("nathelper", "natping_interval", 10) modparam("nathelper", "rtpproxy_disable", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{ setflag(2); # set for accounting (the same value as in log_flag!) acc_log_request("Some comment"); sip_trace(); # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("1")) { sl_send_reply("483","Too Many Hops!"); exit; };
if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; };
# apply loose (normal) routing rules if(!is_method("REGISTER")) { if(loose_route()) { route(2); } } if (is_uri_host_local()){ xlog("L_INFO", "Step 5a: is_uri_host_local() => To: is local"); }
# NAT test if (client_nat_test("3") && !is_present_hf("Route")){ setflag(8); # flag for NAT force_rport(); fix_contact(); # Replace IP:Port append_hf("P-hint: NAT\r\n"); }
# 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 if (!method=="REGISTER") { record_route(); }
# subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); };
if (!is_from_local()) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); if (is_method("INVITE")){ # Is To: Local adresse if (is_uri_host_local()){ setflag(8); # flag for NAT force_rport(); fix_contact(); # Replace IP:Port append_hf("P-hint: NAT\r\n"); route(1); }else{ # to: is no local adress route(2); } } else { route(2); } };
# if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (is_from_local()) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication if (!www_authorize("192.168.178.10", "subscriber")) { www_challenge("192.168.178.10", "0"); exit; };
acc_log_request("Some comment"); save("location"); exit; };
lookup("aliases"); if (!is_from_local()) { append_hf("P-hint: outbound alias\r\n"); route(1); };
# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { #sl_send_reply("404", "Not Found"); route(2); #exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); }
route[1] { #local route without NAT # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP sip_trace(); if (!t_relay()) { sl_reply_error(); }; exit; }
route[2]{ #route external via proxy if (isflagset(8)){ if (is_method("INVITE")){ t_on_reply("1"); t_on_failure("1"); use_media_proxy(); fix_nated_contact(); } else if (is_method("BYE|CANCEL")) { end_media_session(); } #invite } #flagset 8
if (is_uri_host_local()){ lookup("aliases"); }
sip_trace(); if (!t_relay()) { sl_reply_error(); } exit; } # Add for mediaproxy onreply_route[1] { if (status =~ "(183)|(2[0-9][0-9])") { if (client_nat_test("1")) { fix_contact(); } use_media_proxy(); } }
failure_route[1] { end_media_session(); }
Output of ngrep for lo ====================================== U(17) 192.168.178.10:5060 -> 192.168.178.10:5060 INVITE sip:oliver@sip2.mydomain.de;method=INVITE SIP/2.0..Record-Route: sip:192.168.178.10;lr=on;ftag=4147186348102458..Record-Route: <sip:217.74.179.2 9;ftag=4147186348102458;lr=on>..Via: SIP/2.0/UDP 192.168.178.10;branch=z9hG4bK0df2.6a254967.0..Via: SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG4bK0d f2.53376a54.0..Via: SIP/2.0/UDP 217.24.11.186:5530;branch=z9hG4bK4430225740333751..From: sip:myname@sipprovider.net;tag=4147186348102458..To: <sip: oliver@sip2.mydomain.de>..Call-ID: 4 883202677351876@sipprovider.net..CSeq: 2 INVITE..Contact: sip:myname@217.74.179.29:5060..Proxy-Authorization: Digest username="sipprovider/myname", realm="sipprovider.net", nonce="46762df8ff60c6dc11695a491c1538cd9bec5471", uri="sip:oliver@sip2.mydomain.de;method= INVITE", response="6481c0c01cc11eae67aca5dd3d72a87e", algorithm=MD5..Max-Forwards: 68..Expires: 1800..Content-Type: application/BRAVIS_BETA..Content-Leng th: 384..P-hint: OUTBOUND ON INTERNET..P-hint: outbound..P-hint: NAT....ABAAAAAALMAAAAAABGNKMIEHAFAAAAAAABPEKIMAJKBFABAAAAAAADABAAAFFAMDHNAEAAAAAAGIGPH
DHEIAGGANADACJDAGIIAHBDABFBKIMAJKBFABAAAAAAACABAAADFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDBILCKIMAJKBFABAAAAAAABABAAABFAMDHNAEAAAAAAGIGPHDHEIAGGANADAC
JDAGIIAHBDLACIEHAFJKBFABAAAAAAAEABAAAHEAJMHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLKALBINJJKBFABAAAAAADDABAAPPPPPPEKAFAAAAAAHDHCGGGMHIAAAAAAAAABPEKIMAJKBF # U(17) 192.168.178.10:5060 -> 192.168.178.10:5060 SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP 192.168.178.10;branch=z9hG4bK0df2.6a254967.0;rport=5060..Via: SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG 4bK0df2.53376a54.0..Via: SIP/2.0/UDP 217.24.11.186:5530;branch=z9hG4bK4430225740333751..From: sip:myname@sipprovider.net;tag=4147186348102458..To: sip:oliver@sip2.mydomain.de..Call-ID: 4 883202677351876@sipprovider.net..CSeq: 2 INVITE..Server: OpenSER (1.2.0-notls (i386/linux))..Content-Length: 0.... # U(17) 192.168.178.10:5060 -> 192.168.178.10:5060 INVITE sip:oliver@sip2.mydomain.de;method=INVITE SIP/2.0..Record-Route: sip:192.168.178.10;lr=on;ftag=4147186348102458..Record-Route: <sip:192.168.178. 10;lr=on;ftag=4147186348102458>..Record-Route: sip:217.74.179.29;ftag=4147186348102458;lr=on..Via: SIP/2.0/UDP 192.168.178.10;branch=z9hG4bK0df2.7a2549 67.0..Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bK0df2.6a254967.0..Via: SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG4bK0df2.53376a54.0.. Via: SIP/2.0/UDP 217.24.11.186:5530;branch=z9hG4bK4430225740333751..From: sip:myname@sipprovider.net;tag=4147186348102458..To: <sip:oliver@sip2.tel efaks.de>..Call-ID: 4 883202677351876@sipprovider.net..CSeq: 2 INVITE..Contact: sip:myname@192.168.178.10:5060..Proxy-Authorization: Digest usernam e="sipprovider/myname", realm="sipprovider.net", nonce="46762df8ff60c6dc11695a491c1538cd9bec5471", uri="sip:oliver@sip2.mydomain.de;method=INVITE", respo nse="6481c0c01cc11eae67aca5dd3d72a87e", algorithm=MD5..Max-Forwards: 67..Expires: 1800..Content-Type: application/BRAVIS_BETA..Content-Length: 384..P-h int: OUTBOUND ON INTERNET..P-hint: outbound..P-hint: NAT..P-hint: outbound..P-hint: NAT....ABAAAAAALMAAAAAABGNKMIEHAFAAAAAAABPEKIMAJKBFABAAAAAAADABAAAFFA
MDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDABFBKIMAJKBFABAAAAAAACABAAADFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDBILCKIMAJKBFABAAAAAAABABAAABFAMDHNAEAAAAAAG
IGPHDHEIAGGANADACJDAGIIAHBDLACIEHAFJKBFABAAAAAAAEABAAAHEAJMHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLKALBINJJKBFABAAAAAADDABAAPPPPPPEKAFAAAAAAHDHCGGGMHIAAAA AAAAABPEKIMAJKBF # U(17) 192.168.178.10:5060 -> 192.168.178.10:5060 SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP 192.168.178.10;branch=z9hG4bK0df2.7a254967.0;rport=5060..Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9h G4bK0df2.6a254967.0..Via: SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG4bK0df2.53376a54.0..Via: SIP/2.0/UDP 217.24.11.186:5530;branch=z9hG4bK443022574 0333751..From: sip:myname@sipprovider.net;tag=4147186348102458..To: sip:oliver@sip2.mydomain.de..Call-ID: 4 883202677351876@sipprovider.net..CSeq: 2 INVITE..Server: OpenSER (1.2.0-notls (i386/linux))..Content-Length: 0.... # U(17) 192.168.178.10:5060 -> 192.168.178.10:5060 INVITE sip:oliver@sip2.mydomain.de;method=INVITE SIP/2.0..Record-Route: sip:192.168.178.10;lr=on;ftag=4147186348102458..Record-Route: <sip:192.168.178. 10;lr=on;ftag=4147186348102458>..Record-Route: sip:192.168.178.10;lr=on;ftag=4147186348102458..Record-Route: <sip:217.74.179.29;ftag=4147186348102458;l r=on>..Via: SIP/2.0/UDP 192.168.178.10;branch=z9hG4bK0df2.8a254967.0..Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bK0df2.7a254967.0..Via: SIP/ 2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bK0df2.6a254967.0..Via: SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG4bK0df2.53376a54.0..Via: SIP/2.0/UD P 217.24.11.186:5530;branch=z9hG4bK4430225740333751..From: sip:myname@sipprovider.net;tag=4147186348102458..To: sip:oliver@sip2.mydomain.de..Call -ID: 4 883202677351876@sipprovider.net..CSeq: 2 INVITE..Contact: sip:myname@192.168.178.10:5060..Proxy-Authorization: Digest username="sipprovider/myname", realm="sipprovider.net", nonce="46762df8ff60c6dc11695a491c1538cd9bec5471", uri="sip:oliver@sip2.mydomain.de;method=INVITE", response="6481c0c01c c11eae67aca5dd3d72a87e", algorithm=MD5..Max-Forwards: 66..Expires: 1800..Content-Type: application/BRAVIS_BETA..Content-Length: 384..P-hint: OUTBOUND O N INTERNET..P-hint: outbound..P-hint: NAT..P-hint: outbound..P-hint: NAT..P-hint: NAT..P-hint: outbound..P-hint: NAT....ABAAAAAALMAAAAAABGNKMIEHAFAAAAAAA
BPEKIMAJKBFABAAAAAAADABAAAFFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDABFBKIMAJKBFABAAAAAAACABAAADFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDBILCKIMAJKBFAB
AAAAAAABABAAABFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLACIEHAFJKBFABAAAAAAAEABAAAHEAJMHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLKALBINJJKBFABAAAAAADDABAAP PPPPPEKAFAAAAAAHDHCGGGMHIAAAAAAAAABPEKIMAJKBF #
============================================================================= Here is the last message before it becomes too big: INVITE sip:oliver@sip2.mydomain.de;method=INVITE SIP/2.0 Record-Route: sip:192.168.178.10;lr=on;ftag=4330431582305345 Record-Route: sip:192.168.178.10;lr=on;ftag=4330431582305345 Record-Route: sip:192.168.178.10;lr=on;ftag=4330431582305345 Record-Route: sip:192.168.178.10;lr=on;ftag=4330431582305345 Record-Route: sip:192.168.178.10;lr=on;ftag=4330431582305345 Record-Route: sip:217.74.179.29;ftag=4330431582305345;lr=on Via: SIP/2.0/UDP 192.168.178.10;branch=z9hG4bKd018.3a76c8c6.0 Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bKd018.2a76c8c6.0 Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bKd018.1a76c8c6.0 Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bKd018.0a76c8c6.0 Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bKd018.f976c8c6.0 Via: SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG4bKd018.e28f70f2.0 Via: SIP/2.0/UDP 217.24.11.186:5530;branch=z9hG4bK4500476364380471 From: sip:myname@sipprovider.net;tag=4330431582305345 To: sip:oliver@sip2.mydomain.de Call-ID: 4 402347358184803@sipprovider.net CSeq: 2 INVITE Contact: sip:myname@192.168.178.10:5060 Proxy-Authorization: Digest username="sipprovider/myname", realm="sipprovider.net", nonce="46762f3a40204b26064717316a0639b27a0980e5", uri="sip:oliver@sip2.mydomain.de;method=INVITE", response="87d50432f5ca4b2cbe245863957c0fae", algorithm=MD5 Max-Forwards: 64 Expires: 1800 Content-Type: application/BRAVIS_BETA Content-Length: 384 P-hint: OUTBOUND ON INTERNET P-hint: outbound P-hint: NAT P-hint: outbound P-hint: NAT P-hint: NAT P-hint: outbound P-hint: NAT P-hint: NAT P-hint: outbound P-hint: NAT P-hint: NAT P-hint: outbound P-hint: NAT
ABAAAAAALMAAAAAABGNKMIEHAFAAAAAAABPEKIMAJKBFABAAAAAAADABAAAFFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDABFBKIMAJKBFABAAAAAAACABAAADFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDBILCKIMAJKBFABAAAAAAABABAAABFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLACIEHAFJKBFABAAAAAAAEABAAAHEAJMHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLKALBINJJKBFABAAAAAADDABAAPPPPPPEKAFAAAAAAHDHCGGGMHIAAAAAAAAABPEKIMAJKBF
Does anyone have an idea how OpenSER behaves in terms of call forking?
That means: - A sip client A registers at OpenSER from IP adress A, - then another SIP client B registers at OpenSER from IP adress B with the same credentials while A ist still registered.
Question 1: - does OpenSER allow both clients to register with the same credentials?
Question 2: - can this be switched on/off somewhere?
Question 3: - in case it works, can an incoming call being routed to A and B simulaneously?
Thanks for your help Peter
Hi there Peter,
answers bellow:
Question 1:
- does OpenSER allow both clients to register with the same credentials?
Yes, this is the default behavior of openser.
Question 2:
- can this be switched on/off somewhere?
You can limit it here: http://www.openser.org/docs/modules/1.2.x/registrar.html#AEN199 or by using some sort of avp tricks.
Question 3:
- in case it works, can an incoming call being routed to A and B
simulaneously?
Yes, calls would be forked to both entries in location table.
Cheers, DanB
On 8/27/07, Peter P GMX Prometheus001@gmx.net wrote:
Does anyone have an idea how OpenSER behaves in terms of call forking?
That means:
- A sip client A registers at OpenSER from IP adress A,
- then another SIP client B registers at OpenSER from IP adress B with
the same credentials while A ist still registered.
Question 1:
- does OpenSER allow both clients to register with the same credentials?
Question 2:
- can this be switched on/off somewhere?
Question 3:
- in case it works, can an incoming call being routed to A and B
simulaneously?
Thanks for your help Peter
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Dan-Cristian Bogos -
Peter P GMX -
Stefan Sayer -
Victor Gamov