sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

[Users] OpenSER + SEMS + Nat?
by Brandon Armstead 08 Nov '06

08 Nov '06

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

1 0

[Serusers] Using scripts with exec module
by Prettl, Kathrin 08 Nov '06

08 Nov '06

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

3 3

Fw: [Users] TM : retransmission timers
by Rao Ramaratnamma 08 Nov '06

08 Nov '06

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

7 12

[Serusers] RE: XCAP server
by Jayantheesh Srimushnam - TLS, Chennai 08 Nov '06

08 Nov '06

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.

1 0

[Users] newbie wants to forward REGISTERs through DMZ to internal SIP server
by Simon Barber 08 Nov '06

08 Nov '06

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

2 1

[Users] Problems with DNS.
by nick 08 Nov '06

08 Nov '06

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???

5 13

Re: [Users] Errors whie starting openser with radius server integration
by Sanjeev Manoli 08 Nov '06

08 Nov '06

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

1 0

Re: [Users] TM : retransmission timers
by Rao Ramaratnamma 08 Nov '06

08 Nov '06

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

2 1

[Users] one way audio
by rilawich ango 08 Nov '06

08 Nov '06

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.

1 0

[Users] Forwarding requests
by Harry Harcrow 07 Nov '06

07 Nov '06

_____ From: Harry Harcrow [mailto:harry.harcrow@verizonbusiness.com] Sent: Tuesday, November 07, 2006 3:36 PM To: 'users(a)openser.org' Subject: Forwarding requests I have my SER server running on a Linux machine and I am attempting to forward some requests to a Cisco SIP server. I have been running X-lite clients on windows and the same Linux box that the SER server is running on. I have no problem completing calls between the X-lite clients OR with either X-lite client calling the Cisco SIP server directly. However, when I try to make a call from either X-lite client through the SER server I eventually get timeout methods. I am trapping those calls and wrote the following route block: route [5] { record_route(); forward(uri:host, uri:port); } I have tried replacing the forward with send() and t_relay() method calls, but nothing seems to work. The header from the X-lite client directly to the Cisco SIP server, which works is: INVITE sip:2158200@65.221.7.xxx SIP/2.0 Via: SIP/2.0/UDP 166.34.149.xxx:5061;rport;branch=z9hG4bK5963AD09C90F6F3A16F55A271C98F573 From: Harry Harcrow <sip:1000@166.34.149.xxx:5061>;tag=1279481120 To: <sip:2158200@65.221.7.xxx> Contact: <sip:1000@166.34.149.xxx:5061> Call-ID: 28E5B723-9B02-BF38-1A81-1FECC0A85D5E(a)166.34.149.xxx CSeq: 6254 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105d Content-Length: 313 The header from SER to the Cisco server, which does not work is: INVITE sip:2158200@65.221.7.xxx SIP/2.0 Record-Route: <sip:166.34.149.xxx;ftag=2061592395;lr=on> Via: SIP/2.0/UDP 166.34.149.xxx;branch=0 Via: SIP/2.0/UDP 166.34.149.xxx:5061;rport=5061;branch=z9hG4bK4EA9A90B8CE7CE52BFB69DA431560E5 7 From: Harry Harcrow <sip:1000@166.34.149.xxx:5061>;tag=2061592395 To: <sip:2158200@65.221.7.xxx> Contact: <sip:1000@166.34.149.xxx:5061> Call-ID: 38CA166F-59A6-E44B-F34E-9E1D6307698B(a)166.34.149.xxx CSeq: 3009 INVITE Max-Forwards: 16 Content-Type: application/sdp User-Agent: X-Lite release 1105d Content-Length: 313 The only thing that I can see different is the record_route record and an additional Via record. Does anyone have any idea what I am doing wrong? Thanks Harry Harcrow

1 0

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