sr-users November 2006

sr-users@lists.kamailio.org

189 participants
306 discussions

by Ion Minzu

Hello , I have connected openser with pstn through cisco. when I make a call from voip network to pstn it's ok. but from pstn to voip I have a problem:openser answers 403 forbiden. in openser I do the authorisation on mysql, I have disabled authorisation on sip gateway: if (src_ip!=X.X.X.X) { if (!www_authorize("DOMAIN.COM","subscriber")) { www_challenge("DOMAIN.COM","0"); exit; } }; What is the problem? X.X.X.X is cisco U X.X.X.X:54177 -> 172.17.6.2:5060 INVITE sip:820022@172.17.6.2:5060 SIP/2.0..Via: SIP/2.0/UDP X.X.X.X:5060..From: <sip:022250699@X.X.X.X>;tag=1A0FBC30-1472..To: <sip:820022@172.1 7.6.2>..Date: Wed, 08 Nov 2006 11:03:14 GMT..Call-ID: 906DA628-6E4F11DB-9034EA4F-E981BA1F@X.X.X.X..Supported: timer,100rel..Min-SE: 1800..Cisco-Guid : 2422905184-1850675675-2419190351-3917593119..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBS CRIBE, NOTIFY, INFO..CSeq: 101 INVITE..Max-Forwards: 6..Remote-Party-ID: <sip:022250699@X.X.X.X>;party=calling;screen=yes;privacy=off..Timestamp: 116 2983794..Contact: <sip:022250699@X.X.X.X:5060>..Expires: 180..Allow-Events: telephone-event..Content-Type: application/sdp..Content-Length: 235....v= 0..o=CiscoSystemsSIP-GW-UserAgent 1226 5023 IN IP4 X.X.X.X..s=SIP Call..c=IN IP4 X.X.X.X..t=0 0..m=audio 16642 RTP/AVP 18 19..c=IN IP4 X.X.X.X..a=rtpmap:18 G729/8000..a=fmtp:18 annexb=no..a=rtpmap:19 CN/8000..a=ptime:20.. # U 172.17.6.2:5060 -> X.X.X.X:5060 SIP/2.0 403 Use From=ID..Via: SIP/2.0/UDP X.X.X.X:5060..From: <sip:022250699@X.X.X.X>;tag=1A0FBC30-1472..To: <sip:820022@172.17.6.2>;tag=329cfeaa6ded039da25ff8cbb8668bd2.13ec..Call-ID: 906DA628-6E4F11DB-9034EA4F-E981BA1F@X.X.X.X..CSeq: 101 INVITE..Server: OpenSer (1.1.0-tls (x86_64/linux))..C ontent-Length: 0..Warning: 392 172.17.6.2:5060 "Noisy feedback tells: pid=32240 req_src_ip=X.X.X.X req_src_port=54177 in_uri=sip:820022@172.17.6.2:5 060 out_uri=sip:820022@172.17.6.2:5060 via_cnt==1".... # U X.X.X.X:54177 -> 172.17.6.2:5060 ACK sip:820022@172.17.6.2:5060 SIP/2.0..Via: SIP/2.0/UDP X.X.X.X:5060..From: <sip:022250699@X.X.X.X>;tag=1A0FBC30-1472..To: <sip:820022@172.17.6 .2>;tag=329cfeaa6ded039da25ff8cbb8668bd2.13ec..Date: Wed, 08 Nov 2006 11:03:14 GMT..Call-ID: 906DA628-6E4F11DB-9034EA4F-E981BA1F@X.X.X.X..Max-Forward s: 6..Content-Length: 0..CSeq: 101 ACK.... Best regards, Ion Minzu, Specialist Tehnologii Informationale, Administrator de sistem al Centrului de certificare, Administrator VoIP, I.S."Centrul de Telecomunicatii Speciale", tel:250-517 (office), 069501208 (mob), 382869185 (ICQ) mailto:ion.minzu@cts.md

17 years, 11 months

[Users] OpenSER + SEMS + Nat?

by Brandon Armstead

