sr-users July 2008

sr-users@lists.kamailio.org

147 participants
206 discussions

by Deepak

I am using LCR module and I have two set of gateways (group id 1 and group id 2). I have defined a list of prefixes and the corresponding gateway group id's. All is working fine vis-à-vis the prefixes and the choice of the gateway group. My problem is that if a RURI is supposed to be handled by gateways in group id 1, and all the gateways in that group are busy, the call then gets forwarded to the gateways in group id 2 although the prefix does not match to the one associated with group id 2. Is there any way to disable this so that if all gateways are busy in group id 1, SER does not forward calls to the group id 2? Thanks in advance

15 years, 9 months

[OpenSER-Users] change From display name and From URI username

by Mouncif Benniane

I am trying to change/re-write From URI username and From display name (*$fU and **$fn respectively) to avposp values*I tried: $fU = $avp(s:somevariable); avp_write("$fU","$avp(s:somevariable)"); append_hf("From-username: $avp(s:somevariable)\r\n"); but none of them works, any ideas on how to re-write those variables in SIP messages? Thank you* *

15 years, 9 months

[OpenSER-Users] [MediaProxy] If early media is longer than "idleTimeout" the RTP session is terminated

by Iñaki Baz Castillo

Hi, I use MediaProxy 1.9.1 with OpenSer. idleTimeout=50 seconds I've received an INVITE and a 183 with early media during 52 seconds and after that the 200 was received. But the RTP session in MediaProxy was terminated after 50 seconds (idleTimeout). Why? Is a still no answered call considered "idle"? This is the syslog: ----------------------------------------------- # INVITE arrives: Jul 25 15:21:17 server-sip proxydispatcher[21258]: request 9b984e5890000e3e13c4aa99fd9a69852d69d32b2614fe1cc8-0228-6667 77.14.6.152:57102:audio,77.14.6.152:41292:image 77.14.0.144 77.14.0.144 remote 192.168.10.2 remote CS2000_NGSS/9.0 info=from:882534800@77.14.0.144:5060,to:887332031@88.99.3.10:5060,fromtag:e3e-13c4-aa99fd-62c9f59e-aa99fd,totag: Jul 25 15:21:17 server-sip mediaproxy[21253]: request 9b984e5890000e3e13c4aa99fd9a69852d69d32b2614fe1cc8-0228-6667 77.14.6.152:57102:audio,77.14.6.152:41292:image 77.14.0.144 77.14.0.144 remote 192.168.10.2 remote CS2000_NGSS/9.0 info=totag:,to:887332031@88.99.3.10:5060,from:882534800@77.14.0.144:5060,fromtag:e3e-13c4-aa99fd-62c9f59e-aa99fd Jul 25 15:21:17 server-sip mediaproxy[21253]: session 9b984e5890000e3e13c4aa99fd9a69852d69d32b2614fe1cc8-0228-6667: started. listening on 88.99.3.10:61820,61822 Jul 25 15:21:17 server-sip mediaproxy[21253]: execution time: 0.92 ms Jul 25 15:21:17 server-sip proxydispatcher[21258]: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '88.99.3.10 61820 61822' # After 50 seconds the session is ended by MediaProxy: Jul 25 15:22:06 server-sip mediaproxy[21253]: session 9b984e5890000e3e13c4aa99fd9a69852d69d32b2614fe1cc8-0228-6667: 0/0/0 packets, 0/0/0 bytes (caller/called/relayed) Jul 25 15:22:06 server-sip mediaproxy[21253]: session 9b984e5890000e3e13c4aa99fd9a69852d69d32b2614fe1cc8-0228-6667: ended (did timeout). # After 2 seconds the 200 OK arrives so media fails. Jul 25 15:22:08 server-sip proxydispatcher[21258]: lookup 9b984e5890000e3e13c4aa99fd9a69852d69d32b2614fe1cc8-0228-6667 192.168.10.2:19084:audio 88.99.1.213 sip.domain.net local unknown unknown Asterisk=20testDesign info=from:882534800@sip.domain.net,to:887332031@88.99.3.10:5060,fromtag:e3e-13c4-aa99fd-62c9f59e-aa99fd,totag:as6156af6c Jul 25 15:22:08 server-sip mediaproxy[21253]: lookup 9b984e5890000e3e13c4aa99fd9a69852d69d32b2614fe1cc8-0228-6667 192.168.10.2:19084:audio 88.99.1.213 sip.domain.net local unknown unknown Asterisk=20testDesign info=totag:as6156af6c,to:887332031@88.99.3.10:5060,from:882534800@sip.domain.net,fromtag:e3e-13c4-aa99fd-62c9f59e-aa99fd Jul 25 15:22:08 server-sip mediaproxy[21253]: session 9b984e5890000e3e13c4aa99fd9a69852d69d32b2614fe1cc8-0228-6667: started. listening on 88.99.3.10:61824 Jul 25 15:22:08 server-sip mediaproxy[21253]: execution time: 0.60 ms Jul 25 15:22:08 server-sip proxydispatcher[21258]: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '88.99.3.10 61824' Jul 25 15:22:08 server-sip proxydispatcher[21258]: execution time: 1.09 ms ----------------------------------------------- -- Iñaki Baz Castillo

