sr-users

sr-users@lists.kamailio.org

37 participants
37511 discussions

[Users] rtpproxy still not working for me
by Ronald Wiplinger 28 Sep '06

28 Sep '06

Status: openser compiled, including mysql openser working with mysql (registering) openser server has two ethernet ports with one public and one private IP rtpproxy is running without any parameter 7311 is eyebeam on local desktop 7312 is gizmo on the same local desktop 7111 is a grandstream remote, behind a nat Openser adminstrator shows all three phones as registered with following sip addresses: sip:7111@192.168.10.91 sip:7311@192.168.250.108:42800;rinstance=f17a00051f63a625 sip:17476063396@proxy01.sipphone.com:5060 <=== that should be 7312(a)192.168.250.108 Internal calls: call from 7312 to 7311 works. call from 7311 to 7312 ends up at a voicemail box (most likely gizmo problem) call from 7311 to 17476063396(a)proxy01.sipphone.com ends up at the voicemail box External calls: call from 7311 (local phone) 7111 (remote phone behind NAT) does not work, see the ngrep info below. Looking at the output I feel that the nathelper is not working. As I understand the documents, the address should be replaced with an public IP address, but it uses my servers internal ethernet port (192.168.250.41) 5.32.86.166 in alt1 is the IP address of my Hamachi network. I have no idea, why this one shows up here. # U 2006/09/28 08:56:06.482374 192.168.250.108:42800 -> 192.168.250.41:5060 INVITE sip:7111@192.168.250.41 SIP/2.0. Via: SIP/2.0/UDP 192.168.250.108:42800;branch=z9hG4bK-d87543-a177451df022e84f-1--d87543-;rport. Max-Forwards: 70. Contact: <sip:7311@192.168.250.108:42800>. To: "7111"<sip:7111@192.168.250.41>. From: "Ronald-taipei @ video "<sip:7311@192.168.250.41>;tag=13766900. Call-ID: ZGIzNjlhYmIwODBmOTAzMDJiMDU1Zjc0ZTZhNDM0MzE.. CSeq: 1 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. User-Agent: eyeBeam release 1005g stamp 32576. Content-Length: 809. . v=0. o=- 0 2 IN IP4 192.168.250.108. s=CounterPath eyeBeam 1.5. c=IN IP4 192.168.250.108. t=0 0. m=audio 59382 RTP/AVP 107 100 106 6 0 105 18 3 5 101. a=alt:1 2 : eE24SyNT p1rs0KkA 5.32.86.166 59382. a=alt:2 1 : eKP8Z+Ou +E2ejbdN 192.168.250.108 59382. a=fmtp:18 annexb=yes. a=fmtp:101 0-15. a=rtpmap:107 BV32/16000. a=rtpmap:100 SPEEX/16000. a=rtpmap:106 SPEEX-FEC/16000. a=rtpmap:105 SPEEX-FEC/8000. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=sendrecv. a=x-rtp-session-id:B8DA69C497FC40B2AACE87E3E86D914A. m=video 46168 RTP/AVP 125. a=alt:1 2 : Ac/XN/Nt wQExOeCB 5.32.86.166 46168. a=alt:2 1 : ZKv1sx6w JY5CEQdN 192.168.250.108 46168. a=fmtp:125 profile-level-id=42e015; max-br=4000; max-mbps=19800. a=rtpmap:125 H264/90000. a=sendrecv. a=x-rtp-session-id:AD24C300DC234CCFA115E5F0B36CDEAB. # U 2006/09/28 08:56:06.483471 192.168.250.41:5060 -> 192.168.250.108:42800 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.250.108:42800;branch=z9hG4bK-d87543-a177451df022e84f-1--d87543-;rport=42800. To: "7111"<sip:7111@192.168.250.41>. From: "Ronald-taipei @ video "<sip:7311@192.168.250.41>;tag=13766900. Call-ID: ZGIzNjlhYmIwODBmOTAzMDJiMDU1Zjc0ZTZhNDM0MzE.. CSeq: 1 INVITE. Server: OpenSer (1.1.0-notls (x86_64/linux)). Content-Length: 0. Warning: 392 192.168.250.41:5060 "Noisy feedback tells: pid=8787 req_src_ip=192.168.250.108 req_src_port=42800 in_uri=sip:7111@192.168.250.41 out_uri=sip:7111@192.168.10.91 via_cnt==1". . # U 2006/09/28 08:56:30.829647 192.168.250.108:42800 -> 192.168.250.41:5060 . . # U 2006/09/28 08:56:36.004956 192.168.250.41:5060 -> 192.168.250.108:42800 SIP/2.0 408 Request Timeout. Via: SIP/2.0/UDP 192.168.250.108:42800;branch=z9hG4bK-d87543-a177451df022e84f-1--d87543-;rport=42800. To: "7111"<sip:7111@192.168.250.41>;tag=fa997f81440371de71ab448ebdb9af56-1877. From: "Ronald-taipei @ video "<sip:7311@192.168.250.41>;tag=13766900. Call-ID: ZGIzNjlhYmIwODBmOTAzMDJiMDU1Zjc0ZTZhNDM0MzE.. CSeq: 1 INVITE. Server: OpenSer (1.1.0-notls (x86_64/linux)). Content-Length: 0. Warning: 392 192.168.250.41:5060 "Noisy feedback tells: pid=8791 req_src_ip=192.168.250.108 req_src_port=42800 in_uri=sip:7111@192.168.250.41 out_uri=sip:7111@192.168.10.91 via_cnt==0". . # /var/log/messages shows: Sep 28 09:00:27 taipei /usr/local/sbin/openser[8787]: ERROR: force_rtp_proxy2: no available proxies Sep 28 09:00:40 taipei /usr/local/sbin/openser[8787]: ERROR: unforce_rtp_proxy: no available proxies Sep 28 09:00:40 taipei /usr/local/sbin/openser[8787]: ERROR: unforce_rtp_proxy: no available proxies Where is my mistake? bye Ronald