Hello, I currently have an openser server running on port 5060, and a second that handles voicemail / stateful transaction stuff on port 5070. So, I am having proxy A forward to proxy B to do the handling which are both on the same server, although there seems to be a problem with NAT'ing, when I call 'voicemail' or something I can not hear anything. It seems to be because it is sending the RTP data to the wrong location? It should be sending it back to public-ip-addr-1 when it is sending to an internal ip address 192.168.1.* Here is the log from sems: 101 44811:1466724767 <sip:public-ip-addr-1:5060;nat=yes;ftag=dd9bbf561d35ee06o0;lr=on> sip:public-ip-addr-1:5060;nat=yes;ftag=dd9bbf561d35ee06o0;lr=on P-MsgFlags: 0 UA: Linksys/PAP2-3.1.9(LSa) P-Email-Address: test(a)test.com . v=0 o=- 9200357 9200357 IN IP4 192.168.1.241 s=- c=IN IP4 192.168.1.241 t=0 0 m=audio 16420 RTP/AVP 0 2 4 8 18 96 97 98 100 101 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv > (7856) DEBUG: execute (AmInterfaceHandler.cpp:99): req.method = <INVITE> (7856) DEBUG: execute (AmInterfaceHandler.cpp:100): req.user = <115> (7856) DEBUG: execute (AmInterfaceHandler.cpp:101): req.domain = <public-ip-addr-1> (7856) DEBUG: execute (AmInterfaceHandler.cpp:102): req.dstip = <public-ip-addr-1> (7856) DEBUG: execute (AmInterfaceHandler.cpp:103): req.port = <5070> (7856) DEBUG: execute (AmInterfaceHandler.cpp:104): req.r_uri = < sip:115@public-ip-addr-1:5070> (7856) DEBUG: execute (AmInterfaceHandler.cpp:105): req.from_uri = < sip:1000@192.168.1.241:5060> (7856) DEBUG: execute (AmInterfaceHandler.cpp:106): req.from = <Brandon1 < sip:1000@test.mydomain.com>> (7856) DEBUG: execute (AmInterfaceHandler.cpp:107): req.to = << sip:115@test.mydomain.com>> (7856) DEBUG: execute (AmInterfaceHandler.cpp:108): req.callid = < 81e2d596-978fccc6(a)192.168.1.241> (7856) DEBUG: execute (AmInterfaceHandler.cpp:109): req.from_tag = <dd9bbf561d35ee06o0> (7856) DEBUG: execute (AmInterfaceHandler.cpp:110): req.to_tag = <> (7856) DEBUG: execute (AmInterfaceHandler.cpp:113): cseq_str = <101> (7856) DEBUG: execute (AmInterfaceHandler.cpp:119): cseq = <101>(101) (7856) DEBUG: execute (AmInterfaceHandler.cpp:121): req.key = <44811:1466724767> (7856) DEBUG: execute (AmInterfaceHandler.cpp:122): req.route = <<sip:public-ip-addr-1:5060;nat=yes;ftag=dd9bbf561d35ee06o0;lr=on>> (7856) DEBUG: execute (AmInterfaceHandler.cpp:123): req.next_hop = <sip:public-ip-addr-1:5060;nat=yes;ftag=dd9bbf561d35ee06o0;lr=on> (7856) DEBUG: execute (AmInterfaceHandler.cpp:128): hdrs = <P-MsgFlags: 0 UA: Linksys/PAP2-3.1.9(LSa) P-Email-Address: test(a)test.com > (7856) DEBUG: execute (AmInterfaceHandler.cpp:133): body = <v=0 o=- 9200357 9200357 IN IP4 192.168.1.241 s=- c=IN IP4 192.168.1.241 t=0 0 m=audio 16420 RTP/AVP 0 2 4 8 18 96 97 98 100 101 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv > (7856) DEBUG: execute (AmInterfaceHandler.cpp:144): Request OK: dispatch it! (7856) DEBUG: postEvent (AmEventQueue.cpp:48): AmEventQueue: trying to post event (7856) DEBUG: postEvent (AmEventQueue.cpp:56): AmEventQueue: event posted (7856) DEBUG: processEvents (AmEventQueue.cpp:69): before processing event (7856) DEBUG: process (AmSession.cpp:421): AmSession::process (7856) DEBUG: process (AmSession.cpp:425): Session received SIP Event (7856) DEBUG: onSipRequest (AmSession.cpp:472): onSipRequest: method = INVITE (7856) DEBUG: parse_sdp_media (AmSdp.cpp:632): next_line=<a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv > (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:0 PCMU/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=0; enc=PCMU; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:2 G726-32/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=2; enc=G726-32; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:4 G723/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=4; enc=G723; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:8 PCMA/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=8; enc=PCMA; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:18 G729a/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=18; enc=G729a; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:96 G726-40/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=96; enc=G726-40; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:97 G726-24/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=97; enc=G726-24; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:98 G726-16/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=98; enc=G726-16; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:100 NSE/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=100; enc=NSE; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:101 telephone-event/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=101; enc=telephone-event; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=fmtp:101 0-15 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=ptime:30 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:740): unknown attribute definition 'ptime:30' (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=sendrecv (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:745): flag definition is not yet supported (sendrecv) (7856) DEBUG: parse_sdp_media (AmSdp.cpp:651): ret=0; next_line=<> (7856) DEBUG: getCompatiblePayload (AmSdp.cpp:341): payload found: 0/PCMU/8000 (7856) DEBUG: getCompatiblePayload (AmSdp.cpp:344): using global address: 192.168.1.241 (7856) DEBUG: negotiate (AmSession.cpp:247): remote party supports telephone events (pt=101) (7856) DEBUG: setRAddr (AmRtpStream.cpp:346): RTP remote address set to 192.168.1.241:16420 (7856) DEBUG: init (AmRtpAudio.cpp:146): AmRtpAudio::init(...) (7856) DEBUG: acceptAudio (AmSession.cpp:607): Sending Rtp data to 192.168.1.241/16420 (7856) DEBUG: updateStatusReply (AmSipDialog.cpp:86): reply: transaction found! (7856) DEBUG: updateStatusReply (AmSipDialog.cpp:125): req.method = INVITE; t.method = INVITE (7856) DEBUG: init (AmCtrlInterface.cpp:231): AmUnixCtrlInterface::init @ /tmp/5D08F0A1-4552226600080041-08108600 (7856) DEBUG: write_to_socket (AmUtils.cpp:588): sending: <:t_reply:/tmp/5D08F0A1-4552226600080041-08108600 200 OK 44811:1466724766 193812C5-45522256000F0C97-08103000 Contact: <sip:115@public-ip-addr-1:5070> Content-Type: application/sdp . v=0 o=username 0 0 IN IP4 public-ip-addr-1 s=session c=IN IP4 public-ip-addr-1 t=0 0 m=audio 10022 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 . > (7856) DEBUG: write_to_socket (AmUtils.cpp:614): write to unix socket: completed (7856) DEBUG: cacheMsg (AmCtrlInterface.cpp:186): recv-ed: <200 Succeeded> (7856) DEBUG: processEvents (AmEventQueue.cpp:71): event processed (7856) DEBUG: processEvents (AmEventQueue.cpp:69): before processing event (7856) DEBUG: process (AmSession.cpp:421): AmSession::process (7856) DEBUG: process (AmSession.cpp:425): Session received SIP Event (7856) DEBUG: onSipRequest (AmSession.cpp:472): onSipRequest: method = INVITE (7856) DEBUG: parse_sdp_media (AmSdp.cpp:632): next_line=<a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv > (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:0 PCMU/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=0; enc=PCMU; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:2 G726-32/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=2; enc=G726-32; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:4 G723/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=4; enc=G723; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:8 PCMA/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=8; enc=PCMA; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:18 G729a/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=18; enc=G729a; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:96 G726-40/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=96; enc=G726-40; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:97 G726-24/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=97; enc=G726-24; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:98 G726-16/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=98; enc=G726-16; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:100 NSE/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=100; enc=NSE; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:101 telephone-event/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=101; enc=telephone-event; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=fmtp:101 0-15 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=ptime:30 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:740): unknown attribute definition 'ptime:30' (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=sendrecv (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:745): flag definition is not yet supported (sendrecv) (7856) DEBUG: parse_sdp_media (AmSdp.cpp:651): ret=0; next_line=<> (7856) DEBUG: getCompatiblePayload (AmSdp.cpp:341): payload found: 0/PCMU/8000 (7856) DEBUG: getCompatiblePayload (AmSdp.cpp:344): using global address: 192.168.1.241 (7856) DEBUG: negotiate (AmSession.cpp:247): remote party supports telephone events (pt=101) (7856) DEBUG: setRAddr (AmRtpStream.cpp:346): RTP remote address set to 192.168.1.241:16420 (7856) DEBUG: init (AmRtpAudio.cpp:146): AmRtpAudio::init(...) (7856) DEBUG: acceptAudio (AmSession.cpp:607): Sending Rtp data to 192.168.1.241/16420 (7856) DEBUG: updateStatusReply (AmSipDialog.cpp:86): reply: transaction found! (7856) DEBUG: updateStatusReply (AmSipDialog.cpp:125): req.method = INVITE; t.method = INVITE (7856) DEBUG: init (AmCtrlInterface.cpp:231): AmUnixCtrlInterface::init @ /tmp/75EE09BE-4552226600080514-08108600 (7856) DEBUG: write_to_socket (AmUtils.cpp:588): sending: <:t_reply:/tmp/75EE09BE-4552226600080514-08108600 200 OK 44811:1466724767 193812C5-45522256000F0C97-08103000 Contact: <sip:115@public-ip-addr-1:5070> Content-Type: application/sdp . v=0 o=username 0 0 IN IP4 public-ip-addr-1 s=session c=IN IP4 public-ip-addr-1 t=0 0 m=audio 10022 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 . > (7856) DEBUG: write_to_socket (AmUtils.cpp:614): write to unix socket: completed (7856) DEBUG: cacheMsg (AmCtrlInterface.cpp:186): recv-ed: <200 Succeeded> (7856) DEBUG: processEvents (AmEventQueue.cpp:71): event processed (7856) DEBUG: run (AmSession.cpp:292): 81e2d596-978fccc6(a)192.168.1.241 dlg.getUACTransPending() = 0 Here is my config for "proxy B" the transaction handling with SEMS that "proxy A" sends to: # # $Id: ser.cfg,v 1.25.2.1 2005/02/18 14:30:44 andrei Exp $ # # ser for sems configuration # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5070 children=4 unix_sock="/tmp/openser_sems_sock" # ------------------ module loading ---------------------------------- mpath="/usr/local/lib/openser/modules" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "avpops.so" # ----------------- setting module-specific parameters --------------- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) modparam("avpops", "avp_aliases", "email=i:67") modparam("tm", "pass_provisional_replies", 1) # appends for INVITE to voicemail modparam("tm", "tw_append", "voicemail_headers:UA=$hdr(User-Agent);P-Email-Address=$avp(s:email)") # appends for dtmf per INFO modparam("tm", "tw_append", "info_append:Content-Length=$hdr(Content-Length);Content-Type=$hdr(Content-Type);$rb") # 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; }; if (method != "ACK" && method != "INVITE" && method != "BYE" && method != "CANCEL" && method != "INFO" ){ log("unsupported method\n"); sl_send_reply("500","unsupported method"); 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 record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing # make transaction if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); if (!t_relay()) { sl_reply_error(); } return; }; if (!t_newtran()){ log("could not create transaction\n"); sl_send_reply("500","could not create transaction"); return; } # actively absorb ACKs if (method == "ACK") { t_relay(); return; } # pass INFO to SEMS if (method=="INFO") { if(!t_write_unix("/tmp/sems_sock","sems/info_append")){ log("could not contact sems\n"); t_reply("500","could not contact media server"); } } if (uri =~ "sip:101.*@") { if (!t_write_unix("/tmp/sems_sock","myapp")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:102.*@") { if (!t_write_unix("/tmp/sems_sock","myconfigurableapp")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:103.*@") { if (!t_write_unix("/tmp/sems_sock","myannounceapp")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:104.*@") { if (!t_write_unix("/tmp/sems_sock","myjukebox")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:105.*@") { if (!t_write_unix("/tmp/sems_sock","mycc")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:106.*@") { if (!t_write_unix("/tmp/sems_sock","ivr_announce")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } ############ default sems apps if (uri =~ "sip:110.*@") { if (!t_write_unix("/tmp/sems_sock","echo")){ log("could not contact echo\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:111.*@") { if (!t_write_unix("/tmp/sems_sock","announcement")){ log("could not contact announcement\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:112.*@") { if (!t_write_unix("/tmp/sems_sock","conference")){ log("could not contact conference\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:113.*@") { if (!t_write_unix("/tmp/sems_sock","mailbox")){ log("could not contact mailbox\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:114.*@") { if (!t_write_unix("/tmp/sems_sock","early_announce")){ log("could not contact early_announce\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:115.*@") { # load email avp with some email address avp_write("test(a)test.com","$avp(s:email)"); # use voicemail_headers append to pass it to sems if (!t_write_unix("/tmp/sems_sock","voicemail/voicemail_headers")){ log("could not contact voicemail\n"); t_reply("500","could not contact media server"); return; } return; } t_reply("404","Not found"); } Thank you, any and all help is appreciated, thanks again! -- Brandon Armstead

