Re: [OpenSIPS-Users] dns name and media_relay_avp.

[Saúl Ibarra Corretgé]

Hi,

El 02/02/10 16:50, Leonid Nasedkin escribió:
> Hi there.
> Is it posible to use dns-name at media_relay_avp?
> Now I just get error:
> media-dispatcher[356]: warning: user requested media_relay
> relay-01.test.local is not available
>

No, you need to specify the IP address, as the dispatcher keeps track of 
the connected relay's IPs and it tries to match the IP in the 
media_relay_avp to that list. You're getting that error because the 
relay can't be found in that list.


Regards,


-- 
Saúl Ibarra Corretgé
AG Projects

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Starting OpenXCAP without any logs

[Saúl Ibarra Corretgé]

Hi,

El 03/02/10 5:28, CheeWii escribió:
> Havn't resloved the former problem,I got into the new trouble. The
> errors shows as follows,could you give me some suggestions? Is it the
> fault of python？？

Unfortunately the traceback doesn't show anything useful :-/ I'll try to 
reproduce your scenario (Python 2.5 and Twisted 9.0.0), so that I test 
latest Twisted with OpenXCAP. Keep you posted.


Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] priorities with opensips

[wüber]

Hello to everybody!
I'm newbie with opensips. I have a voip network with about 30 sip clients
and I use opensips as sip server.
one of this clients should have the highest priority and should be able to
speak to everybody, so all active calls should be hanged up! how can I set
the highest priority at the user?
thanks in advance. 
-- 
View this message in context: 
http://n2.nabble.com/priorities-with-opensips-tp4506066p4506066.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] call queues with opensips

[wüber]

Hi.
I'd like to set that in my voip network (using opensips as sip server) no
more than one call should be allowed. in case of multiple calls I'd like to
put them in a queue and serve one call at a time. is there the possibility
to set this feature in opensips?
thanks a lot! 
-- 
View this message in context: 
http://n2.nabble.com/call-queues-with-opensips-tp4506072p4506072.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MediaProxy as bridge between Private and Public Interfaces

[Saúl Ibarra Corretgé]

Hi,

El 03/02/10 6:38, Daniel Worrad escribió:
> Hi All,
>
> I have MediaProxy working in a multi-homed setup where it is acting as a
> relay between an interface on a public IP and one on a private IP (We
> connect to our SIP provider over a private network via the private
> interface using static routes in the route table, and a SNAT out the
> private interface)
>
> The system is functioning and calls are being relayed between public and
> private interfaces, however with every call, I am receiving the
> following in the logs (which is a bit unnerving):
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: Traceback (most recent call
> last):
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: File
> "/usr/local/lib/python2.5/site-packages/twisted/internet/udp.py", line
> 126, in doRead
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]:
> self.protocol.datagramReceived(data, addr)
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: File
> "/usr/local/lib/python2.5/site-packages/mediaproxy/mediacontrol.py",
> line 127, in datagramReceived
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: self.cb_func(host, port, data)
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: File
> "/usr/local/lib/python2.5/site-packages/mediaproxy/mediacontrol.py",
> line 203, in got_data
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]:
> self.substream.check_create_conntrack()
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: File
> "/usr/local/lib/python2.5/site-packages/mediaproxy/mediacontrol.py",
> line 253, in check_create_conntrack
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: self.forwarding_rule =
> _conntrack.ForwardingRule(self.caller.remote, self.caller.local,
> self.callee.remote, self.callee.local, self.stream.session.mark)
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: Error: No such file or directory
>
> I have tried strace to determine what file may be missing or lacking
> permissions, however there are references to hundreds of files and it is
> proving difficult to track down.
>
> Has anyone seen this before, or could suggest some other way of
> troubleshooting the issue?
>

The reason you are finding it difficult to track down the issue is 
because it's produced by the _conntrack module, which is a Python C 
extension.

At the beginning of your mail you say it's working for you, but do the 
RTP timeouts also work for you?

Please, give me some more information about your system (distro, kernel 
version, MediaProxy version)so we can see what could be happening.


Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Config Suggestions Request (SIP Trunks)

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, Mike O'Connor escribió:
> Authenticate by IP Address, yep but how ?
> 
> What is the recommend way of handling this and how do I route DID's to
>  them.

You can use "address" table ("permissions" module). Use the "grp" column to 
identify the client based on the origin IP/network.

-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] How to force opensips add port field in via header?

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, Lei Tang escribió:
> Hi Bogdan and Iñaki, Thank you every much.
> Bogdan, Could you send me the patch?


Did you try my suggestion before??

http://www.opensips.org/Resources/DocsCoreFcn15#toc25


-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] priorities with opensips

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, wüber escribió:
> Hello to everybody!
> I'm newbie with opensips. I have a voip network with about 30 sip clients
> and I use opensips as sip server.
> one of this clients should have the highest priority and should be able to
> speak to everybody, so all active calls should be hanged up! how can I set
> the highest priority at the user?
> thanks in advance.

So do you want that when such privileged makes a call all the existing calls 
must automatically end?? 


-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] call queues with opensips

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, wüber escribió:
> Hi.
> I'd like to set that in my voip network (using opensips as sip server) no
> more than one call should be allowed. in case of multiple calls I'd like to
> put them in a queue and serve one call at a time. is there the possibility
> to set this feature in opensips?

No OpenSIPS is mainly a SIP proxy. You are asking for features typically found 
in a PBX (like Asterisk).


-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] priorities with opensips

[wüber]

yes, exactly!
thanks a lot.
-- 
View this message in context: 
http://n2.nabble.com/priorities-with-opensips-tp4506066p4506277.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] priorities with opensips

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, wüber escribió:
> yes, exactly!
> thanks a lot.

AFAIK this is not possible. 


-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] call queues with opensips

[wüber]

Ok. So, I cann't put some calls in a "waiting state" if the callee is already
busy. is it right?
Can you suggest a way to do that?
Thanks a lot for your support!
-- 
View this message in context: 
http://n2.nabble.com/call-queues-with-opensips-tp4506072p4506344.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] call queues with opensips

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, wüber escribió:
> Ok. So, I cann't put some calls in a "waiting state" if the callee is
>  already busy. is it right?
> Can you suggest a way to do that?

Again OpenSIPS is mainly a SIP proxy while you are asking for PBX features.
I recommend you to use a PBX instead.

-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] number of opensips children

[Bogdan-Andrei Iancu]

Hi Brian,

The test I mentioned was done with UDP.

The messages you are seeing means that the TCP MANAGER process sees that 
all the TCP WORKER processes are already processing other messages, so 
no one is free (idle), so , it will queue the current active connection 
to one of the TCP WORKERs...
There is nothing wrong with this, it is the normal way it works - of 
course, if you have too few TCP workers, the probability to have queuing 
is higher.

In UDP the queueing is not visible at application level as it is done by 
the kernel in the receive buffer that is assigned to the socket.

In TCP the queueing is visible as there is a single TCP MANAGER process 
managing the connections (detecting the reads, connects, etc) which is 
quite fast (not doing any processing) -> the queueing is moved between 
the TCP MANAGER and TCP WORKERS.

Also, to be sure you got it right, there is no relation between the TCP 
WORKER and a connection. A TCP WORKER process is just reading and 
processing a SIP message at a certain time. Next SIP message from the 
same connection may end up in a different TCP WORKER proc.

and this has nothing to do with the tcp_persistent_flag.

Regards,
Bogdan

opensipsl...@encambio.com wrote:
> Hello Bogdan,
>
> An mer., déc  23, 2009, Bogdan-Andrei Iancu schrieb:
>   
>> opens...@encambio.com wrote:
>> 
>>> An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>>>   
 To see what processes you have and what they are doing, do:

 opensipsctl fifo ps

 
