sr-users

sr-users@lists.kamailio.org

44 participants
37550 discussions

RE: [Users] lcr: load_gws(): from_uri to large
by Papadopoulos Georgios 08 May '07

08 May '07

Hi Juha, Exactly this is my point, 128 should work and 129 should fail, especially since all related char buffers are allocated properly with size [MAX_FROM_URI_LEN+1] I think that the bug is here: if (from_uri.len < MAX_FROM_URI_LEN) { strncpy(from_uri_str, from_uri.s, from_uri.len); from_uri_str[from_uri.len] = '\0'; } else { LOG(L_ERR, "load_gws(): from_uri to large\n"); return -1; } It should be if (from_uri.len <= MAX_FROM_URI_LEN) George > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Monday, May 07, 2007 5:44 PM > To: Papadopoulos Georgios > Cc: users(a)openser.org > Subject: [Users] lcr: load_gws(): from_uri to large > > Papadopoulos Georgios writes: > > > I get the following error from lcr module > load_gws(): > from_uri to large > This happens when the rpid is exactly > 128 characters long. If I make it > 127 long it works fine. > This is on the 1.1.x branch. Has anyone else > noticed this? > > MAX_FROM_URI_LEN constant is defined as > > > #define MAX_FROM_URI_LEN 128 > > i can change that to 256. > > -- juha > Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

2 1

[Users] 2 ENUM lookups
by Joao Pereira 08 May '07

08 May '07

Hello I would like to know how to lookup to 2 ENUM trees (arpa and e164.org). I have this config: loadmodule "enum.so" modparam("enum", "domain_suffix", "e164.org.") if ( method=="INVITE" && uri=~"sip:\+[1-9][0-9]*@mydomain.com") { if(!enum_query("e164.org.")) { log(1, "log: ENUM not found :( \n"); }else{ log(1, "log: ENUM found :) \n"); if (!method=="REGISTER") record_route(); t_relay(); return; } } Thanks Regards Joao Pereira -- ______________________________________________ João Gomes Pereira FCCN Av. do Brasil, nº 101 1700-066 Lisboa tel: +351 218 440 100 - fax: +351 218 472 167 email|SIP: joao.pereira(a)fccn.pt http://www.fccn.pt ______________________________________________ --- Aviso de Confidencialidade Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218 440 100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218 440 100 and delete it immediately. ---

3 2

Re: [Serusers] Fwd: record_route..........TCP ??
by KUMAR 07 May '07

07 May '07

Here is the message dump that i get when using TCP as transport. > > > On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote: > > I think you would have to send message dumps first so that [serusers] volunteers > > have material for providing an answer. > > > > -jiri > > > > At 12:07 03/05/2007, KUMAR wrote: > > >- > > >Hi all, > > >I already posted this message yet havent got any replies. I really > > >need to find this out. > > >Please anyone reply to this problem. > > > > > >I am using SER-0.9.6 and the problem i'm having is this. When using > > >the following ser.cfg, it works well when the transport UDP is used. > > >But when transport TCP is used, then it only results in one way IM, > > >only from the UA from which the INVITE is being sent. Moreover, when > > >record_route is used instead of record_route_preset, then even that > > >one way IM doesn't work. But it works well with UDP. > > > > > >Can anyone please point me as to where the problem might be?? > > >Thank you in advance. > > > > > >kumar > > > > > > > > >Content-Type: application/octet-stream; name=ser.cfg > > >X-Attachment-Id: f_f18sg2bl > > >Content-Disposition: attachment; filename="ser.cfg" > > > > > >_______________________________________________ > > >Serusers mailing list > > >Serusers(a)lists.iptel.org > > >http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > -- > > Jiri Kuthan http://iptel.org/~jiri/ > > > > > >

6 12

Re: [Users] Openser generated strange SIP packets with LCR Fallback on a second gateway
by gemalto-fw＠e-qual.fr 07 May '07

07 May '07

2 1

[Users] [openser 1.2] $fn, strange shape.
by Bodin Bruno 07 May '07

07 May '07

Hello, When I do : xlog("display name = $fn"); It show : display name = "toto titi" why it add quote ? how can I disable theses quotes ? thank

4 6

[Users] 183 early media and NATed clients
by Jeff Williams 07 May '07

07 May '07