17 years, 11 months

[Serusers] Using scripts with exec module

by Prettl, Kathrin

I have written a shell script which has a return value of either 0 or 1. Depending on the outcome of this script I want SER to react. I know I have to use the exec module for this but I don't know how. Can anyone help? Thanks, Kathrin

17 years, 11 months

Fw: [Users] TM : retransmission timers

by Rao Ramaratnamma

sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this. rr ----- Forwarded Message ---- From: Rao Ramaratnamma <raramarat(a)yahoo.com> To: Christian Schlatter <cs(a)unc.edu>; users(a)openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter! Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer. thank you in advance! rr ----- Original Message ---- From: Christian Schlatter <cs(a)unc.edu> To: users(a)openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers Greg Fausak wrote: > Hello, > > I believe this is a well known bug. > Granularity of timers is 1 second. So, if you sign up for a timer to > be fired in 1 second it will happen anywhere between 0 seconds and 1 > second. > 2 seconds will happen between 1 and 2 seconds. I usually set up my > timers to be 2, 2, 4, 8. There are VOIP providers that are pretty > sticky about > the first 500ms. If you are using one of them you're out of luck. Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times. Christian > > I believe SER has made timer changes to support more exact timer > intervals. They are a completely different camp, with a different feature > set (although they share the same roots). > > -g > > > On 11/7/06, Jean-François SMIGIELSKI <jf-smig(a)ibelgique.com> wrote: >> Hello, >> >> I made strange observations about the intervals between >> retransmissions with the TM module. >> In my experiments, I used the default parameters for the TM module >> timers, and I sent an INVITE that cannot receive answers (it has a >> well known R-URI pattern that is forwarded to a place and port that >> nobody listen). >> >> When reading RFC3261, I expected to see intervals between >> retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s. >> >> But with OpenSER, (I have tested with the debian package 1.1.0-5 on a >> debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by >> myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s >> are spent (9 sendings). The first interval is sometomes very short >> (40ms). >> >> Altough I like the sequence of 4s separated transmissions, I do not >> know why the first interval is so short, and why there is no sending >> after 1s. >> >> Did anybody observed such behaviours? Are they normal? >> >> Thanks in advance! >> >> JF Smigielski. >> >> >> ________________________________________________________________________ >> iBELGIQUE, exprimez-vous ! >> http://web.ibelgique.com/ >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > > _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