>>>   # opensipsctl fifo ps
>>>   Process::  ID=0 PID=24975 Type=attendant
>>>   Process::  ID=1 PID=24977 Type=SIP receiver udp:123.234.210.1:5060
>>>   Process::  ID=2 PID=24978 Type=time_keeper
>>>   Process::  ID=3 PID=24979 Type=timer
>>>   Process::  ID=4 PID=24980 Type=MI FIFO
>>>
>>> [...]
>>>
>>> My gut feeling is that having four UDP listening processes and four
>>> TCP listening processes is about right for us, because we only have
>>> a handful of UACs participating infrequently (5 calls per day.)
>>>   
>>>   
>> Actually that is more than needed - during some performance tests (only 
>> simply call relaying) we managed to put 6K cps in a single process.
>>
>> 
> I have eight TCP listeners configured and about sixteen UACs are
> connected. I get a ton of these warnings whenever REGISTER or INVITE
> messages come in:
>
>   Feb 02 18:17:22 name.host.tld  opensips[02126]: 
> WARNING:core:send2child: no free tcp receiver, connection passed to the 
> leastbusy one (1)
>   Feb 02 18:17:25 name.host.tld  opensips[02126]: 
> WARNING:core:send2child: no free tcp receiver, connection passed to the 
> leastbusy one (1)
>
> Because you mentioned that you benchmarked 6K CPS with a single
> process (was it TCP?), I'd like to know if you got as many warnings
> as well. One question is:
>
>   What does 'free tcp receiver' mean? I assumed that listening
>   TCP ports were free to accept as many connections as needed.
>
> By the way, each of the 16 UACs registered to the 8 TCP listener
> processes is avoiding NAT problems by keeping the TCP connection
> open by setting the tcp_persistent_flag.
>
> Is OpenSIPS expecting there to be at least one TCP listener process
> which is not encumbered by the tcp_persistent_flag?
>
> Regards,
> Brian
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] number of opensips children

[Bogdan-Andrei Iancu]

Yes, I would say the WARNING level is a bit too much for this event - A 
simple INFO or DBG should be more than enough.

I will do the change on SVN.

Regards,
Bogdan

opensipsl...@encambio.com wrote:
> Hello,
>
> An mar., févr 02, 2010, opensipsl...@encambio.com schrieb:
>   
>> An mer., déc  23, 2009, Bogdan-Andrei Iancu schrieb:
>> 
>>> opens...@encambio.com wrote:
>>>   
 An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
 My gut feeling is that having four UDP listening processes and four
 TCP listening processes is about right for us, because we only have
 a handful of UACs participating infrequently (5 calls per day.)
   
 
>>> Actually that is more than needed - during some performance tests (only 
>>> simply call relaying) we managed to put 6K cps in a single process.
>>>
>>>   
>> I have eight TCP listeners configured and about sixteen UACs are
>> connected. I get a ton of these warnings whenever REGISTER or INVITE
>> messages come in:
>>
>>  Feb 02 18:17:22 name.host.tld  opensips[02126]: 
>> WARNING:core:send2child: no free tcp receiver, connection passed to the 
>> leastbusy one (1)
>>  Feb 02 18:17:25 name.host.tld  opensips[02126]: 
>> WARNING:core:send2child: no free tcp receiver, connection passed to the 
>> leastbusy one (1)
>>
>> Because you mentioned that you benchmarked 6K CPS with a single
>> process (was it TCP?), I'd like to know if you got as many warnings
>> as well. One question is:
>>
>>  What does 'free tcp receiver' mean? I assumed that listening
>>  TCP ports were free to accept as many connections as needed.
>>
>> [...]
>>
>> Is OpenSIPS expecting there to be at least one TCP listener process
>> which is not encumbered by the tcp_persistent_flag?
>>
>> 
> At risk of answering my own question and questioning my own answer,
> I'd like to suggest the following change:
>
> --- tcp_main.c.orig   2010-01-18 12:33:49.151095000 +0100
> +++ tcp_main.c2010-02-02 20:07:15.263065567 +0100
> @@ -911,7 +911,7 @@
>   tcp_children[idx].busy++;
>   tcp_children[idx].n_reqs++;
>   if (min_busy){
> - LM_WARN("no free tcp receiver, connection passed to the least"
> + LM_INFO("no free tcp receiver, connection passed to the least "
>   "busy one (%d)\n", min_busy);
>   }
>   LM_DBG("to tcp child %d %d(%d), %p\n", idx, tcp_children[idx].proc_no,
>
> That would correct the defective english spelling 'leastbusy' as
> well as ridding the log of a properly running OpenSIPS server of
> false warnings. I'm assuming of course, that it's perfectly okay
> for TCP listener processes to keep a TCP connection open by using
> the tcp_persistent_flag and accept new SIP requests at the same
> time.
>
> Regards,
> Brian
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Private IP in registered AOR causing failure

[Bogdan-Andrei Iancu]

Hi Brian,

maybe adding some extra logging (info or notice) to print (when building 
a SUBSCRIBE) the RURI , the OBP (received) and other info to see that 
presence is doing (or not) the right job

After that you simply run it and check from time to time the logs 

What do you say ?

Regards,
Bogdan

opensipsl...@encambio.com wrote:
> Hello Bogdan,
>
> An ven., janv 29, 2010, Bogdan-Andrei Iancu schrieb:
>   
>> opensipsl...@encambio.com wrote:
>> 
 1) the BLA part is sending the SUBSCRIBEs based on user location
 and it is using the "received" field if present, so it should be
 ok. Unless you set in the bla module the "outbound" param - this
 will override the received info.

 
>>> My module parameters for presence and BLA are:
>>>
>>> modparam("presence", "server_address", "sip:p...@name.host.tld")
>>> modparam("presence_xml", "force_active", 1)
>>> modparam("pua_bla", "server_address", "sip:p...@name.host.tld")
>>> modparam("pua_bla", "default_domain", "name.host.tld")
>>> modparam("pua_bla", "header_name", "Sender")
>>>
>>> ...so I'm not setting the 'outbound' parameter it seems, right?
>>>
>>>   
>> In such a case, check in usrloc if the registrations for the user
>> the SUBSCRIBE belongs to, do has the received field - maybe the
>> error is when saving the contacts and not when using them.
>>
>> 
> That would be nice, but I don't think so:
>
>   # /pfx/sbin/opensipsctl ul show
>   AOR:: user1
> Contact:: sip:us...@192.168.0.31:3618;transport=tls;line=9hm7f0ua Q=1
>   Expires:: 352
>   Callid:: 703c26357076-zmjcebpdyaey
>   Cseq:: 1058
>   User-agent:: Unimportant
>   Received:: sip:82.90.12.232:2108;transport=TLS
>   State:: CS_SYNC
>   Flags:: 0
>   Cflag:: 64
>   Socket:: tls:62.124.111.222:5061
>   Methods:: 7999
>
>   
> After running a socket listener on 192.168.0.31 on the OpenSIPS host:
>
>$ socat TCP4-LISTEN:2310,bind=192.168.0.31,reuseaddr -
>SUBSCRIBE 
> sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm SIP/2.0
>Via: SIP/2.0/TCP 86.90.39.44;branch=G4z9hb82dK8.f144.0
>To: ;tag=ty6sjh9iz9
>From: ;tag=6c9d4319c74d756e6b696-baa1
>CSeq: 11 SUBSCRIBE
>Call-ID: b1c04118-8...@86.90.39.44
>Content-Length: 0
>User-Agent: OpenSIPS (1.6.1-tls)
>Max-Forwards: 70
>Event: dialog;sla
>Contact: 
>Expires: 610
>
>   
>>> Any ideas?
>>>   
>>>   
>> If you could try to get a capture of the whole flow - starting with
>> REGISTER, etc.plus the logs...  But first check the usrloc (see
>> 1))
>>
>> 
> I'll do that next, when I have time over the weekend. Capturing is
> actually quite difficult because everything is TLS, and there are
> more than one phone, as well as a voicemail server...
>
> Thanks for helping so far, and if you think of anything based on
> your suggestion 1) and my answer, then please advise.
>
> Thanks,
> Brian
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] high-availability - senario