Guys, I'm wondering what solutions there are to this problem. We have some NATed clients making outgoing calls. The NAT traversal is done using mediaproxy and works fine. However, we have a problem with 183 responses and early media ringing sounds. The problem is that before the NATed client starts sending out RTP data, mediaproxy doesn't know which IP and port to send the RTP traffic to. Some of the NETed clients don't start sending out RTP traffic until the call is connected, therefore none of the early media (ringing sounds) reaches the user - making it sound like dead air. Any ideas? Jeff

4 7

[Users] Openser generated strange SIP packets with LCR Fallback on a second gateway
by mailinglist-openser-users 07 May '07

07 May '07

gallois:/var/log# sudo /usr/bin/ngrep -W byline "" "port 5060" |more filter: (ip or ip6) and ( port 5060 ) # U phone:5060 -> openser:5060 INVITE sip:xxxxxxxx@sip1.e-qual.fr SIP/2.0. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. Contact: <sip:phone>. Content-Length: 221. Content-Type: application/sdp. CSeq: 1 INVITE. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. Max-Forwards: 70. Session-GUID: 875967334-858992696-842282596-875782963. Supported: 100rel. To: <sip:xxxxxxxx@sip1.e-qual.fr>. User-Agent: Quintum/1.0.0. Via: SIP/2.0/UDP phone;branch=z9hG4bK-tenor-c0a8-0843-001c. Quintum: 0c01030b0237370501001301000f0b413031322d323032334332. . v=0. o=Quintum 17 17 IN IP4 phone. s=VoipCall. c=IN IP4 phone. t=0 0. m=audio 10274 RTP/AVP 4 101. c=IN IP4 phone. a=rtpmap:4 g723/8000/1. a=ptime:30. a=rtpmap:101 telephone-event/8000/1. a=sendrecv. # U openser:5060 -> phone:5060 SIP/2.0 100 Giving a try. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. CSeq: 1 INVITE. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. To: <sip:xxxxxxxx@sip1.e-qual.fr>. Via: SIP/2.0/UDP phone;branch=z9hG4bK-tenor-c0a8-0843-001c. Server: OpenSER (1.2.0-notls (i386/linux)). Content-Length: 0. . # U openser:5060 -> gateway1:5060 INVITE sip:xxxxxxxxx@gateway1:5060;transport=udp SIP/2.0. Record-Route: <sip:openser;lr=on;ftag=c0a80843-16>. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. Contact: <sip:phone>. Content-Length: 221. Content-Type: application/sdp. CSeq: 1 INVITE. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. Max-Forwards: 69. Session-GUID: 875967334-858992696-842282596-875782963. Supported: 100rel. To: <sip:xxxxxxxx@sip1.e-qual.fr>. User-Agent: Quintum/1.0.0. Via: SIP/2.0/UDP openser;branch=z9hG4bKe7a2.b7f82867.0. Via: SIP/2.0/UDP phone;branch=z9hG4bK-tenor-c0a8-0843-001c. Quintum: 0c01030b0237370501001301000f0b413031322d323032334332. P-hint: outbound PSTN. . v=0. o=Quintum 17 17 IN IP4 phone. s=VoipCall. c=IN IP4 phone. t=0 0. m=audio 10274 RTP/AVP 4 101. c=IN IP4 phone. a=rtpmap:4 g723/8000/1. a=ptime:30. a=rtpmap:101 telephone-event/8000/1. a=sendrecv. # U gateway1:5060 -> openser:5060 SIP/2.0 488 Not acceptable here. Via: SIP/2.0/UDP openser;branch=z9hG4bKe7a2.b7f82867.0;received=openser. Via: SIP/2.0/UDP phone;branch=z9hG4bK-tenor-c0a8-0843-001c. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. To: <sip:xxxxxxxx@sip1.e-qual.fr>;tag=as714f5f56. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. CSeq: 1 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Contact: <sip:xxxxxxxxx@gateway1>. Content-Length: 0. . # U openser:5060 -> gateway1:5060 ACK sip:xxxxxxxxx@gateway1:5060;transport=udp SIP/2.0. Via: SIP/2.0/UDP openser;branch=z9hG4bKe7a2.b7f82867.0. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. To: <sip:xxxxxxxx@sip1.e-qual.fr>;tag=as714f5f56. CSeq: 1 ACK. User-Agent: OpenSER (1.2.0-notls (i386/linux)). Content-Length: 0. . # U openser:5060 -> gateway2:5060 INVITE sip:xxxxxxxx@gateway2:5060;transport=udp..t SIP/2.0. Record-Route: <sip:openser;lr=on;ftag=c0a80843-16>. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. Contact: <sip:phone>. Content-Length: 221. Content-Type: application/sdp. CSeq: 1 INVITE. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. Max-Forwards: 69. Session-GUID: 875967334-858992696-842282596-875782963. Supported: 100rel. To: <sip:xxxxxxxx@sip1.e-qual.fr>. User-Agent: Quintum/1.0.0. Via: SIP/2.0/UDP openser;branch=z9hG4bKe7a2.b7f82867.1. Via: SIP/2.0/UDP phone;branch=z9hG4bK-tenor-c0a8-0843-001c. Quintum: 0c01030b0237370501001301000f0b413031322d323032334332. P-hint: outbound PSTN. . v=0. o=Quintum 17 17 IN IP4 phone. s=VoipCall. c=IN IP4 phone. t=0 0. m=audio 10274 RTP/AVP 4 101. c=IN IP4 phone. a=rtpmap:4 g723/8000/1. a=ptime:30. a=rtpmap:101 telephone-event/8000/1. a=sendrecv. # U openser:5060 -> gateway2:5060 INVITE sip:xxxxxxxx@gateway2:5060;transport=udp..t SIP/2.0. Record-Route: <sip:openser;lr=on;ftag=c0a80843-16>. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. Contact: <sip:phone>. Content-Length: 221. Content-Type: application/sdp. CSeq: 1 INVITE. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. Max-Forwards: 69. Session-GUID: 875967334-858992696-842282596-875782963. Supported: 100rel. To: <sip:xxxxxxxx@sip1.e-qual.fr>. User-Agent: Quintum/1.0.0. Via: SIP/2.0/UDP openser;branch=z9hG4bKe7a2.b7f82867.1. Via: SIP/2.0/UDP phone;branch=z9hG4bK-tenor-c0a8-0843-001c. Quintum: 0c01030b0237370501001301000f0b413031322d323032334332. P-hint: outbound PSTN. . v=0. o=Quintum 17 17 IN IP4 phone. s=VoipCall. c=IN IP4 phone. t=0 0. m=audio 10274 RTP/AVP 4 101. c=IN IP4 phone. a=rtpmap:4 g723/8000/1. a=ptime:30. a=rtpmap:101 telephone-event/8000/1. a=sendrecv. # U openser:5060 -> gateway2:5060 INVITE sip:xxxxxxxx@gateway2:5060;transport=udp..t SIP/2.0. Record-Route: <sip:openser;lr=on;ftag=c0a80843-16>. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. Contact: <sip:phone>. Content-Length: 221. Content-Type: application/sdp. CSeq: 1 INVITE. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. Max-Forwards: 69. Session-GUID: 875967334-858992696-842282596-875782963. Supported: 100rel. To: <sip:xxxxxxxx@sip1.e-qual.fr>. User-Agent: Quintum/1.0.0. Via: SIP/2.0/UDP openser;branch=z9hG4bKe7a2.b7f82867.1. Via: SIP/2.0/UDP phone;branch=z9hG4bK-tenor-c0a8-0843-001c. Quintum: 0c01030b0237370501001301000f0b413031322d323032334332. P-hint: outbound PSTN. . v=0. o=Quintum 17 17 IN IP4 phone. s=VoipCall. c=IN IP4 phone. t=0 0. m=audio 10274 RTP/AVP 4 101. c=IN IP4 phone. a=rtpmap:4 g723/8000/1. a=ptime:30. a=rtpmap:101 telephone-event/8000/1. a=sendrecv. # U openser:5060 -> gateway2:5060 INVITE sip:xxxxxxxx@gateway2:5060;transport=udp..t SIP/2.0. Record-Route: <sip:openser;lr=on;ftag=c0a80843-16>. Call-ID: call-717C8C1D-CEDE-2910-0D00-26@phone. Contact: <sip:phone>. Content-Length: 221. Content-Type: application/sdp. CSeq: 1 INVITE. From: <sip:sip1.e-qual.fr>;tag=c0a80843-16. Max-Forwards: 69. Session-GUID: 875967334-858992696-842282596-875782963. Supported: 100rel. To: <sip:xxxxxxxx@sip1.e-qual.fr>. User-Agent: Quintum/1.0.0. Via: SIP/2.0/UDP openser;branch=z9hG4bKe7a2.b7f82867.1. Via: SIP/2.0/UDP phone;branch=z9hG4bK-tenor-c0a8-0843-001c. Quintum: 0c01030b0237370501001301000f0b413031322d323032334332. P-hint: outbound PSTN. . v=0. o=Quintum 17 17 IN IP4 phone. s=VoipCall. c=IN IP4 phone. t=0 0. m=audio 10274 RTP/AVP 4 101. c=IN IP4 phone. a=rtpmap:4 g723/8000/1. a=ptime:30. a=rtpmap:101 telephone-event/8000/1. a=sendrecv.