17 years, 11 months

[Serusers] RE: XCAP server

by Jayantheesh Srimushnam - TLS, Chennai

Hi, Is it possible to run XCAP server as a standalone? I didn't see any info about this in the document. --Jayantheesh _____ From: Jayantheesh Srimushnam - TLS, Chennai Sent: Tuesday, November 07, 2006 8:44 PM To: 'serusers(a)iptel.org' Cc: Jayantheesh Srimushnam - TLS, Chennai Subject: XCAP server Hi All, I have downloaded the SER and trying to run XCAP server. I have gone through the README file for the XCAP server and understood that it is server simulation. Still I didn't get how to install and run it. Could anyone please through some light on this? Thanks, Jayantheesh DISCLAIMER The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect.

17 years, 11 months

[Users] newbie wants to forward REGISTERs through DMZ to internal SIP server

by Simon Barber

Hi All, I have an internal SIP server that handles registrations, and is used for incoming and outgoing phone calls. It does not do any authentication. I'd like to set up SER in my DMZ, and have it: 1. authenticate all requests. (this should be easy - I think I can handle it, although I would like to get digest -> RADIUS auth against an Active directory going). 2. forward REGISTER requests to the internal SIP server, both for phones on the internal network and for phones on the external network. 3. forward INVITE and ACK requests performing the correct handling of NAT, using RTP helper to forward media when needed. Right now I'd love to just get the REGISTER requests doing the right thing. Any help, or even better sample config scripts would be much appreciated. Simon