[Bogdan-Andrei Iancu]

Hi Julien,

OpenSIPS does not support the 0.0.0.0 address - it is not able (due 
internal stuff) to learn new IPs on the fly (at runtime)

Regards,
Bogdan

Julien Chavanton wrote:
> This was well documented
>  
> in opensips.cfg
>  
> listen=udp:0.0.0.0:5060
>  
> or for both TCP/UDP
>  
> listen=0.0.0.0:5060
>
> 
> *From:* users-boun...@lists.opensips.org on behalf of Julien Chavanton
> *Sent:* Tue 02/02/2010 12:47 PM
> *To:* OpenSIPS users mailling list; OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] high-availability - senario
>
> I deceided not to use a loadbalancer because, the IP address for 
> outbound call would have been different and we want it to be 
> completely transparent for existing Interco.
>  
> I went with heartbeat + mon
> I created sip.monitor
>  
> When the fail over take effect it is not listening on the virtual IP, 
> how do I configure opensips to bind to 0.0.0.0:5060 ?
>
> 
> *From:* users-boun...@lists.opensips.org on behalf of Nigel Daniels
> *Sent:* Tue 26/01/2010 11:45 PM
> *To:* OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] high-availability - senario
>
>
> have you considerd using keepalived with vrrp instead ?
>
> On Tue, Jan 26, 2010 at 7:03 AM, Julien Chavanton  > wrote:
>
> I am configuring high-availability with heart-beat + LVS + ldirector
>  
> I do not want to load balance but mostly make sure it will fail
> over quickly, I have found situation where the in LVS (UDP/TCP)
> connection never timeout when the remote IP send periodic OPTIONS
> request for example.
>  
> I beleive I will have to set very low UDP/TCP time-out, however 
> with such a low time-out I can not load-balance so I will use
> weighted Round-Robin with very high priority 65535 on the active
> one and weith 1 on the passive server.
>  
> Any other suggested way to cluster without load-balancing ?
>  
>
> ___
> Users mailing list
> Users@lists.opensips.org 
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> -- 
> Nigel Daniels
> Network & Systems Administrator
> ConnectAndSell inc.
> (650)-533-2542
>
> 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] What is protocol/port mismatch?

[Bogdan-Andrei Iancu]

Hi Brian,

Regarding the crash you mentioned - do you have any backtraces ?

About some of your doubts:
1) t_relay() is not forcing any proto by itself: it preserves the 
inbound proto if the RURI (or socket) is not saying otherwise.
2) turning off the double RR may brake some things as opensips will not 
be able to properly route between the original inbound and outbound 
interfacesonly if you do it manually from the script.

To me, the solution looks like a dirty hack, but if makes Asterisk 
happywhat can I say :)

Regards,
Bogdan

opensipsl...@encambio.com wrote:
> Hello list,
>
> The problem was that the voicemail server was respecting the host
> and port of the routeset which OpenSIPS was rewriting to acommodate
> the transport change from TLS to TCP. The voicemail server was
> configured to send over TLS to the outbound proxy however, so
> traffic was arriving at OpenSIPS on the port 5060 using TLS.
>
> It's clear now why the warnings were appearing in the logs, but
> even more it seems that OpenSIPS sometimes crashes when sending
> TLS traffic to a TCP port which it is expecting clear text from.
>
> To know about the solution to this problem, read below.
>
> An ven., janv 29, 2010, opensipsl...@encambio.com schrieb:
>   
>> An ven., janv 29, 2010, Bogdan-Andrei Iancu schrieb:
>> 
>>> opensipsl...@encambio.com wrote:
>>>   
 ...and I see this in the log:

opensips[2717]: WARNING:core:get_send_socket: protocol/port 
 mismatch

 some hundreds of times per day (about once every 20 minutes
 per registered UAC.)

 I have this in the route script:

   listen = tls:name.host.tld:5061
   [...]
   t_relay("name.host.tld:5080");

 
> First, although all UAs were exchanging SIP traffic with OpenSIPS
> over TLS, t_relay was relaying the messages over UDP. I assume that
> t_relay is either hardcoded to use UDP or OpenSIPS was routing the
> messages to itself internally over UDP (to recursively resolve
> aliases.) In this case maybe t_relay implicitly uses the transport
> over which the message was last received (even internally.)
>
> In any case, the call to t_relay should look like this if relaying
> over the TCP transport is desired:
>
>   t_relay("tcp:name.host.tld:5080");
>
> The problem then is that the rr module will add two Record-Route
> headers, expecting a symetrical fashion of SIP traffic. I turned
> this off with modparam("rr", "enable_double_rr", 0) because the
> voicemail server (Asterisk) is very tricky (maybe even buggy) to
> configure to use TLS and outbound proxies.
>
> At this point I saw that traffic was arriving at OpenSIPS port 5061
> over TLS as expected, and as indicated by the routeset. The problem
> is solved.
>
>   
>> Is the basic idea of this warning message that OpenSIPS
>> exchanges a SIP message with a UA over a certain transport
>> (TLS in this case) and port number (5061 in this case), but
>> a t_relay in the route script forwards the message over a
>> different transport or to a different port number?
>>
>> 
> The basic idea of this warning message is that OpenSIPS expects
> a certain type (TLS or not TLS) of traffic at a certain TCP port
> as configured by the 'listen' directives. If a UAC sends TLS
> traffic to a port only configured to listen to plain text traffic
> then this warning will appear. What happens to the mismatched
> traffic is not clear, but I assume that it is ignored by OpenSIPS.
>
>   
>> If so, what is being compared and how is it compared?
>>
>> 
> The TCP port on which OpenSIPS listens to and the type of traffic,
> either TLS encrypted or plain text.
>
> Regards,
> Brian
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] How to force opensips add port field in via header?

[Bogdan-Andrei Iancu]

Hi Iñaki,

Well, that is for forcing a totally different port, not for forcing the 
addition of the default port. But theoretically it may work...not sure 
about the practical part :).

Regards,
Bogdan

Iñaki Baz Castillo wrote:
> El Martes, 2 de Febrero de 2010, Bogdan-Andrei Iancu escribió:
>   
>> Hi Iñaki,
>>
>> actually there is no param to force adding port to the local VIA when
>> the port is the SIP default one (just checked the code).
>> 
>
> Sure? what about "advertised_port=5060"? :)
>
> Some years ago I used it in openser 1.2 to avoid a stupid bug in a stupid 
> gateway (Nortel CS2K, the worst machine in the world).
>
>
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] How to force opensips add port field in via header?

[Bogdan-Andrei Iancu]

Hi Lei,

Indeed, that is the right place to change.

Regards,
Bogdan