2 1

[Users] proxy authorization required sent to the wrong port
by Benko 28 Sep '06

28 Sep '06

Hello! I've tried to modify my setup to use rtpproxy, following the guide posted at http://siprouter.onsip.org/doc/gettingstarted/, most of it works fine, but i have a small but annoying problem: When i receive a invite from a UA, i verify the identity with proxy_authorize. However, the proxy-authenticate-request is not sent to the originating sip-port of the UA but to 5060 for some reason. In my old setup this worked flawless, the proxy authorize request is sent to the correct external port of the phone. To me it seems there is no difference in this part of the route-plan, so how does this happen? I have attached both config-files and a ngrep of the requests(*.old is the working setup, *.rtpproxy is the new setup that doesn't work), maybe someone can help me with this? Thanks in advance! Regards Christian

2 3

Re: [Users] OPENSER 1.1.0 equivalent version for SER
by Bogdan-Andrei Iancu 28 Sep '06

28 Sep '06

Hi Bill, Bill Zhang wrote: > Hi, > > I just sew the new face of www.iptel.org <http://www.iptel.org/> and > see they start to move things forward now. Got some questions about > SER versus OPENSER: > > 1. What is the OPENSER 1.1.0 equivalent version for SER? 0.10.x or > 0.9.x? Is there a lot of difference? > OpenSER 1.1.0 is the latest stable release. AFAIK, last stable release for SER is 0.9.x for more than one year ago.... ..yes there are a lot of differences... > 1. SER has a SEMS server, does OPENSER has something equivalent? > SEMS can be also used with OpenSER > > 1. When will OPENSER have the new Presence module? I know it’s > soon, but how soon? > in a matter of weeks - are you interested in testing it? Regards, Bogdan

1 0

[Users] Openser Administrator misses /var/log/openser
by Ronald Wiplinger 28 Sep '06

28 Sep '06

Openser Administrator says: No such file or directory - /var/log/openser - I agree with that! Where do I set it? tail /var/log/messages Sep 27 19:59:41 taipei /usr/local/sbin/openser[13042]: ERROR:registrar:update_contacts: invalid cseq for aor <7111> Sep 27 19:59:41 taipei /usr/local/sbin/openser[13044]: ERROR:registrar:update_contacts: invalid cseq for aor <7211> Sep 27 19:59:44 taipei /usr/local/sbin/openser[13044]: ERROR:registrar:update_contacts: invalid cseq for aor <7111> Sep 27 19:59:47 taipei /usr/local/sbin/openser[13044]: ERROR:registrar:update_contacts: invalid cseq for aor <7211> Sep 27 19:59:50 taipei /usr/local/sbin/openser[13042]: ERROR:registrar:update_contacts: invalid cseq for aor <7111> Sep 27 19:59:59 taipei /usr/local/sbin/openser[13044]: ERROR:registrar:update_contacts: invalid cseq for aor <7113> Sep 27 19:59:59 taipei /usr/local/sbin/openser[13042]: ERROR:registrar:update_contacts: invalid cseq for aor <7211> Sep 27 20:00:02 taipei /usr/local/sbin/openser[13044]: ERROR:registrar:update_contacts: invalid cseq for aor <7111> Sep 27 20:00:03 taipei /usr/local/sbin/openser[13042]: ERROR:registrar:update_contacts: invalid cseq for aor <7113> Sep 27 20:00:07 taipei /usr/local/sbin/openser[13044]: ERROR:registrar:update_contacts: invalid cseq for aor <7113> BTW, what do these error messages mean? bye Ronald