17 years, 11 months

[Users] Problems with DNS.

by nick

I'm trying to get my machine ready to work externally, with public Ip addresses. I believe I've got all the pieces ready for the domain. I have the PTR records published for my server's public IP address. I have the .sip_.udp.mobilia.it. 0 0 5060 sipserver.mobilia.it. record (I tried it with and without the .mobilia.it added to the udp) published, I tell the server to listen on the IP addresses which maps it's name in DNS, I have a line after listen : alias="mobilia.it" (I've tried both FQDN and this) I've exported the domain both as the command export SIP_DOMAIN="mobilia.it" and in the openserctlrc (does it need to be the FQDN or just the domain, again, neither seem to make a difference..) however, I still can't get the machine to believe that it is actually responsible for this domain. When I register I have errors along this line: (it registers, obviously, but the logic is wrong, since he thinks the user is coming from another domain). grep_sock_info - checking if host==us: 10==13 && [mobilia.it] == [89.202.252.16] Nov 3 10:13:34 sipserver /usr/local/sbin/openser[3193]: grep_sock_info - checking if port 5060 matches port 5060 Nov 3 10:13:34 sipserver /usr/local/sbin/openser[3193]: grep_sock_info - checking if host==us: 10==13 && [mobilia.it] == [89.202.252.16] Nov 3 10:13:34 sipserver /usr/local/sbin/openser[3193]: grep_sock_info - checking if port 5060 matches port 5060 Can anyone venture a guess as to what I might be missing???

17 years, 11 months

Re: [Users] Errors whie starting openser with radius server integration

by Sanjeev Manoli

Hi Ravi, Thanks for your help and suggestion. I went through avp module documentation and figured out that the avp_check syntax in config.cfg file was incorrect. I changed it as follows and now it's working, if(!avp_check("$avp(i:2)", "eq/$avp($src_ip)/ig")) { sl_send_reply("403", "Forbidden IP"); exit; }; But still I get parse error for following 2 statements in openser.cfg (I commented them to make forward progress). Please advice modparam("acc", "radius_extra", "Sip-Src-IP=$si;Sip-Src-Port=$sp") modparam("avpops", "avp_aliases", "day=i:101;time=i:102") Another thing is I am currently using the file based radius authentication for the users. (I have created a file called /usr/local/etc/raddb/users with 2 users). Do you know how to enable/use radius with user authentication done from a database (i am using mysql). I couldn't find any documentation for it. Thanks for the help - Sanjeev On 11/6/06, raviprakash sunkara <sunkara.raviprakash.feb14(a)gmail.com> wrote: > Usrs usrloc is comment, > > > > > > On 11/7/06, Sanjeev Manoli <meghsan(a)gmail.com> wrote: > > Hi, > > I am getting following errors as seen in /var/log/message while > > running openser with radius integration, > > > ***************************************************************************************** > > Nov 6 20:33:45 lx-dev monit[13565]: 'openser' start: /etc/init.d/openser > > Nov 6 20:33:45 lx-dev monit[13565]: 'openser' failed to start > > Nov 6 20:33:45 lx-dev openser: init_tcp: using epoll_lt as the io > > watch method (auto detected) > > Nov 6 20:33:45 lx-dev openser: INFO: statistics manager successfully > > initialized > > Nov 6 20:33:45 lx-dev openser: StateLess module - initializing > > Nov 6 20:33:45 lx-dev openser: TM - initializing... > > Nov 6 20:33:46 lx-dev openser: Maxfwd module- initializing > > Nov 6 20:33:46 lx-dev openser: AVPops - initializing > > Nov 6 20:33:46 lx-dev openser: TextOPS - initializing > > Nov 6 20:33:46 lx-dev openser: ACC - initializing > > Nov 6 20:33:46 lx-dev openser: AUTH module - initializing > > Nov 6 20:33:46 lx-dev openser: xl_parse_item: error - bad parameters > > Nov 6 20:33:46 lx-dev openser: ERROR:avpops:fixup_check_avp: unable > > to get pseudo-variable in P1 > > Nov 6 20:33:46 lx-dev openser: ERROR: fix_actions: fixing failed > > (code=-2) at cfg line 146 > > Nov 6 20:33:46 lx-dev openser: ERROR: fix_expr : fix_actions error > > > ***************************************************************************************** > > I am using openser (Version: openser-1.1.0-tls) and radius server > > (freeradius-1.1.3) along with radiusclient-ng (radiusclient-ng-0.5.2 ). > > I exactly followed the following radius integration documentation > > from openser web site, > > http://openser.org/docs/openser-radius-1.0.x.html > > > > If I remove the radius integration related part from openser.cfg then > > my openser server starts fine, I have tested it with kphone SIP UA and > > it works fine. > > > > One other question is I get parse error for following 2 statements in > > openser.cfg (I commented them to make forward progress). Please advice > > the right syntax to use following modparam statements. > > modparam("acc", "radius_extra", > "Sip-Src-IP=$si;Sip-Src-Port=$sp") > > modparam("avpops", "avp_aliases", "day=i:101;time=i:102") > > > > This is kind of urgent for me and I am clueless at this point so > > really appreciate all your help. > > > > Thanks, > > - San > > P.S. For your reference here is the openser.cfg file that I am using, > > # > > # $Id$ > > # > > # radius config script > > # > > > > # ----------- global configuration parameters ------------------------ > > > > debug=9 # debug level (cmd line: -dddddddddd) > > fork=no > > log_stderror=no # (cmd line: -E) > > > > check_via=no # (cmd. line: -v) > > dns=no # (cmd. line: -r) > > rev_dns=no # (cmd. line: -R) > > port=5060 > > children=4 > > listen=udp: 192.168.0.5 > > alias="192.168.0.5" > > > > #fifo="/tmp/openser_fifo" > > > > # ------------------ module loading > ---------------------------------- > > mpath="/usr/local/lib/openser/modules" > > > > loadmodule "mysql.so" > > loadmodule "sl.so" > > loadmodule "tm.so" > > loadmodule "rr.so" > > loadmodule "maxfwd.so" > > loadmodule "avpops.so" > > loadmodule " usrloc.so" > > loadmodule "registrar.so" > > loadmodule "textops.so" > > loadmodule "xlog.so" > > loadmodule "uri.so" > > loadmodule "acc.so" > > loadmodule "auth.so" > > loadmodule "auth_radius.so" > > loadmodule "group_radius.so" > > loadmodule "avp_radius.so" > > > > # ----------------- setting module-specific parameters --------------- > > > > # -- usrloc params -- > > > #modparam("usrloc","db_url","mysql://openser:openserrw@localhost/openser") > > modparam("usrloc", "db_mode", 2) > > > > # -- acc params -- > > modparam("acc", "radius_flag", 1) > > modparam("acc", "radius_missed_flag", 2) > > modparam("acc", "log_flag", 1) > > modparam("acc", "log_missed_flag", 1) > > modparam("acc", "service_type", 15) > > #modparam("acc", "radius_extra", > "Sip-Src-IP=$si;Sip-Src-Port=$sp") > > modparam("acc|auth_radius|group_radius|avp_radius", > "radius_config", > > "/etc/radiusclient-ng/radiusclient.conf") > > > > # -- group_radius params -- > > modparam("group_radius", "use_domain", 1) > > > > # -- avpops params -- > > #modparam("avpops", "avp_aliases", "day=i:101;time=i:102") > > > > # -- rr params -- > > # add value to ;lr param to make some broken UAs happy > > modparam("rr", "enable_full_lr", 1) > > > > # ------------------------- 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"); > > exit; > > }; > > > > if (msg:len >= 2048 ) { > > sl_send_reply("513", "Message too big"); > > exit; > > }; > > > > # check if user is suspended > > > if(is_method("REGISTER|INVITE|MESSAGE|OPTIONS|SUBSCRIBE")) > > { > > if (radius_is_user_in("From", "suspended")) { > > sl_send_reply("403", "Forbidden - > suspended"); > > exit; > > }; > > }; > > > > # 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"); > > if(is_method("BYE")) > > { # log it all the time > > acc_rad_request("200 ok"); > > acc_log_request("200 ok"); > > } > > route(1); > > }; > > > > if(is_method("INVITE") && !has_totag()) > > { # set the acc flags > > setflag(1); > > setflag(2); > > }; > > > > if (!uri==myself) { > > # check if user is allowed to do voip calls to other domains > > if(is_method("INVITE|MESSAGE")) { > > if (!radius_is_user_in("From", "voip")) { > > sl_send_reply("403", "Forbidden VoIP"); > > exit; > > }; > > }; > > # mark routing logic in request > > append_hf("P-hint: outbound\r\n"); > > route(1); > > }; > > > > # 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 (uri==myself) { > > # authenticate registers > > if (method=="REGISTER") { > > if (!radius_www_authorize("192.168.0.5")) { > > www_challenge("192.168.0.5", "0"); > > exit; > > }; > > > > # check the src ip address > > > Call the method is Wrong , Check the Module doc od avp_radius and Avp, > > > > > if(!avp_check("i:2", "eq/$src_ip/ig")) > > { > > sl_send_reply("403", "Forbidden IP"); > > exit; > > }; > > > > save("location"); > > exit; > > }; > > > > # calls to pstn > > if(uri=~"sip:00[1-9][0-9]+@") { > > if(is_method("INVITE") && !has_totag()) { > > if (!radius_is_user_in("From", "pstn")) { > > sl_send_reply("403", "Forbidden > PSTN"); > > exit; > > }; > > }; > > # set gateway address > > rewritehostport(" 10.10.10.10:5090"); > > route(1); > > }; > > > > # load callee's avps > > if(avp_load_radius("callee")) > > { > > # check if user has time filter enabled > > if(avp_check("i:3", "eq/i:1")) > > { > > # print time in an avp > > avp_printf("i:100", "$Tf"); > > # extract day > > avp_subst("i:100/i:101", "/(.{3}) > .+/*\1*/"); > > if(!avp_check("i:6", "fm/$day")) { > > sl_send_reply("403", "Forbidden - > day"); > > exit; > > }; > > # extract 'hours:minutes' > > avp_subst("i:100/i:102", "/(.{10}) > (.{5}):.+/\2/"); > > if((is_avp_set("i:4") && avp_check("i:4", > "gt/$time")) > > || (is_avp_set("i:5") && avp_check("i:5", "lt/$time"))) { > > sl_send_reply("403", "Forbidden - > time"); > > exit; > > }; > > }; > > }; > > > > # native SIP destinations are handled using our USRLOC DB > > if (!lookup("location")) { > > # log to acc as missed call > > acc_rad_request("404 Not Found"); > > acc_log_request("404 Not Found"); > > sl_send_reply("404", "Not Found"); > > exit; > > }; > > append_hf("P-hint: usrloc applied\r\n"); > > }; > > > > route(1); > > } > > > > # generic forward > > route[1] { > > # send it out now; use stateful forwarding as it works reliably > > # even for UDP2TCP > > if (!t_relay()) { > > sl_reply_error(); > > }; > > exit; > > } > > # > > > > _______________________________________________ > > Users mailing list > > Users(a)openser.org > > http://openser.org/cgi-bin/mailman/listinfo/users > > > > > > -- > Thanks and Regards > Ravi Prakash Sunkara > ravi.sunkara(a)hyperion-tech.com > M:+91 9985077535 > O:+91 40 23114549 > F:+91 40 40208727 > ravi.sunkara(a)hyperion-tech.com > www.hyperion-tech.com

17 years, 11 months

Re: [Users] TM : retransmission timers

by Rao Ramaratnamma

the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter! Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer. thank you in advance! rr ----- Original Message ---- From: Christian Schlatter <cs(a)unc.edu> To: users(a)openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers Greg Fausak wrote: > Hello, > > I believe this is a well known bug. > Granularity of timers is 1 second. So, if you sign up for a timer to > be fired in 1 second it will happen anywhere between 0 seconds and 1 > second. > 2 seconds will happen between 1 and 2 seconds. I usually set up my > timers to be 2, 2, 4, 8. There are VOIP providers that are pretty > sticky about > the first 500ms. If you are using one of them you're out of luck. Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times. Christian > > I believe SER has made timer changes to support more exact timer > intervals. They are a completely different camp, with a different feature > set (although they share the same roots). > > -g > > > On 11/7/06, Jean-François SMIGIELSKI <jf-smig(a)ibelgique.com> wrote: >> Hello, >> >> I made strange observations about the intervals between >> retransmissions with the TM module. >> In my experiments, I used the default parameters for the TM module >> timers, and I sent an INVITE that cannot receive answers (it has a >> well known R-URI pattern that is forwarded to a place and port that >> nobody listen). >> >> When reading RFC3261, I expected to see intervals between >> retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s. >> >> But with OpenSER, (I have tested with the debian package 1.1.0-5 on a >> debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by >> myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s >> are spent (9 sendings). The first interval is sometomes very short >> (40ms). >> >> Altough I like the sequence of 4s separated transmissions, I do not >> know why the first interval is so short, and why there is no sending >> after 1s. >> >> Did anybody observed such behaviours? Are they normal? >> >> Thanks in advance! >> >> JF Smigielski. >> >> >> ________________________________________________________________________ >> iBELGIQUE, exprimez-vous ! >> http://web.ibelgique.com/ >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > > _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

17 years, 11 months

[Users] one way audio

by rilawich ango

Hi all, Anyone experiences an one way audio problem when a call is connected to the called party? I am using openser with mediaproxy to provide services to our customer. However, some of our customer complain about the one way audio problem (calling party can hear called party but not vice versa). The system works to most of the customer without that problem. I wonder why there are some customers experience that problem. I assume there is the port problem during RTP packet transmission. Am I right? In the mediaproxy setting, the portRange is 2000:8000. Do I need to increase it? Any method to trace the problem if my assumption is wrong? Thanks.

17 years, 11 months

← Newer
1
...
21
22
23
24
25
26
27
...
31
Older →

Jump to page:

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 November 2006