Lei Tang wrote:
> Hi Bogdan,
> I tried to modify msg_translator.c, change line 1933 from
>
>   if ((send_sock->port_no!=SIP_PORT) || 
> (port_str!=&send_sock->port_no_str))
> to
>   if (1)
>
> It seem work now.
>
>
> 2010/2/3 Lei Tang mailto:lei.tl...@gmail.com>>
>
> Hi Bogdan and Iñaki, Thank you every much.
> Bogdan, Could you send me the patch? 
>
> 2010/2/2 Iñaki Baz Castillo mailto:i...@aliax.net>>
>
> El Martes, 2 de Febrero de 2010, Bogdan-Andrei Iancu escribió:
> > Hi Iñaki,
> >
> > actually there is no param to force adding port to the local
> VIA when
> > the port is the SIP default one (just checked the code).
>
> Sure? what about "advertised_port=5060"? :)
>
> Some years ago I used it in openser 1.2 to avoid a stupid bug
> in a stupid
> gateway (Nortel CS2K, the worst machine in the world).
>
>
>
> --
> Iñaki Baz Castillo mailto:i...@aliax.net>>
>
> ___
> Users mailing list
> Users@lists.opensips.org 
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> -- 
> Lei.Tang
> lei.tl...@gmail.com 
>
>
>
>
> -- 
> Lei.Tang
> lei.tl...@gmail.com 
> 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] storing and accessing dialog vals

[Bogdan-Andrei Iancu]

Hi,

When accessing the dialog context for a sequential request (like ACK, 
BYE), be sure you do it after loose_route() function - this function is 
the one matching the request to the internal dialog and exposing the 
dialog context.

Regards,
Bogdan

liuf wrote:
> I have the same problem as the topic "
> http://n2.nabble.com/storing-and-accessing-dialog-module-flags-and-vals-td3562938.html
> storing and accessing dialog module flags and vals ", I can't access any of
> the dialog vals that I set on previous messages. Am I missing something? 
>
> I've check out the newest source (20100202), and add the following based on
> the default opensips.cfg.
>
> opensips.cfg
> ==
> ..
>
> loadmodule "dialog.so"
>
> ..
>
> route{
>
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483","Too Many Hops");
> exit;
> }
>
> if (is_method("INVITE")) {
>   create_dialog();
>   store_dlg_value("test_src_ip","192.168.3.60");
>   fetch_dlg_value("test_src_ip","$var(test_src_ip_0)");   
>   xlog("### test_src_ip_0 = $var(test_src_ip_0)  ###");  # output
> 192.168.3.60
> }
>
> if (is_method("BYE")) {
>   fetch_dlg_value("test_src_ip","$var(test_src_ip_1)");
>   xlog("### test_src_ip_1 = $var(test_src_ip_1)  ###");  # output 0
> }
>
> if (has_totag()) {
> # sequential request withing a dialog should
> # take the path determined by record-routing
> if (loose_route()) {
>
> ..
>
> ==
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] How to force opensips add port field in via header?

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, Bogdan-Andrei Iancu escribió:
> Hi Iñaki,
> 
> Well, that is for forcing a totally different port, not for forcing the
> addition of the default port. But theoretically it may work...not sure
> about the practical part :).

Hi, by adding such option "advertised_port=5060" the Via header generated by 
OpenSIPS will contain the port 5060, sure. I had to use this hack and it works 
(5060 is added to Via).

Of course, when listening in different ports it could be a problem. However I 
though there were some modifications so "listen" allows such option, but not 
sure.


Regards.


-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Magnus Burman]

Nice little utility, saves alot of time on typing. :-)

Here's a pastbin with the correct format (ngrep-sip b) of the same call:
http://pastebin.ca/1776903

Thanks,
Magnus

2010/2/2 Iñaki Baz Castillo 

> El Martes, 2 de Febrero de 2010, Magnus Burman escribió:
> > I'll start capturing like that right away, less you want the pcap-file
> for
> > that specific call? Since the problem only occurs sporadically and at
> > re-invites (ie 20+ minutes into a call) it's a bit of a mess to track
> down
> > calls that fit the criteria. But I'll get right on it for sure, thanks.
>
> Try this to filter the captured data:
>
>  http://dev.sipdoc.net/projects/sip-stuff/wiki/Ngrep-SIP
>
>
> --
> Iñaki Baz Castillo 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió:
> Nice little utility, saves alot of time on typing. :-)
> 
> Here's a pastbin with the correct format (ngrep-sip b) of the same call:
> http://pastebin.ca/1776903

As you can see, the SDP in not modified by mediaproxy module for the re-INVITE 
and the 200 response for the re-INVITE. This means that you get one-way-audio 
as the caller is behind NAT.

You should inspect why you are not calling mediaproxy functions when handling 
in-dialog INVITE and its responses.


-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Saúl Ibarra Corretgé]

Hi Magnus,


El 03/02/10 12:38, Magnus Burman escribió:
> Nice little utility, saves alot of time on typing. :-)
>
> Here's a pastbin with the correct format (ngrep-sip b) of the same call:
> http://pastebin.ca/1776903
>
> Thanks,
> Magnus
>

This looks as a configuration issue to me. Have a look at the reinvite, 
when it leaves the proxy (22.22.224.9 -> 22.22.198.159) the IP in the 
SDP and Contact are not mangled (it's 11.11.0.144). You also need to 
check for NAT and mangle the SDP in that case.


Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Magnus Burman]

None of my users are behind NAT, they're all on public IPs (I control their
connection).

Sorry if it's a stupid question, but what do you mean with "the SDP is not
modified by mediaproxy"?

On line 276 in the re-invite (Opensips --> UA) the port used is different:
m=audio 40518 RTP/AVP 18 8 0 101'
The original invite (line 73) reads: m=audio 58928 RTP/AVP 18 8 0 101'

In the statistics dumped at the end, port says 58928.

This is my config in regards to mediaproxy. I included the loose_route above
as well, as this is all that comes before it in the route:

##Loose_route packets
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
if(method=="BYE") {
setflag(1);
$avp(s:can_uri) = $ru;
}
route(1);
};

if (method==INVITE && !has_totag()) {
if(avp_db_query("select 1 from subscriber_debug where username =
'$fU'", "$avp(s:debug)")) {
# No media proxy if in debug
} else {
engage_media_proxy();
}
}


2010/2/3 Iñaki Baz Castillo 

> El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió:
> > Nice little utility, saves alot of time on typing. :-)
> >
> > Here's a pastbin with the correct format (ngrep-sip b) of the same call:
> > http://pastebin.ca/1776903
>
> As you can see, the SDP in not modified by mediaproxy module for the
> re-INVITE
> and the 200 response for the re-INVITE. This means that you get
> one-way-audio
> as the caller is behind NAT.
>
> You should inspect why you are not calling mediaproxy functions when
> handling
> in-dialog INVITE and its responses.
>
>
> --
> Iñaki Baz Castillo 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió:
> None of my users are behind NAT, they're all on public IPs (I control their
> connection).

It could occur that the gateway just allows RTP from certains IP's.


> Sorry if it's a stupid question, but what do you mean with "the SDP is not
> modified by mediaproxy"?

Do you know how MediaProxy works by replacing the media IP in the SDP of 
INVITE and responses? Take a look to the first (initial) INVITE. The INVITE 
arrives to OpenSIPS with a media address XX.XX.XX.XX in the SDP, but when it 
leaves the proxy to go to the gateway the media is different because opensips 
has modified it to make it going through the MediaProxy server.

But this doesn't occur for the re-INVITE as you can see in your trace.

 
> On line 276 in the re-invite (Opensips --> UA) the port used is different:
> m=audio 40518 RTP/AVP 18 8 0 101'
> The original invite (line 73) reads: m=audio 58928 RTP/AVP 18 8 0 101'

Not just the port but also the SDP. And this occurs because the explained 
above: opensips is not replacing the ip:port in the SDP for the re-INVITE and 
its response. You should check why not.

However I don't know mediaproxy module functions very well so I don't know 
what "engage_mediaproxy" should do. I just can tell you what is happening in 
the trace.