2 1

[Users] t_on_failure does not work for me
by Jeremie Le Hen 28 Sep '06

28 Sep '06

Hi list, my configuration file contains the following block: % if (is_method("INVITE")){ % force_rtp_proxy(""); % t_on_failure("1"); % append_hf("P-hint: RTP session ports reserved by rtpproxy\r\n"); % }; If I dump the SIP dialog on the network, I can indeed see the "P-hint" header. Then, the configuration file contains: % failure_route[1] { % if (!(status == "407")) { % unforce_rtp_proxy(); % append_hf("P-hint: RTP session dropped\r\n"); % } else { % append_hf("P-hint: Proxy authentication required, don't drop RTP session\r\n"); % } % } Unfortunately, when a 407 reply code comes back from the registrar, the outgoing SIP packet doesn't have any "P-hint" header. I didn't manage to test the other cases, unfortunately. Did I miss something in the configuration file ? Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >

2 3

RE: [Serusers] Implementing call fwd
by Kamal.Mann＠t-systems.com 28 Sep '06

28 Sep '06

Hi all Please help out ________________________________ From: Mann, Kamal Sent: Tuesday, September 26, 2006 5:46 PM To: 'serusers(a)lists.iptel.org' Subject: RE: [Serusers] Implementing call fwd Hi all I am implementing Blind call forwarding with 0.9.6 SER version. But with current configuration it's not working. Please help on same. I am enclosing small part of usr_prefrences table & my ser.cfg.

3 6

Re: [Serusers] Implementing call fwd
by Greger V. Teigre 28 Sep '06

28 Sep '06

Please copy the list. It depends on what you want to achieve. Blind forwarding is to me the following: - Check if this is a local user (myself) - Check if this is an alias (lookup("aliases")) - Check if the AOR is registered (lookup("location")) - Check if the user has blind call forwarding - If no, relay to looked up location - If yes, rewrite ruri. (Then what you do depends on your setup complexity, either you forward to PSTN, so just rewrite to GW and relay, or you allow recursive forwarding. Then you need to either relay to yourself or call a route that runs the above described process. Or simpler, you can do as you do by duplicating the lookups, now with the new ruri. Then you allow only one step of forwarding, not recursive.) g-) Kamal.Mann(a)t-systems.com wrote: > > I think so, because we need to check is r-uri (to which call get > forwarded) is registered or not. > > I am newbie if anything wrong please suggests me. > > > > Thanks in anticipation > > Kamal Mann > > ** ** > > *From:* Greger V. Teigre [mailto:greger@teigre.com] > *Sent:* Wednesday, September 27, 2006 8:19 PM > *To:* Mann, Kamal > *Cc:* serusers(a)lists.iptel.org > *Subject:* Re: [Serusers] Implementing call fwd > > > > You do lookup("aliases") and lookup("location") AFTER you have changed > the uri through avp_pushto from usr_preferences. > Is this really what you want? > g-) > > Kamal.Mann(a)t-systems.com <mailto:Kamal.Mann@t-systems.com> wrote: > > > Hi All > I want to setup Blind call forwarding. Like if a uri - mann(a)iptel.org <mailto:mann@iptel.org> > is not registered with SER but this user had already configured in ser > database table usr_prefrences that his call should be forwarde to > another uri kamal(a)iptel.org <mailto:kamal@iptel.org>. For that my usr_prefrence table is like > > > >> USR_PREFRENCES table >> >> +------+----------+-----------+-----------+---------------------+------ >> > + > >> ---------------+ >> >> | uuid | username | domain | attribute | value | type >> > | > >> modified | >> >> +------+----------+-----------+-----------+---------------------+------ >> > + > >> ----------------+ >> >> | | bhaskar | debian | callfwd | kamal(a)iptel.org <mailto:kamal@iptel.org> >> | 0 | 20060926165852 | >> >> | | mann | iptel.org | callfwd | sip:kamal@iptel.org <mailto:sip:kamal@iptel.org> | 0 >> > | > >> 20060926150443 | >> >> | | prateek | iptel.org | callfwd | kamal(a)iptel.org <mailto:kamal@iptel.org> | 0 >> > | > >> 20060926170701 | >> >> +------+----------+-----------+-----------+---------------------+------ >> > + > >> ----------------+ >> > > > Is this entry is correct?? Is there any flaw in my ser.cfg?? > Any help would be appreciated. > Regards > Kamal Mann > -----Original Message----- > From: Steve Blair [mailto:blairs@isc.upenn.edu] > Sent: Wednesday, September 27, 2006 2:26 PM > To: Mann, Kamal > Cc: serusers(a)lists.iptel.org <mailto:serusers@lists.iptel.org> > Subject: Re: [Serusers] Implementing call fwd > > > > Does your config file relay REFER messages? It needs to in order to > perform the transfer. > > Kamal.Mann(a)t-systems.com <mailto:Kamal.Mann@t-systems.com> wrote: > > >> Hi all >> >> Please help out >> >> >> > ------------------------------------------------------------------------ > >> *From:* Mann, Kamal >> *Sent:* Tuesday, September 26, 2006 5:46 PM >> *To:* 'serusers(a)lists.iptel.org <mailto:serusers@lists.iptel.org>' >> *Subject:* RE: [Serusers] Implementing call fwd >> >> Hi all >> >> I am implementing Blind call forwarding with 0.9.6 SER version. But >> with current configuration it's not working. Please help on same. >> >> I am enclosing small part of usr_prefrences table & my ser.cfg. >> >> ----------------------------------------------------------------------- >> > - > >> _______________________________________________ >> Serusers mailing list >> Serusers(a)lists.iptel.org <mailto:Serusers@lists.iptel.org> >> http://lists.iptel.org/mailman/listinfo/serusers >> >> >> > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org <mailto:Serusers@lists.iptel.org> > http://lists.iptel.org/mailman/listinfo/serusers > > >