15 years, 9 months

[OpenSER-Users] Error with parallel forking and TCP

by Zappasodi Daniele

Hello, I have a problem with parallel forking and TCP when one connection isn't available and the inv_timeout expires. I have two clients registered with the same username and transport=TCP. If I make a call to this number when one of them is not reachable, the INVITE goes to the phone reachable, if the call timeout expires (fr_inv_timer_avp) Openser sends the CANCEL, but doesn't send anything to the caller. The failure_route doesn't hit. There is also a delay between the t_relay and the forwarding of the packet TCP on the net (around 3 seconds). The TCP packet is forwarded to the available connection only after Openser detects the failure for the closed TCP connection (the INVITE goes on the net only after the message ERROR:tm:t_forward_nonack: sending request failed). This is the trace (debug level 3, Openser version 1.3.2): Jun 25 16:30:01 SAM-IP ser[23888]: R1 t_relay R-uri: <sip:10240@10.45.10.63:2054;transport=tcp;line=zdhv6xi4> Jun 25 16:30:01 SAM-IP ser[23888]: Branch route <sip:10240@10.45.10.63:2054;transport=tcp;line=zdhv6xi4> 1 Jun 25 16:30:01 SAM-IP ser[23888]: Branch route <sip:10240@10.45.10.36:5064;transport=tcp> 2 Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:core:tcp_blocking_connect: poll error: flags 18 Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (113) No route to host Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:core:tcp_send: connect failed Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:tm:msg_send: tcp_send failed Jun 25 16:30:04 SAM-IP ser[23888]: ERROR:tm:t_forward_nonack: sending request failed Jun 25 16:30:04 SAM-IP ser[23890]: Reply Route: provision 180 - Ringing ip <10.45.10.36:33109> From <sip:10242@10.45.8.249> To <sip:10240@10.45.8.249> Jun 25 16:30:04 SAM-IP ser[23890]: ERROR:core:io_wait_loop_sigio_rt: ignoring event 41 on fd 24 (fm->fd=-1, fm->data=0x406e5488) Jun 25 16:30:04 SAM-IP ser[23900]: ERROR:core:io_wait_loop_sigio_rt: ignoring event 41 on fd 25 (fm->fd=-1, fm->data=0x406c5258) Jun 25 16:30:11 SAM-IP ser[23889]: Reply Route: 487 - <Request Terminated> ip <10.45.10.36:33110> From <sip:10242@10.45.8.249> To <sip:10240@10.45.8.249> Jun 25 16:30:11 SAM-IP ser[23890]: ERROR:core:io_wait_loop_sigio_rt: ignoring event 41 on fd 24 (fm->fd=-1, fm->data=0x406d5370) Jun 25 16:30:11 SAM-IP ser[23891]: ERROR:core:tcp_read: error reading: Connection reset by peer Jun 25 16:30:11 SAM-IP ser[23891]: ERROR:core:tcp_read_req: failed to read ********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message inerror. **********************************************************************

15 years, 9 months

[OpenSER-Users] Need openser.cfg with RLS working

by mahesh.peddi＠info-spectrum.com

Hi All, I am currently working on OpenSER-1.3.2. I want to exclude the RLS module but when I did getting some errors. Could you please send me the openser.cfg with RLS working. Regards, Mahesh Peddi Infospectrum India Pvt. Ltd. Cell: +91 9765775176 IP-Phone Ext. - 764

15 years, 9 months

[OpenSER-Users] Regarding watcher Application

by sureshkumar.jaiswal

Hi All is openseer is supporting watcher application (NDO) ~Suresh..

15 years, 9 months

[OpenSER-Users] IPv6 Destination unreachable

by Andhika Gannesha Gemilang