-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] storing and accessing dialog vals

[liuf]

Thanks for your help. 

I've another question.  I can't access any of the dialog vals on reply
route. loose_route() only can be used for REQUEST_ROUTE. Am I missing
something?


opensips.cfg

=

onreply_route {

  if (status=="100")
  {
fetch_dlg_value("test_src_ip","$var(test_src_ip_100)");
xlog("# test_src_ip_100 = $var(test_src_ip_100) #");  #
output 0
  }
  else if (status=="180")
  {
fetch_dlg_value("test_src_ip","$var(test_src_ip_180)");
xlog("# test_src_ip_180 = $var(test_src_ip_180) #");  #
output 0
  }
   else if (status=="200")
  {
fetch_dlg_value("test_src_ip","$var(test_src_ip_200)");
xlog("# test_src_ip_200 = $var(test_src_ip_200) #");  #
output 0
  }
}

=
-- 
View this message in context: 
http://n2.nabble.com/storing-and-accessing-dialog-vals-tp4499104p4506962.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Magnus Burman]

Now I see what you're saying. I thought mediaproxy used the wrong port in
the re-invite, while it is in fact not engaged at all and thus the original
IP and port is sent on. That makes a lot of sense, thank you.

According to the docs the engage_media_proxy should only be called once on
the initial invite thou and after that use the dialog module to trace the
dialog. Any suggestions as how to debug where it fails? I'm not getting any
output in the syslog.

Cheers,
Magnus

2010/2/3 Iñaki Baz Castillo 

> El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió:
> > None of my users are behind NAT, they're all on public IPs (I control
> their
> > connection).
>
> It could occur that the gateway just allows RTP from certains IP's.
>
>
> > Sorry if it's a stupid question, but what do you mean with "the SDP is
> not
> > modified by mediaproxy"?
>
> Do you know how MediaProxy works by replacing the media IP in the SDP of
> INVITE and responses? Take a look to the first (initial) INVITE. The INVITE
> arrives to OpenSIPS with a media address XX.XX.XX.XX in the SDP, but when
> it
> leaves the proxy to go to the gateway the media is different because
> opensips
> has modified it to make it going through the MediaProxy server.
>
> But this doesn't occur for the re-INVITE as you can see in your trace.
>
>
> > On line 276 in the re-invite (Opensips --> UA) the port used is
> different:
> > m=audio 40518 RTP/AVP 18 8 0 101'
> > The original invite (line 73) reads: m=audio 58928 RTP/AVP 18 8 0 101'
>
> Not just the port but also the SDP. And this occurs because the explained
> above: opensips is not replacing the ip:port in the SDP for the re-INVITE
> and
> its response. You should check why not.
>
> However I don't know mediaproxy module functions very well so I don't know
> what "engage_mediaproxy" should do. I just can tell you what is happening
> in
> the trace.
>
>
> --
> Iñaki Baz Castillo 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Iñaki Baz Castillo]

El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió:
> Now I see what you're saying. I thought mediaproxy used the wrong port in
> the re-invite, while it is in fact not engaged at all and thus the original
> IP and port is sent on. That makes a lot of sense, thank you.

Yes, that's the problem.


> According to the docs the engage_media_proxy should only be called once on
> the initial invite thou and after that use the dialog module to trace the
> dialog. Any suggestions as how to debug where it fails? I'm not getting any
> output in the syslog.

As I said I don't know mediaproxy module very well as I just used the old one 
(some years ago).



-- 
Iñaki Baz Castillo 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] B2BUA(top hiding) leads to segmentation fault

[Anca Vamanu]

Hi Franz,

Please update to svn branch, it contains a much stable version of b2b.

Regards,

-- 
Anca Vamanu
www.voice-system.ro



Franz Edler wrote:
> Hi,
>
> I observed the following behaviour with B2BUA(top hiding scenario):
>
> Whenever the ringing phase lasts e few seconds longer a segmentation fault
> is issued.
> Below is the backtrace of three such cases of Segmentation fault (core
> dumped):
>
> (gdb) bt
> #0  0x080e1003 in fm_malloc (qm=0xb5781000, size=288) at mem/f_malloc.c:172
> #1  0xb78e0431 in b2b_dlg_copy (dlg=0xbfdbf0d0) at
> ../tm/../../mem/shm_mem.h:202
> #2  0xb78e4103 in b2b_new_dlg (msg=0x81b7df4, on_reply=1) at dlg.c:670
> #3  0xb78e507a in b2b_tm_cback (htable=0xb590d284, ps=0xb798a0b4) at
> dlg.c:1351
> #4  0xb78ddf1b in b2b_client_tm_cback (t=0xb59194c4, type=1024,
> ps=0xb798a0b4) at client.c:44
> #5  0xb796570b in run_trans_callbacks (type=1024, trans=0xb59194c4, req=0x0,
> rpl=0x81b7df4, code=180) at t_hooks.c:208
> #6  0xb797bd29 in local_reply (t=0xb59194c4, p_msg=0x81b7df4, branch=0,
> msg_status=180, cancel_bitmap=0xbfdbf460) at t_reply.c:1333
> #7  0xb797d211 in reply_received (p_msg=0x81b7df4) at t_reply.c:1484
> #8  0x08068ca3 in forward_reply (msg=0x81b7df4) at forward.c:559
> #9  0x08099796 in receive_msg (
> buf=0x818a4c0 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP
> 10.0.0.5;branch=z9hG4bK165f.1c0d4de2.0\r\nContact:
> \r\nTo:
> ;tag=0170bb0b\r\nFrom:
> ;tag=7ff38bb96eae"..., len=339, rcv_info=0xbfdbf584) at
> receive.c:200
> #10 0x080daee4 in udp_rcv_loop () at udp_server.c:492
> #11 0x0806ff66 in main (argc=3, argv=0xbfdbf724) at main.c:711
>
> (gdb) bt
> #0  0x080e1003 in fm_malloc (qm=0xb575e000, size=24) at mem/f_malloc.c:172
> #1  0xb7941dd2 in insert_tmcb (cb_list=0xb58f73e8, types=1536, f=0xb78c37a0
> , param=0xb58f5024,
> release_func=0xb78bc917 ) at ../../mem/shm_mem.h:202
> #2  0xb795b33c in t_uac (method=0xbf87c534, headers=0xbf87c448, body=0x0,
> dialog=0x81b7f0c, cb=0xb78c37a0 , cbp=0xb58f5024,
> release_func=0xb78bc917 ) at uac.c:252
> #3  0xb795cace in req_within (method=0xbf87c534, headers=0xbf87c448,
> body=0x0, dialog=0x81b7f0c, completion_cb=0xb78c37a0 ,
> cbp=0xb58f5024, release_func=0xb78bc917 ) at uac.c:390
> #4  0xb78c02ac in b2b_send_request (et=B2B_SERVER, b2b_key=0xb58f626c,
> method=0xbf87c534, extra_headers=0x0, body=0x0) at dlg.c:1054
> #5  0xb78b26be in b2b_logic_notify (src=1, msg=0x81b7998, key=0xbf87c6d8,
> type=0, param=0xb58f2f00) at logic.c:711
> #6  0xb78b4343 in b2b_client_notify (msg=0x81b7998, key=0xbf87c6d8, type=0,
> param=0xb58f2f00) at logic.c:938
> #7  0xb78bec93 in b2b_prescript_f (msg=0x81b7998, uparam=0x0) at dlg.c:455
> #8  0x080aedca in exec_pre_req_cb (msg=0x81b7998) at script_cb.c:155
> #9  0x08099570 in receive_msg (
> buf=0x818a4c0 "BYE sip:s...@10.0.0.5:5060 SIP/2.0\r\nVia: SIP/2.0/UDP
> 10.0.0.1:11026;branch=z9hG4bK-d8754z-d3d94b4bafce1803-1---d8754z-\r\nMax-For
> wards: 70\r\nContact: \r\nTo:
> ;tag"..., len=434, rcv_info=0xbf87c7c4) at
> receive.c:156
> #10 0x080daee4 in udp_rcv_loop () at udp_server.c:492
> #11 0x0806ff66 in main (argc=3, argv=0xbf87c964) at main.c:711
>
> (gdb) bt
> #0  0x080e1003 in fm_malloc (qm=0xb5715000, size=112) at mem/f_malloc.c:172
> #1  0xb7864ca1 in b2bl_create_new_entity (type=B2B_CLIENT,
> entity_id=0x81b8aa0, to_uri=0xbfc79414, from_uri=0xbfc7940c, ssid=0x0) at
> ../../mem/shm_mem.h:202
> #2  0xb7865cbf in create_top_hiding_entities (msg=0x81b7998,
> to_uri=0xbfc79414, from_uri=0xbfc7940c) at logic.c:1043
> #3  0xb786812e in b2b_init_request (msg=0x81b7998, arg1=0x0, arg2=0x0,
> arg3=0x0, arg4=0x0, arg5=0x0, arg6=0x0) at logic.c:1205
> #4  0x080577e9 in do_action (a=0x81b4570, msg=0x81b7998) at action.c:967
> #5  0x0805668e in run_action_list (a=0x81b4570, msg=0x81b7998) at
> action.c:139
> #6  0x080596e5 in do_action (a=0x81b4648, msg=0x81b7998) at action.c:706
> #7  0x0805668e in run_action_list (a=0x81b4100, msg=0x81b7998) at
> action.c:139
> #8  0x08059b47 in do_action (a=0x81b4a00, msg=0x81b7998) at action.c:712
> #9  0x0805668e in run_action_list (a=0x81b4a00, msg=0x81b7998) at
> action.c:139
> #10 0x08059b47 in do_action (a=0x81b4a6c, msg=0x81b7998) at action.c:712
> #11 0x0805668e in run_action_list (a=0x81b3700, msg=0x81b7998) at
> action.c:139
> #12 0x080596e5 in do_action (a=0x81b4dc0, msg=0x81b7998) at action.c:706
> #13 0x0805668e in run_action_list (a=0x81b1ed0, msg=0x81b7998) at
> action.c:139
> #14 0x0805a663 in run_top_route (a=0x81b1ed0, msg=0x81b7998) at action.c:119
> #15 0x080996e3 in receive_msg (
> buf=0x818a4c0 "INVITE sip:b...@net1.test SIP/2.0\r\nVia: SIP/2.0/UDP
> 10.0.0.1:9570;branch=z9hG4bK-d8754z-1d2b253308357a1c-1---d8754z-\r\nMax-Forw
> ards: 69\r\nContact: \r\nTo:
> \"sip:b...@ne"..., len=800, rcv_info=0xbfc7a004) at receive.c:162
> #16 0x080daee4 in udp_rcv_loop () at udp_server.c:492
> #17 0x0806ff66 in main (argc=3, argv=0xbfc7a1a4) at main.c:711
>
>
> I hope that helps to clarify the issue.
>
> Regards
> Franz
>
>
>
> 

