sr-users February 2008

sr-users@lists.kamailio.org

146 participants
260 discussions

Re: [OpenSER-Users] [CDRTool] How to get the "In" and "Out"

by A.smith

Hola, >So you see "In" or/and "Out"... ANd do you mean that this info is provided by >MediaProxy instead of be deduced by CDRTool in some way? Yes, I believe this info is provided by mediaproxy as it relates to the KB of RTP data relayed by mediaproxy, this cannot be deduced as you need to be sitting in the data stream to know this... Sounds like the level of functionality provided by mediaproxy DB accouting and radius accouting are not the same. FYI here is an example of the information I see with DB accouting: (this is shown in the signalling information section of CDRTool and also I see data in the KBIn KBout sections in the summary) Media information Application: audio Codecs: G711u Caller RTP: 658.59 KB Called RTP: 653.55 KB Caller SIP UA: Asterisk PBX Called SIP UA: NCH Swift Sound Express Talk 3.02 ________________________________________________ Message sent using UK Grid Webmail 2.7.9

16 years, 9 months

[OpenSER-Users] OpenSER 1.2.X - Is it possible to check if callee in NAT-ed network?

by David Loh

Hi Guys, I've encountered one-way voice situation, where caller on Public IP make a P2P call to callee behind NAT, wondering is there any OpenSER module/function that could actually query callee's network type, if OpenSER can detect callee network (whether it's NAT or not), I can use rtp proxy to overcome the one-way voice. Currently my setup works on following: Caller --- Callee 1) WAN to WAN 2) NAT to NAT (force_rtp_proxy) 3) NAT to WAN (force_rtp_proxy) but for the WAN to NAT case, due to the caller aren't behind NAT, I didn't run force_rtp_proxy, but whenever the P2P call established, it result one-way voice. I'm thinking of querying the callee detail from database via AVP, but it doesn't sound feasible; wondering if there's any better solution. P/S: My openser.cfg (INVITE route) ------------------------------- route[3] { if(nat_uac_test("19")) { fix_nated_contact(); } # 10* = P2P call if(uri=~"^sip:10\*.+@.*") { strip(3); if(!lookup("location")) { xlog("L_INFO", "DBG: P2P Peer not found [$tu] from [$fu]($si)"); sl_send_reply("404", "User Offline"); exit; } xlog("L_INFO", "DBG: P2P Call [$fu]($si) to [$tu]"); # For NAT-to-WAN or NAT-to-NAT, supposedly WAN-to-NAT should run this too :( if(nat_uac_test("19") || search("^Route:.*;nat=yes")) { # onreply_route[2] will do a "force_rtp_proxy" t_on_reply("2"); force_rtp_proxy(); xlog("L_INFO", "DBG: NAT-ed P2P Call, RTP Proxy Forced [$fu]($si)"); } } else if(!proxy_authorize("", "subscriber")) { xlog("L_INFO", "DBG: INVITE [$fu]($si) PROXY authentication FAILED"); proxy_challenge("", "1"); exit; } if(!check_from()) { xlog("L_INFO", "INVITE Spoofed From-URI detected - RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("403", "Spoofed From-URI Detected"); exit; } rewritehost("1.2.3.4"); } t_on_reply("1"); t_on_failure("1"); t_relay(); xlog("L_INFO", "DBG: INVITE F-[$fu] T-[$tu] IP-[$si] UA-[$ua] SUCCESSFUL"); } ------------------------------- Thanks, David Loh

16 years, 9 months

Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released

by A.smith

Hi Dan/List, I was reading the post below and trying to understand how your config works. If you are implementing this with something like a Cisco PSTN then you need all of these: PSTN, OpenSER, Mediaproxy and Yate involved in the SIP route? Does the RTP stream have to route via Yate and mediaproxy? :S thanks for any help! cheers Andy. >Hey Marc, > >I use Yate for doing that. It is simple and works out of the box (with adding few >lines in configs of course). > >I take Session timeout returned from connector and pass it to yate in a sip header >Process that header in regex routing and define the value as timeout for session. >Yate knows by default that when a session has a parameter "timeout" returned >from routing to disconnect the call when timeout is hit. > >Let me know if you need further info, so I can send you some config files if you >want to. You can contact me on IRC for live support (DanB). > > >All the best, >DanB ________________________________________________ Message sent using UK Grid Webmail 2.7.9

16 years, 9 months

[Serusers] How do you really get rtpptoxy to pass audio between two interfaces?

by Frank Durda IV

Having abandoned from mediaproxy (which could not cope with a network setup with two or more interfaces), I switched to rtpproxy, but find that it also is not doing the right thing, although it gets closer that mediaproxy does. Perhaps someone will know what the missing piece of this is. To recap, we have three networks connected to the SER+rtpproxy server: 192.168.200.x/24 Connects to various SIP phones and Asterisk server(s). Can be thought to eventually be the network where the SIP clients will all be. Our players in this lab setup are: 192.168.200.10 An Asterisk server 192.168.200.20 A Linksys SIP phone - (SIP+RTP for phone goes via Asterisk server so you won't see this addr at SER server) 192.168.200.30 an interface on the SER server (re2) 10.9.193.132/28 Connects to the various SIP ports on a Class 5 PSTN switch. Only SIP packets pass on this network, eg these can't handle RTP packets. Here, our visible devices are: 10.9.193.130 The active PSTN switch SIP signaling port. 10.9.193.135 An interface on the SER server (re1) 10.9.193.142/29 Connects to the bearer/voice ports on a Class 5 PSTN switch. These are isolated ports, eg, all they do is RTP packets and no SIP packets. The devices here: 10.9.193.146 The active PSTN switch voice bearer port. 10.9.193.148 An interface on the SER server (re0) NONE of these networks can physically see the other nor router traffic, except for what passes through either SER or rtpproxy/mediaproxy. This isolation is intentional and needed because the PSTN switch has no built-in protection against unexpected/unwanted IP traffic. Of the three networks, only two handle RTP/bearer data, and only two handle SIP data. ---------------------------------------------------------------------------- What happens (or doesn't happen): The symptom is that someone (probably rtpproxy) isn't re-writting the correct IP address into the SDP payload emitted by SER, and so the calling party (or PSTN switch party) is editing in an unreachable IP address to send bearer traffic to. So rtpproxy never gets going and you have no two-way audio, although you can see audio packets being emitted by both parties, one hopelessly mis-addresed, and the others audio reaching the SER/rtpproxy server, but apparently not allowed to pass until an audio packet from the other party arrives, which will not be happening. In addition, rtpproxy doesn't listen for RTP packets on both interfaces, so one side of the conversation is always inaccessible, and since both sides must be able to send at least one audio packet for the proxy process to begin, no audio is passed in either direction. ---------------------------------------------------------------------------- A sample call and the SIP messages: 1. The Asterisk server contacts the SER server with the INVITE. It says the audio should go to 192.168.200.10:10860 (which is also the Asterisk box) # U 2008/02/13 13:58:24.691638 192.168.200.10:5060 -> 192.168.200.30:5060 INVITE sip:9613789999@192.168.200.30 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>. Contact: <sip:3797271700@192.168.200.10>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Max-Forwards: 70. Date: Wed, 13 Feb 2008 14:00:08 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 475. . v=0. o=root 23759 23759 IN IP4 192.168.200.10. s=session. c=IN IP4 192.168.200.10. t=0 0. m=audio 10860 RTP/AVP 0 3 8 112 5 10 7 97 111 101. a=rtpmap:0 PCMU/8000. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:112 AAL2-G726-32/8000. a=rtpmap:5 DVI4/8000. a=rtpmap:10 L16/8000. a=rtpmap:7 LPC/8000. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:111 G726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. 2. SER send an INVITE message on to the PSTN switch. It has correctly put its own address as where the audio should be sent later on. c=IN IP4 10.9.193.148:35010 # U 2008/02/13 13:58:24.697275 10.9.193.135:5060 -> 10.9.193.130:5060 INVITE sip:9613789999@10.9.193.130:5060 SIP/2.0. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>. Contact: <sip:3797271700@192.168.200.10:5060>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Max-Forwards: 16. Date: Wed, 13 Feb 2008 14:00:08 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 491. . v=0. o=root 23759 23759 IN IP4 192.168.200.10. s=session. c=IN IP4 10.9.193.148. t=0 0. m=audio 35010 RTP/AVP 0 3 8 112 5 10 7 97 111 101. a=rtpmap:0 PCMU/8000. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:112 AAL2-G726-32/8000. a=rtpmap:5 DVI4/8000. a=rtpmap:10 L16/8000. a=rtpmap:7 LPC/8000. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:111 G726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. a=nortpproxy:yes. 3. The PSTN switch send back a TRYING message. # U 2008/02/13 13:58:24.701458 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 100 Trying. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130>. Content-Length: 0. . 4. SER server sends the TRYING message on to Asterisk. # U 2008/02/13 13:58:24.696951 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. Server: Sip EXpress router (0.9.6 (i386/freebsd)). Content-Length: 0. . 5. PSTN switch sends the SER box a RINGING message. # U 2008/02/13 13:58:24.799647 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 180 Ringing. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130>. Content-Length: 0. . 6. SER box sends on the RINGING message to the Asterisk box. # U 2008/02/13 13:58:24.802106 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 180 Ringing. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130:5060>. Content-Length: 0. . 7. PSTN switch indicates the called party has answered to SER and gives its bearer/audio address & port (10.9.193.146:28006). # U 2008/02/13 13:58:32.736665 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 200 OK. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130>. Content-Type: application/sdp. Content-Length: 175. . v=0 o=- 3411921616 3411921696 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.146 t=0 0 m=audio 28006 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - 8. SER sends Asterisk the OK with the edited-but-WRONG bearer IP address 10.9.193.148:35012, INSTEAD of the reachable 192.168.200.30:35012 value that should have been sent. # U 2008/02/13 13:58:32.743185 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130:5060>. Content-Type: application/sdp. Content-Length: 193. . v=0 o=- 3411921616 3411921696 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.148 t=0 0 m=audio 35012 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=nortpproxy:yes. And DING, we are in trouble, because the 10.9.193.148 is the wrong IP address on the SER/rtpproxy box that the Asterisk server should send the audio to, a network that the Asterisk server can't reach. SER/rtpproxy should have edited that to read c=IN IP4 192.168.200.30 the interface facing towards the SIP phone, one of the two interfaces specified in the SER config file and rtpproxy invocation, AND started listening there. So, no audio from Asterisk will ever reach the SER/rtpproxy box, and rtpproxy will just sit there and wait. Note also that rtpproxy only listens on one of the interfaces specified: lsof -p 852 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rtpproxy 852 root cwd VDIR 0,90 512 2 / rtpproxy 852 root rtd VDIR 0,90 512 2 / rtpproxy 852 root txt VREG 0,93 71102 386745 /usr/local/bin/rtpproxy rtpproxy 852 root txt VREG 0,90 158712 94213 /libexec/ld-elf.so.1 rtpproxy 852 root txt VREG 0,90 922668 235591 /lib/libc.so.6 rtpproxy 852 root 0u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 1u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 2u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 3u unix 0xc2e4d164 0t0 /var/run/rtpproxy.sock rtpproxy 852 root 7u IPv4 0xc200f870 0t0 UDP 10.9.193.148:35010 rtpproxy 852 root 8u IPv4 0xc200fb40 0t0 UDP 10.9.193.148:35011 rtpproxy 852 root 9u IPv4 0xc200f0b4 0t0 UDP 10.9.193.148:35012 rtpproxy 852 root 10u IPv4 0xc200fd5c 0t0 UDP 10.9.193.148:35013 Swapping the order that the IP addresses are listed on the rtpproxy command line appears to dictate which address will be used exclusively, rather than using whichever is appropriate for the network of the destination. Why rtpproxy opens four sockets per call is another question for later. Now audio is seen flowing from the PSTN switch to the SER box, which seems correct: U 2008/02/13 13:58:32.692840 10.9.193.146:28006 -> 10.9.193.148:35010 ........ 9............................................................................... ................................................................................ ... But we see no audio from the Asterisk server reaching the SER/rtpproxy server, because the SIP phone was given the wrong address by SER/rtpproxy. It is probably sending audio out, but it won't reach the SER box. 9. Asterisk Server ACKs the message with the faulty data back to the SER server. # U 2008/02/13 13:58:32.744216 192.168.200.10:5060 -> 192.168.200.30:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK79c58e2e;rport. Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>,<sip:10.9.193.135;r2=on; ftag=as0458f259;lr=on>. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Contact: <sip:3797271700@192.168.200.10>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 70. Content-Length: 0. . 10. SER passes on the ACK message to the PSTN switch. # U 2008/02/13 13:58:32.745038 10.9.193.135:5060 -> 10.9.193.130:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Via: SIP/2.0/UDP 10.9.193.135;branch=0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK79c58e2e;rport=5060. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Contact: <sip:3797271700@192.168.200.10>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 16. Content-Length: 0. . 11. PSTN switch tells SER that the called party has hung up. # U 2008/02/13 14:00:17.113865 10.9.193.130:5060 -> 10.9.193.135:5060 BYE sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on SIP/2.0. Via: SIP/2.0/UDP 10.9.193.130. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. From: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. CSeq: 1 BYE. Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Route: <sip:3797271700@192.168.200.10>. Supported: timer. Content-Length: 0. Max-Forwards: 70. . 12. SER passes on the hang-up message to Asterisk. # U 2008/02/13 14:00:17.116100 192.168.200.30:5060 -> 192.168.200.10:5060 BYE sip:3797271700@192.168.200.10 SIP/2.0. Record-Route: <sip:192.168.200.30;r2=on;ftag=17b0000-0-1077770870;lr=on>. Record-Route: <sip:10.9.193.135;r2=on;ftag=17b0000-0-1077770870;lr=on>. Via: SIP/2.0/UDP 192.168.200.30;branch=z9hG4bKd67e.7d582993.0. Via: SIP/2.0/UDP 10.9.193.130. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. From: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. CSeq: 1 BYE. Supported: timer. Content-Length: 0. Max-Forwards: 16. . 13. Asterisk ACKs the message to SER. # U 2008/02/13 14:00:17.116898 192.168.200.10:5060 -> 192.168.200.30:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.30;branch=z9hG4bKd67e.7d582993.0;received=192.168.2 00.30. Via: SIP/2.0/UDP 10.9.193.130. Record-Route: <sip:192.168.200.30;r2=on;ftag=17b0000-0-1077770870;lr=on>. Record-Route: <sip:10.9.193.135;r2=on;ftag=17b0000-0-1077770870;lr=on>. From: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 1 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:3797271700@192.168.200.10>. Content-Length: 0. . ---------------------------------------------------------------------------- Invovation and Configuration Ser is started with "serctl start" and rtpproxy with rtpproxy -l 10.9.193.148/192.168.200.20 Ser is 0.9.6 and rtpproxy is a 1.1 snapshot from December (the 1.0 RELEASE link on the web site is broken) Here is the ser.cfg file. # ----------------------------------------------------------------- # ser.cfg # ----------------------------------------------------------------- # 92.168.200.30 is an interface towards external SIP gear, asterisk # ervers, etc. listen=192.168.200.30 # INSERT YOUR IP ADDRESS HERE # 0.9.193.135 is an interface directly connected to a PSTN switch # also performing SIP->TDM conversion listen=10.9.193.135 # INSERT YOUR IP ADDRESS HERE # mhomed required or ser will not attempt to match destination IPs # with the interface and network that can reach the destination. mhomed=yes # ----------------------------------------------------------------- # handbook defaults # ----------------------------------------------------------------- debug=3 fork=yes log_stderror=no sip_warning=no port=5060 children=4 dns=no rev_dns=no fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser" # ----------------------------------------------------------------- # Modules # ----------------------------------------------------------------- loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so" loadmodule "/usr/local/lib/ser/modules/textops.so" loadmodule "/usr/local/lib/ser/modules/avpops.so" loadmodule "/usr/local/lib/ser/modules/permissions.so" # ----------------------------------------------------------------- # Module settings # ----------------------------------------------------------------- modparam("auth_db|permissions|uri_db|usrloc", "db_url", "mysql://ser:heslo@local host/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("usrloc", "db_mode", 2) modparam("registrar", "nat_flag", 6) modparam("rr", "enable_full_lr", 1) modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout") modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted") # ----------------------------------------------------------------- # Main Route Evaluation # ----------------------------------------------------------------- route { log(1, "ENTERING MAIN ROUTE\n"); if (method=="REGISTER") log(1, "REGISTER message received\n"); if (method=="INVITE") log(1, "INVITE message received\n"); if (method=="ACK") log(1, "ACK message received\n"); if (method=="BYE") log(1, "BYE message received\n"); if (method=="CANCEL") log(1, "CANCEL message received\n"); if (method=="SUBSCRIBE") log(1, "SUBSCRIBE message received\n"); if (method=="NOTIFY") log(1, "NOTIFY message received\n"); if (method=="OPTIONS") log(1, "OPTIONS message received\n"); if (method=="INFO") log(1, "INFO message received\n"); if (method=="MESSAGE") log(1, "MESSAGE message received\n"); if (method=="REFER") log(1, "REFER message received\n"); # ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- log(1, "Performing Sanity Check\n"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); break; }; if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); break; }; # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- log(1, "Entering Record Route\n"); if (method!="REGISTER") { record_route(); }; if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); } # ----------------------------------------------------------------- # Call Tear Down Section # ----------------------------------------------------------------- log(1, "Entering Tear Down Section\n"); if (method=="BYE" || method=="CANCEL") { log(1, "Method was Equal to BYE or Cancel\n"); unforce_rtp_proxy(); } # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- log(1, "Entering Loose Route Section\n"); if (loose_route()) { log(1, "Call is Loose_Route\n"); if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); break; }; if (method=="INVITE") { log(1, "Loose Route Method equals Invite\n"); if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; log(1, "Consume Credentials\n"); consume_credentials(); if (nat_uac_test("19")) { log(1, "Client was client nat test 19\n"); setflag(6); force_rport(); fix_nated_contact(); }; force_rtp_proxy("l"); }; route(1); break; }; # ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- log(1, "Entering Call Type Processing\n"); if (!is_uri_host_local()) { if (is_from_local() || allow_trusted()) { log(1, "URI is local or Trusted\n"); log(1, "Going to route 4\n"); route(4); log(1, "Going to route 1\n"); route(1); } else { sl_send_reply("403", "Forbidden"); }; break; }; if (method=="ACK") { log(1, "Call Processing ACK\n"); route(1); break; } else if (method=="CANCEL") { log(1, "Call Processing CANCEL\n"); route(1); break; } else if (method=="INVITE") { log(1, "Call Processing INVITE\n"); route(3); break; } else if (method=="REGISTER") { log(1, "Call Processing REGISTER\n"); route(2); break; }; lookup("aliases"); log(1, "Lookup Aliases\n"); if (!is_uri_host_local()) { log(1, "Call Processing uri_host_local\n"); log(1, "Going to route 4\n"); route(4); log(1, "Going to route 1\n"); route(1); break; }; if (!lookup("location")) { log(1, "Call Processing lookup location\n"); sl_send_reply("404", "User Not Found"); break; }; route(1); } # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- route[1] { log(1, "Entering ROUTE[1]\n"); t_on_reply("1"); setflag(1); if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { log(1, "unforce rtp proxy\n"); unforce_rtp_proxy(); }; sl_reply_error(); }; } # ----------------------------------------------------------------- # REGISTER Message Handler # ----------------------------------------------------------------- route[2] { log(1, "Entering ROUTE[2]\n"); sl_send_reply("100", "Trying"); if (!search("^Contact:[ ]*\*") && nat_uac_test("19")) { log(1, "searching contact\n"); setflag(6); fix_nated_register(); force_rport(); }; if (!www_authorize("","subscriber")) { log(1, "authorize challenge\n"); www_challenge("","0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); log(1, "401 unauth break\n"); break; }; consume_credentials(); if (!save("location")) { sl_reply_error(); }; } # ----------------------------------------------------------------- # INVITE Message Handler # ----------------------------------------------------------------- route[3] { log(1, "Entering ROUTE[3]\n"); if (!allow_trusted()) { log(1, "Allow Trusted True\n"); if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; log(1, "Consume Credentials route 3\n"); consume_credentials(); }; if (uri=~"^sip:1[0-9]{10}@") { strip(1); }; if (nat_uac_test("19")) { setflag(6); } lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); break; }; if (uri=~"^sip:011[0-9]*@") { # International PSTN route(4); route(5); break; }; if (!lookup("location")) { log(1, "Domestic PSTN\n"); if (uri=~"^sip:[0-9]{10}@") { # Domestic PSTN route(4); route(5); break; }; sl_send_reply("404", "User Not Found"); break; }; route(4); route(1); } # ----------------------------------------------------------------- # NAT Traversal Section # ----------------------------------------------------------------- route[4] { log(1, "Entering ROUTE[4]\n"); if (isflagset(6)) { log(1, "Running NAT Traversal\n"); force_rport(); fix_nated_contact(); force_rtp_proxy(); } } # ----------------------------------------------------------------- # PSTN Handler # ----------------------------------------------------------------- route[5] { log(1, "Entering ROUTE[5]\n"); rewritehost("10.9.193.130:5060"); # INSERT YOUR PSTN GATEWAY IP ADDRESS avp_write("i:45", "inv_timeout"); log(1, "Rewrote IP for PSTN Gateway\n"); log(1, "Returning to Route 1\n"); route(1); } # ----------------------------------------------------------------- # Return Message To Sender # ----------------------------------------------------------------- onreply_route[1] { log(1, "Reached Onreply Route\n"); if (isflagset(6) && status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:[ ]*0")) { log(1, "Running Force RTP Proxy\n"); force_rtp_proxy(); }; }; if (nat_uac_test("1")) { log(1, "Fix Nated Contact\n"); fix_nated_contact(); }; } # ----------------------------------------------------------------- # End of ser.cfg # ----------------------------------------------------------------- Whew, so with all that information, the question comes down to: How do you convince rtpproxy to listen on and tell SER about the right IP addresses when there are two interfaces and you have told rtpproxy about both of them? Thanks in advance for assistance on this! Frank

16 years, 9 months

[OpenSER-Users] auth_db module problem

by Karol Krasnan

Hi, Everybody, I would like ask you for help. I am trying start OpenSer with database support. But when I uncomment, in default openser.cfg, line "loadmodule "auth_db.so"" the openser will not start. Until that it work fine. And with loading "mysql" and "auth" module is not problem. I wasn't change originnal openser.cfg. Thank you very much for help. Karol

16 years, 9 months

Re: [OpenSER-Users] [CDRTool] How to get the "In" and "Out" columns?

by Andy Smith

Hi Iñaki, For me this is functioning fine, I have just enabled the database accoutning in mediaproxy.ini and it worked as soon as I got mediaproxy working correctly... Do you know if mediaproxy is writing any data to the database? For MySQL you need SQLite and mysql_python. Also for authentication reasons the MySQL user you connect as from Mediaproxy needs to have their password set as OLD_PASSWORD (old/poor security type password) in the users table in mysql DB. cheers Andy. >Hi, my installation of CDRTool with Mediaproxy and FreeRadius works ok. I see >correctly the accounting detail in CDR's (except the fact that I have no yet >created rated, profiles and so...). >Also I see correctly the web SIP trace created with "siptrace" module. > >But in the CDR view the columns "In" and "Out" are always empty. How to fill >them? what do they depend on? I've not read nothing about them in the doc. > >Thanks a lot.

16 years, 9 months

Re: [OpenSER-Users] [CDRTool] How to get the "In" and "Out" columns?

by Andy Smith

16 years, 9 months

[OpenSER-Users] [CDRTool] How to get the "In" and "Out" columns?

by Iñaki Baz Castillo

Hi, my installation of CDRTool with Mediaproxy and FreeRadius works ok. I see correctly the accounting detail in CDR's (except the fact that I have no yet created rated, profiles and so...). Also I see correctly the web SIP trace created with "siptrace" module. But in the CDR view the columns "In" and "Out" are always empty. How to fill them? what do they depend on? I've not read nothing about them in the doc. Thanks a lot. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 9 months

Re: [OpenSER-Users] OpenSER - a slow starter?

by Bogdan-Andrei Iancu

Hi Lars, yes, correct is auto_aliases=no my typo :). Just to clarify - the problem is that openser starts very slow ? or that some requests are processed very slow?? Regards, Bogdan Lars Skjærlund wrote: > Hi Bogdan, > > >> by default openser tries to do reverse DNS lookup on the IPs you put >> > in > >> "listen" to learn all the aliases (DNS records pointing to this IP). >> >> To disable this, set the global parameter: >> auto_alias=no >> > > Beeing a beginner, the above confused me a bit - I think the right > syntax is auto_aliases=no? > > >> Let me know if this makes a difference or not. >> > > Unfortunately, no. I thought I'd solved it last night (see another mail > from me), but the problem has reappeared: > > I cannot register with Twinkle - however, Express Talk works fine? > > Well, we just did another test before hitting send: By switching IDs > between the two softphones, Twinkle registered immediately - it's > getting even more weird... > > Regards, > Lars >

16 years, 9 months

Re: [OpenSER-Users] Tech prefix and CarrierRoute

by Henning Westerholt

On Wednesday 13 February 2008, TCB wrote: > > > append the callerid as tech prefix to all outgoing calls > > changing the source code of the rewrite function in the cr module > Any pointers to which specific area of code? Hi, the actual rewrite is done in the route_func.c:actually_rewrite() function. The rewriting URI action is done in the carrier_rewrite_msg() in the same file. But why can't your billing server just evaluate the call-id header field that is probably present in the SIP message header? This would be much more easier then to hack the module code in my opinion. Henning

16 years, 9 months

← Newer
1
...
13
14
15
16
17
18
19
...
26
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 February 2008