Trace from cilent: ============================================================================================================= 10:26:36.424197 IP6 2004::90:82.sip > 2004::90:81.sip: SIP, length: 354 `....j.@ ............... ....................jx.REGISTER sip:[2004::90:81] SIP/2.0 Via: SIP/2.0/UDP [2004::90:82]:5060;branch=z9hG4bK1206866792 From: <sip:2002@[2004::90]:81>;tag=1806361594 To: <sip:2002@[2004::90]:81> Call-ID: 1308861798@2004::90:82 CSeq: 1 REGISTER Contact: <sip:2002@[2004::90:82]:5060> Max-Forwards: 70 User-Agent: Linphone-1.7.1/eXosip Expires: 200 Content-Length: 0 10:26:36.424605 IP6 2004::90:81.sip > 2004::90:82.sip: SIP, length: 451 `......@ ............... .....................v.SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP [2004::90:82]:5060;branch=z9hG4bK1206866792;received=2004:0:0:0:0:0:90:82 From: <sip:2002@[2004::90]:81>;tag=1806361594 To: <sip:2002@[2004::90]:81>;tag=9bf42f041e5ea2673c94775a0faadb8b.8e04 Call-ID: 1308861798@2004::90:82 CSeq: 1 REGISTER WWW-Authenticate: Digest realm="[2004::90:81]", nonce="4886a61885ddea6cfa1c3e538e26b3ceffab04bf" Server: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 17:26:52.618229 IP6 2004::90:82 > 2004::90:81: ICMP6, destination unreachable, unreachable address 2004::90:82, length 507 `.....:@ ............... .................Im....`......@ ............... .......................SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP [2004::90:82]:5060;branch=z9hG4bK1206866792;received=2004:0:0:0:0:0:90:82 From: <sip:2002@[2004::90]:81>;tag=1806361594 To: <sip:2002@[2004::90]:81>;tag=9bf42f041e5ea2673c94775a0faadb8b.8e04 Call-ID: 1308861798@2004::90:82 CSeq: 1 REGISTER WWW-Authenticate: Digest realm="[2004::90:81]", nonce="4886a60c2e9e478a8c8591a61c5ca117814ea990" Server: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 ======================================================================================================== after receiving "401" challenge, the client just can't find the server. why would this happen? it works very well on the ipv4. please help me...

15 years, 9 months

[OpenSER-Users] Using OpenSER Presence & Snom

by Ross Beer

Hi, I am using the presence_xml module to provide presence across multiple clients. X-Lite, Bria works well however Snom phones produce the following error: ------------- ERROR ----------------namespace error : Namespace prefix hs on detected-state is not defined <hs:detected-state>Lunch</hs:detected-state> ^namespace error : Namespace prefix hs on device is not definedtact priority="0.000">sip:--- ADDRESS ----</contact> <hs:device ^namespace error : Namespace prefix hs on caption is not defined <hs:caption>snom370</hs:caption> ^namespace error : Namespace prefix hs on detected-state is not defined <hs:detected-state>Busy</hs:detected-state> ^namespace error : Namespace prefix hs on device is not definedtact priority="0.000">sip:--- ADDRESS ----</contact> <hs:device ^namespace error : Namespace prefix hs on caption is not defined <hs:caption>snom370</hs:caption> ^namespace error : Namespace prefix hs on detected-state is not defined <hs:detected-state>Lunch</hs:detected-state> ^namespace error : Namespace prefix hs on device is not definedtact priority="0.000">sip:--- ADDRESS ----</contact> <hs:device ^namespace error : Namespace prefix hs on caption is not defined <hs:caption>snom370</hs:caption> ^------------- END ERROR ----------------It looks like a validation issue with the XML, is there anyway you can switch off validation or update the DTD? Thanks, Ross _________________________________________________________________ Play and win great prizes with Live Search and Kung Fu Panda http://clk.atdmt.com/UKM/go/101719966/direct/01/

15 years, 9 months

[OpenSER-Users] Regarding watcher Application

by Adrian Georgescu

This is a feature of OpenXCAP, to retrieve the list of active watchers from OpenSER. It does not require any support in OpenSER. Adrian > Hi All > is openseer is supporting watcher application (NDO) > > ~Suresh.. > > what do you mean by watcher application? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

15 years, 9 months

Re: [OpenSER-Users] About openser redirect - forward

by Iñaki Baz Castillo

El Viernes, 20 de Junio de 2008, Valerio Di Marino escribió: > Thanks for your answer. Ok, but next time continue the thread in the maillist ;) > 2008/6/20 Iñaki Baz Castillo ibc(a)aliax.net: > > AFAIK if a UAC is redirected it will not include the already used > > credentials > > in the new request to the new destination (maybe I'm wrong). > > Do you think is possible to force using the pseudovariables ? No, it's not possible. When a UAAC receives a 302 it generates a completely new request with destination the URI of the "Contact" in the 302. > > If you need solving NAT in your OpenSer then you need to forward the > > request > > in it after make fix NAT. > > How ? Can explain better ? If a UAC receives a 302 it will generate a new INVITE. If the UAC has not configured your OpenSer as outbound proxy, the new INVITE it generates will go directly to the SIP provider, so it's not possible your OpenSer makes fix the NAT (fix "Contact" and so). But maybe your SIP provider makes fix the NAT by itself, or you can try STUN in your UAC's. > > If not you could use forwarding or redirect. > > With redirect, openser will send an address and the uer will contact the > new address: is it correct ? (I am not shure). Yes, OpenSer replies a 302 with the new URI in the "Contact" header. > > In OpenSer to get a redirection you must set the RURI ($ru = ...) and > > reply a > > 302 to the user. > > Can you send ma a routine syntax ? > For example, I would redirect to sip.voipstunt.com Something like: $ru = "sip.voipstunt.com"; send_reply("302", "Redirect to SIP provider"); exit; -- Iñaki Baz Castillo

15 years, 9 months

← Newer
1
...
4
5
6
7
8
9
10
...
21
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 July 2008