Re: [OpenSIPS-Users] storing and accessing dialog vals

[liuf]

Thanks for your help.

I've got it. Now I can access the dialog vals on request route and reply
route. Thanks.


-- 
View this message in context: 
http://n2.nabble.com/storing-and-accessing-dialog-vals-tp4499104p4507368.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Starting OpenXCAP without any logs

[CheeWii]

Thanks a lot !

Looking forward to your reply kindly~ : )

2010/2/3 Saúl Ibarra Corretgé 

> Hi,
>
> El 03/02/10 5:28, CheeWii escribió:
> > Havn't resloved the former problem,I got into the new trouble. The
> > errors shows as follows,could you give me some suggestions? Is it the
> > fault of python？？
>
> Unfortunately the traceback doesn't show anything useful :-/ I'll try to
> reproduce your scenario (Python 2.5 and Twisted 9.0.0), so that I test
> latest Twisted with OpenXCAP. Keep you posted.
>
>
> Regards,
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Magnus Burman]

Thank you for your help Iñaki, it's much appreciated.

By asking my last question I was hoping someone else might chime in. :-)

Best Regards,
Magnus

2010/2/3 Iñaki Baz Castillo 

> El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió:
> > Now I see what you're saying. I thought mediaproxy used the wrong port in
> > the re-invite, while it is in fact not engaged at all and thus the
> original
> > IP and port is sent on. That makes a lot of sense, thank you.
>
> Yes, that's the problem.
>
>
> > According to the docs the engage_media_proxy should only be called once
> on
> > the initial invite thou and after that use the dialog module to trace the
> > dialog. Any suggestions as how to debug where it fails? I'm not getting
> any
> > output in the syslog.
>
> As I said I don't know mediaproxy module very well as I just used the old
> one
> (some years ago).
>
>
>
> --
> Iñaki Baz Castillo 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Saúl Ibarra Corretgé]

Hi,

El 03/02/10 14:43, Magnus Burman escribió:
> Now I see what you're saying. I thought mediaproxy used the wrong port
> in the re-invite, while it is in fact not engaged at all and thus the
> original IP and port is sent on. That makes a lot of sense, thank you.
>
> According to the docs the engage_media_proxy should only be called once
> on the initial invite thou and after that use the dialog module to trace
> the dialog. Any suggestions as how to debug where it fails? I'm not
> getting any output in the syslog.
>

You are correct, the by calling engage_mediaproxy the dialog module 
should take care. However, it's surprising that this only happens 
sometimes, so it's harder to debug :( Is the syslog you pasted in your 
earlier mail the only output you get for that call? Any warning from the 
dialog module?



Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] number of opensips children

[opensipslist]

Hello Bogdan,

An mer., févr 03, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> I have eight TCP listeners configured and about sixteen UACs are
>> connected. I get a ton of these warnings whenever REGISTER or INVITE
>> messages come in:
>>
>>   Feb 02 18:17:22 name.host.tld  opensips[02126]: 
>> WARNING:core:send2child: no free tcp receiver, connection passed to the 
>> leastbusy one (1)
>>   Feb 02 18:17:25 name.host.tld  opensips[02126]: 
>> WARNING:core:send2child: no free tcp receiver, connection passed to the 
>> leastbusy one (1)
>>
>Also, to be sure you got it right, there is no relation between the
>TCP WORKER and a connection. A TCP WORKER process is just reading
>and processing a SIP message at a certain time. Next SIP message
>from the same connection may end up in a different TCP WORKER proc.
>
>and this has nothing to do with the tcp_persistent_flag.
>
But what can be the reason that 8 TCP worker processes are unable to
be idle enough to serve 16 UACs? The UACs are sending REGISTER and
SUBSCRIBE messages every 5 minutes only, and hardly any INVITES are
being made. It would seem that even a single TCP worker process
should be able to serve the 16 UACs exchanging little traffic no?

Regards,
Brian

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] What is protocol/port mismatch?

[opensipslist]

Hello Bogdan,

An mer., févr 03, 2010, Bogdan-Andrei Iancu schrieb:
>Regarding the crash you mentioned - do you have any backtraces ?
>
There's quite a lot of situations in which OpenSIPS crashes, so
I'm not sure this one is related to TLS traffic arriving on a non
TLS port. In any case, here's the last backtrace:

$ gdb /pfx/sbin/opensips opensips.17272.name.host.tld.core 
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.11"...
(no debugging symbols found)
Cannot access memory at address 0x70795464
(gdb) bt
#0  0x0810eefc in fm_realloc ()
#1  0xd0d8cc8c in ?? ()
#2  0x080465a8 in ?? ()
#3  0xd0d859d4 in ?? ()
#4  0x08353c2c in mem_pool ()
#5  0x0191 in ?? ()
#6  0x08046640 in ?? ()
#7  0x in ?? ()
#8  0x in ?? ()
#9  0x080467d8 in ?? ()
#10 0x08046638 in ?? ()
#11 0x0812437e in parse_min_se ()
#12 0x083132e0 in mem_pool ()
#13 0x in ?? ()
#14 0x81af694b in ?? ()
#15 0xd0d8c6fc in ?? ()
#16 0x0001 in ?? ()
#17 0x08353c2c in mem_pool ()
#18 0xce43365d in ?? ()
#19 0x080467c4 in ?? ()
#20 0x0804678c in ?? ()
#21 0x08353f9c in mem_pool ()
#22 0x08046640 in ?? ()
#23 0x08353f9c in mem_pool ()
#24 0x0073 in ?? ()
#25 0x082ff8e8 in ?? ()
#26 0xd13dbbe9 in ?? ()
#27 0x0002 in ?? ()
#28 0x082ff8f0 in ?? ()
#29 0x3332 in ?? ()
#30 0x in ?? ()
(gdb)

$ pstack opensips.17272.name.host.tld.core core 
'opensips.17272.name.host.tld.core' of 17272:/pfx/sbin/opensips -P 
/pfx/var/opensips/opensips.pid
 0810eefc fm_realloc (0, 80467cc, 0, 80467d8, d10f, 8354104) + 4bc
 d1011537 dlg_validate_dialog (8353c2c, ce4334b0, 8046a38, d101459b, ce4334b0, 
8323390) + 290
 d10035ba w_validate_dialog (8353c2c, 0, 0, 0, 0, 0) + 2a
 08076240 do_action (8323390, 8353c2c, 7275652e, 8046c00, 8046bf0, 0) + 15a5
 08079877 run_action_list (8323390, 8353c2c, 844f7c8, 844f735, 83132ba, 13) + 
281
 080d03a7 eval_expr (83233fc, 8353c2c, 0, 0, 313c5, 1) + 46a
 080d014a eval_expr (8323428, 8353c2c, 0, 0, 0, 0) + 20d
 080d0019 eval_expr (8323454, 8353c2c, 0, d0ff18b3, 0, 8354890) + dc
 080d0172 eval_expr (8323480, 8353c2c, 0, 8354700, 8354a2c, 27) + 235
 0807643d do_action (83238cc, 8353c2c, 40, 82b1c50, 80472d4, 80472d4) + 17a2
 08079877 run_action_list (83238cc, 8353c2c, 0, 81aaf92, 82b1c50, ce4350a8) + 
281
 08078381 do_action (832536c, 8353c2c, ce415b0d, d0dadd84, ce433690, ce415b08) 
+ 36e6
 08079877 run_action_list (832536c, 8353c2c, 0, 0, 0, 0) + 281
 08078381 do_action (8325654, 8353c2c, ce415790, 0, 8353c30, 1) + 36e6
 08079877 run_action_list (832108c, 8353c2c, d106ea15, 8344074, 8353c2c, 0) + 
281
 08079c50 get_bl_head_by_name (832108c, 8353c2c, 8353c2c, 80478f0, 308, 
8353c2c) + f3
 080be5aa receive_msg (ce415808, 308, ce4157a0, 80478d4, ce375d9c, 2) + 5ac
 080f4cf4 tcp_read_req (ce415790, 8047978, d11d10c5, d11bfa64, 17, ce375d4c) + 
18c
 080f687d  (b, d001, 8047ac4, d06e7e60, d06e9ae0, 831a84c)
 080f77a4 tcp_receive_loop (c, 2, 0, 8047b10, 9, 0) + 94b
 080ed6f8 tcp_send (82cb1f4, 138a, 83178e8, 805f130, d1169cc8, 8047c5c) + 4b
 08091d47 main (80749c0, 3, 8047bdc) + 3bab
 080749c0 do_assign (3, 8047cc4, 8047cd8, 8047cdb, 0, 8047cfb) + d0

$ pflags opensips.17272.name.host.tld.core
core 'opensips.17272.name.host.tld.core' of 17272:/pfx/sbin/opensips -P 
/pfx/var/opensips/opensips.pid
data model = _ILP32  flags = ORPHAN|MSACCT|MSFORK
 /1:flags = 0
sigmask = 0xbefc,0x  cursig = SIGSEGV

>1) t_relay() is not forcing any proto by itself: it preserves the 
>inbound proto if the RURI (or socket) is not saying otherwise.
>
Okay, then I assume the t_relay() tried sending TLS traffic to
the voicemail server, could not negotiate a TLS connection, and
so resent the message over UDP instead. Is that right? Does
t_relay() choose UDP instead of TCP when its first choice (the
preserved inbound proto) cannot be used?

>2) turning off the double RR may brake some things as opensips will
>not be able to properly route between the original inbound and
>outbound interfaces... only if you do it manually from the script.
>
I've configured OpenSIPS to listen on only one interface, so I guess
that I'm not affected by this breakage. Next I'll try to solve the
problem another way without disabling double Record-Route headers.

>To me, the solution looks like a dirty hack, but if makes Asterisk
>happy... what can I say :)
>
Now that I know more I'll try to solve it another way.

Regards,
Brian

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Does Opensips Presence Support Content Indirection in PIDF ?

[mani sivaraman]

Could any one please let me know if opensips support CID (content
indirection) in PIDF PUBLISH and NOTIFY ?. Is there any configuration to be
done to enable if it is available ?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MediaProxy as bridge between Private and Public Interfaces

[Daniel Worrad]

Hi Saúl,

Thanks for your help, as you suggested, it doesn't look like the rtp timeouts 
are working. I am running CentOS kernel 2.6.18-92.el5, with the following 
component versions:

gnutls-2.4.1
python-application-1.2.1
libnetfilter_conntrack-0.0.101
mediaproxy-2.3.10
mediaproxy-2.3.10
python-cjson-1.0.5
Twisted-9.0.0
confuse-2.6
kamailio-1.5.3-notls
python-gnutls-1.1.9
confuse-2.6
pyrad-1.1
conntrack-tools-0.9.13
libgcrypt-1.4.5
libnfnetlink-1.0.0
Python-2.5.2
zope.interface-3.3.0
libnfnetlink-1.0.0

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
Private Subnet  0.0.0.0 255.255.255.240 U 0  00 eth1
Provider Proxy  Private Next Hop255.255.255.240 UG0  00 eth1
Provider Proxy  Private Next Hop255.255.255.240 UG0  00 eth1
Provider Proxy  Private Next Hop255.255.255.224 UG0  00 eth1
Public Subnet   0.0.0.0 255.255.255.0   U 0  00 eth0
0.0.0.0 Public GW   0.0.0.0 UG0  00 eth0

eth0  Public Interface
eth1  Private Interface

Using the following IPTables command (otherwise all the packets for the 
Provider Proxies get routed out the private interface with a public source IP:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 

Recieving the error w/ firewall turned off as well. 


As you suspected, UDP timeouts don't seem to be working. There is nothing about 
sessions timing

-Original Message-
From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Saúl Ibarra Corretgé
Sent: Wednesday, 3 February 2010 7:41 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] MediaProxy as bridge between Private and Public 
Interfaces

Hi,