1 0

[Users] Mediaproxy / proxydispatcher: couldn't retrieve DNS SRV record
by kjcsb 28 Sep '06

28 Sep '06

I am getting the following error in the log file: Sep 28 06:24:25 beta proxydispatcher[24129]: error: couldn't retrieve DNS SRV record '_mediaproxy._tcp.domain.co.nz': (111, 'Connection refused') However I think the DNS records are OK. dig SRV _mediaproxy._tcp.domain.co.nz ; <<>> DiG 9.2.3 <<>> SRV _mediaproxy._tcp.domain.co.nz ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63894 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;_mediaproxy._tcp.domain.co.nz. IN SRV ;; ANSWER SECTION: _mediaproxy._tcp.domain.co.nz. 86100 IN SRV 0 100 25060 c-mp-03.domain.co.nz. _mediaproxy._tcp.domain.co.nz. 86100 IN SRV 10 50 25060 c-mp-01.domain.co.nz. _mediaproxy._tcp.domain.co.nz. 86100 IN SRV 10 50 25060 c-mp-02.domain.co.nz. ;; AUTHORITY SECTION: domain.co.nz. 258929 IN NS ns2.widge.net. domain.co.nz. 258929 IN NS ns1.widge.net. ;; ADDITIONAL SECTION: c-mp-03.domain.co.nz. 86129 IN A 60.234.nnn.nnn ns1.widge.net. 170576 IN A 82.165.160.211 ns2.widge.net. 170576 IN A 82.165.163.115 ;; Query time: 83 msec ;; SERVER: 64.62.196.100#53(64.62.196.100) ;; WHEN: Thu Sep 28 06:28:07 2006 ;; MSG SIZE rcvd: 276 On the target server (c-mp-03.domain.co.nz) there's something getting through to to mediaproxy as shown in the log file: Sep 28 06:26:21 domain01 mediaproxy[16128]: command status Sep 28 06:26:21 domain01 mediaproxy[16128]: command execution time: 0.54 ms Sep 28 06:26:41 domain01 mediaproxy[16128]: command status Sep 28 06:26:41 domain01 mediaproxy[16128]: command execution time: 0.55 ms Could anyone advise how to resolve this issue? Regards Cameron

2 1

[Serusers] unhandled SIP state transition
by jorain 28 Sep '06

28 Sep '06

Hi all, When i call from pstn to sip phone, and hang up it before someone pick up the sip phone, then my sems will show this error and immediately end the sems. Error: changeSIPState(IsdnCall.cpp:339):unhandled SIP state transition(inbound) from (DISCONNECTED|DISCONNECTED) to (CONNECTED|DISCONNECTED) What could be the problem? Any help is appreciated. Thanks Regards, jorain

1 0

[Users] OPENSER 1.1.0 equivalent version for SER
by Bill Zhang 27 Sep '06

27 Sep '06

Hi, I just sew the new face of www.iptel.org <http://www.iptel.org/> and see they start to move things forward now. Got some questions about SER versus OPENSER: 1. What is the OPENSER 1.1.0 equivalent version for SER? 0.10.x or 0.9.x? Is there a lot of difference? 2. SER has a SEMS server, does OPENSER has something equivalent? 3. When will OPENSER have the new Presence module? I know it's soon, but how soon? Thanks in advance. Best Regards, Bill

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