2 1

[Users] lcr: load_gws(): from_uri to large
by Papadopoulos Georgios 07 May '07

07 May '07

Hello all, I get the following error from lcr module load_gws(): from_uri to large This happens when the rpid is exactly 128 characters long. If I make it 127 long it works fine. This is on the 1.1.x branch. Has anyone else noticed this? thank you George Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

2 1

[Users] Openser used to route call between PSTN to/from remote voice gateways with routing different in each direction ( originate from PSTN or originate from remote voice gateway )
by mailinglist-openser-users 07 May '07

07 May '07

Version: Openser 1.2.0 Platform: PSTN <-> Central Gateways <-- OpenSer --> Remote Gateways <-- >PABX We have 4 central Voice Gateway connected to local PSTN and several tens of customer remote voice gateways connected to PABX. On our central voice gateways, we have several PSTN provider, and these providers have different prices for different location ( so calling a cell phone should be rather made by a voice gateway connected to a particular PSTN provider ). As well, we provide SDA numbers for incoming call from PSTN on our central gateway and that should be routed to a remote customer voice gateway. But if customerA call the SDA of customerB, customerA should go through PSTN by our central voice gateway and then our central voice gateway route the call to CustomerB. So all remote gateways should not know any of the SDA route, only our central gateway should use this routes. So basically we have 2 kinds of routing to be done by OpenSer: o For our Central Gateway - For SDA11, try gateway Customer1 - For SDA12, try gateway Customer1 - For SDA21, try gateway Customer2 - For SDA22, try gateway Customer2 - For any other unknown number, no gateway should be returned ( I don't want a wrong number routed to our gateway from PSTN to generate another call on PSTN ) o For our remote customer gateways, I should have routing like this: - for cell phone, try gateway 1, if that gateway1 fail then try randomly gateway 2,3 or 4 ( and if possible the less loaded of these 3 gateways ) - for spain try gateway2, if that gateway2 fail, then try randomly gateway 1,3 or 4 ( and if possible the less loaded of these 3 gateways ) - for all other routes, try randomly gateway 1,2,3,4 ( and if possible the less loaded of these 4 gateways ) So I have several constraint: - two kind of routing should be made either if the call is coming from the central gateway or from a remote customer gateway ( differenlty said: routing different if call originate from PSTN or originate from remote voice gateway ) - for customer remote gateways, there are some preferred central gateway for certains location (e.g international call ) but if these gateways fail, fallback should occur to others central gateway - the less is hardcoded in the configuration file, the better is is. - how to try first the currently less loaded gateway when several gateways are available ( is it possible in openser has it is only dialog statefull and not call statefull ? ) What is the best option in OpenSer to achieve this ? Is the LCR module with "from_uri" and route by "prefix" can handle all this ? Where can we find complex examples of the LCR module ? Regards, Jerome. -- Jerome

1 0

[Users] do I need openser FIFO?
by Joao Pereira 07 May '07

07 May '07

Hello I'm using SER/OpenSER for a long time and I always used the FIFO. My question is, do I really need to use the FIFO? What OpenSER functionalities rely in the FIFO? Just Serweb? Thanks regards Joao Pereira -- ______________________________________________ João Gomes Pereira FCCN Av. do Brasil, nº 101 1700-066 Lisboa tel: +351 218 440 100 - fax: +351 218 472 167 email|SIP: joao.pereira(a)fccn.pt http://www.fccn.pt ______________________________________________ --- Aviso de Confidencialidade Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218 440 100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218 440 100 and delete it immediately. ---

2 1

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