El 03/02/10 6:38, Daniel Worrad escribió:
> Hi All,
>
> I have MediaProxy working in a multi-homed setup where it is acting as a
> relay between an interface on a public IP and one on a private IP (We
> connect to our SIP provider over a private network via the private
> interface using static routes in the route table, and a SNAT out the
> private interface)
>
> The system is functioning and calls are being relayed between public and
> private interfaces, however with every call, I am receiving the
> following in the logs (which is a bit unnerving):
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: Traceback (most recent call
> last):
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: File
> "/usr/local/lib/python2.5/site-packages/twisted/internet/udp.py", line
> 126, in doRead
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]:
> self.protocol.datagramReceived(data, addr)
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: File
> "/usr/local/lib/python2.5/site-packages/mediaproxy/mediacontrol.py",
> line 127, in datagramReceived
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: self.cb_func(host, port, data)
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: File
> "/usr/local/lib/python2.5/site-packages/mediaproxy/mediacontrol.py",
> line 203, in got_data
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]:
> self.substream.check_create_conntrack()
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: File
> "/usr/local/lib/python2.5/site-packages/mediaproxy/mediacontrol.py",
> line 253, in check_create_conntrack
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: self.forwarding_rule =
> _conntrack.ForwardingRule(self.caller.remote, self.caller.local,
> self.callee.remote, self.callee.local, self.stream.session.mark)
>
> Feb 3 15:19:32 SIPProxy1 media-relay[6806]: Error: No such file or directory
>
> I have tried strace to determine what file may be missing or lacking
> permissions, however there are references to hundreds of files and it is
> proving difficult to track down.
>
> Has anyone seen this before, or could suggest some other way of
> troubleshooting the issue?
>

The reason you are finding it difficult to track down the issue is 
because it's produced by the _conntrack module, which is a Python C 
extension.

At the beginning of your mail you say it's working for you, but do the 
RTP timeouts also work for you?

Please, give me some more information about your system (distro, kernel 
version, MediaProxy version)so we can see what could be happening.


Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay() not relaying payload

[Thamer Alharbash]

Hi Bogdan,

Sorry for not getting back sooner. I've updated my config a bit. I'm  
including what our reinvite handling looks like and the two reinvites  
that pass through opensips. The second one as you can see has no  
payload (ngrep shows ...) I have verified this as well under wireshark.

if (has_totag()) {

 # sequential request within a dialog should
 # take the path determined by record-routing

 if (loose_route()) {

 if (is_method("BYE")) {
 setflag(1); # do accounting ...
 setflag(3); # ... even if the  
transaction fails

 } else if (is_method("INVITE")) {
 # even if in most of the cases is  
useless, do RR for
 # re-INVITEs also, as some buggy  
clients do change route set
 # during the dialog.
 record_route_preset 
("proxy.ip.address.here");
 }
 # route it out to whatever destination was  
set by loose_route()
 # in $du (destination URI).
 route(1);
...
route[1] {
 # for INVITEs enable some additional helper routes
 if (is_method("INVITE")) {
 t_on_branch("1");
 t_on_reply("1");
 t_on_failure("1");
 if(has_body("application/sdp")) {
 rtpproxy_offer("frc","proxy.ip.address.here");
 xlog ("Setting rtpproxy_offer");
 }
 if (isbflagset(6)) {
 fix_nated_contact();
 }

 }




-- FIRST REINVITE

U carrier.ip.address.here:5060 -> our.proxy.ip.address:5060
INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone SIP/ 
2.0.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
From: ;tag=SD1ko0299-324092c7 
+1+ad440023+8233f214.
To: "Thamer Al-Harbash" ;tag=83134be1983195b6.
CSeq: 878247939 INVITE.
Expires: 180.
Min-SE: 1800.
Session-Expires: 1800;refresher=uac.
Supported: 100rel,timer.
Max-Forwards: 69.
Contact: .
Content-Type: application/sdp.
Content-Length: 216.
Route: .
.
v=0.
o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
s=-.
c=IN IP4 carrier.ip.address.here.
t=0 0.
m=audio 10044 RTP/AVP 0 101.
a=sendrecv.
a=ptime:20.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.


U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
From: ;tag=SD1ko0299-324092c7 
+1+ad440023+8233f214.
To: "Thamer Al-Harbash" ;tag=83134be1983195b6.
CSeq: 878247939 INVITE.
Server: OpenSIPS (1.6.0-notls (i386/linux)).
Content-Length: 0.
.

U our.proxy.ip.address:5060 -> uac.ip.address.here:5060
INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone SIP/ 
2.0.
Record-Route: .
Via: SIP/2.0/UDP our.proxy.ip.address;branch=z9hG4bK20d7.90192965.0.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
From: ;tag=SD1ko0299-324092c7 
+1+ad440023+8233f214.
To: "Thamer Al-Harbash" ;tag=83134be1983195b6.
CSeq: 878247939 INVITE.
Expires: 180.
Min-SE: 1800.
Session-Expires: 1800;refresher=uac.
Supported: 100rel,timer.
Max-Forwards: 68.
Contact: .
Content-Type: application/sdp.
Content-Length: 217.
.
v=0.
o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
s=-.
c=IN IP4 our.proxy.ip.address.
t=0 0.
m=audio 32104 RTP/AVP 0 101.
a=sendrecv.
a=ptime:20.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.

-- SECOND REINVITE

U carrier.ip.address.here:5060 -> our.proxy.ip.address:5060
INVITE sip:1...@192.168.2.12:5060;transport=udp;user=phone SIP/2.0.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0020.1.
Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
From: ;tag=SD1ko0299-324092c7 
+1+ad440023+8233f214.
To: "Thamer Al-Harbash" ;tag=83134be1983195b6.
CSeq: 878247940 INVITE.
Expires: 180.
Min-SE: 1800.
Session-Expires: 1800;refresher=uac.
Supported: 100rel,timer.
Max-Forwards: 69.
Contact: .
Content-Type: application/sdp.
Content-Length: 216.
Route: .
.
v=0.
o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
s=-.
c=IN IP4 carrier.ip.address.here.
t=0 0.
m=audio 10044 RTP/AVP 0 101.
a=sendrecv.
a=ptime:20.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.


U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0

Re: [OpenSIPS-Users] Quota system problem

[Pedersen R.]

For now,
I add quota on opensips.subscriber table;
I just change in opensips.cfg this case 1 part:

switch ($retcode) {
case 2:
# Call with no limit
xlog("L_INFO", "Call control: no limit\n");
case 1:
# Call with a limit under callcontrol management (either prepaid
or postpaid)
xlog("L_INFO", "Call control: limit under
callcontrol management \n");
if (db_is_user_in("From","quota")) {
sl_send_reply("403", "Call denied. Monthly Quota is
spent.");
xlog("L_INFO","Quota atteint");
exit;
} else {
xlog("L_INFO","Quota pas encore atteint");
}
break;

But the opensips.grp table is still empty, same for cdrtool.quota_usage
table.
Why the quotaCheck.php cron is not doing his job?


On Tue, Feb 2, 2010 at 11:53 PM, osiris123d  wrote:

>
> Haven't worked with Quota yet, but perhaps this will get you started down
> the
> right path
>
> Look at the "bye_on_timeout_flag" modparam in Dialog module
>
> http://www.opensips.org/html/docs/modules/devel/dialog.html#bye-on-timeout-flag-id
>
>
> Heard about the "bye_on_timeout_flag" on this post
> http://lists.opensips.org/pipermail/users/2008-October/001116.html
> --
> View this message in context:
> http://n2.nabble.com/Quota-system-problem-tp4502804p4503572.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



-- 
Peers
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users