Re: [OpenSIPS-Users] uac_replace_from

[dcomms]

GOT IT thanks

$si

-- 
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Re-uac-replace-from-tp4977465p4977872.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] uac_replace_from

[dcomms]

Thanks that worked. 

How can i match a range of incoming IP address
Gradually getting to grips with opensips

 
-- 
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Re-uac-replace-from-tp4977465p4977719.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] uac_replace_from

[Antonio Anderson Souza]

The best way is to use the uac module.

Calling the function uac_replace_from before the relay, follow a script
snippet bellow:

uac_replace_from("sip:2...@10.10.1.100 ")

Best regards,

Antonio Anderson M. Souza
Voice Technology
http://www.antonioams.com

Em 28/04/2010 20:19, "dcomms" escreveu:


HI,


Whats the best way to do this? i have asterisk configured with
fromuser=22

 xlog("$fu \n")  shows sip:222...@10.10.1.100


I want to change to
sip:111...@10.10.1.100before relay

Even better can someone show me how to change $fu for any ip address
10.10.1.100

thanks

--
View this message in context:
http://opensips-open-sip-server.1449251.n2.nabble.com/uac-replace-from-tp4977451p4977451.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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] uac_replace_from

[dcomms]

HI,


Whats the best way to do this? i have asterisk configured with 
fromuser=22
 
 xlog("$fu \n")  shows sip:222...@10.10.1.100
 

I want to change to sip:111...@10.10.1.100 before relay

Even better can someone show me how to change $fu for any ip address
10.10.1.100

thanks

-- 
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/uac-replace-from-tp4977451p4977451.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] Modify Script variable

[dcomms]

HI,


Whats the best way to do this? i have asterisk configured with 
fromuser=22
 
 xlog("$fu \n")  shows sip:222...@10.10.1.100
 

I want to change to sip:111...@10.10.1.100 before relay

Even better can someone show me how to change $fu for any ip address
10.10.1.100

thanks

-- 
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Modify-Script-variable-tp4977436p4977436.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] OpenSIPS-Users] takes ages to register

[Andy Thomas]

Heres some traces-

This is my first softphone, takes 3 attempts to register, and a total of 24
seconds to complete:


U 2010/04/28 20:45:25.685389 79.121.180.192:38670 -> 92.63.137.209:5060
REGISTER sip:voipexpress.co.uk SIP/2.0.
Via: SIP/2.0/UDP 192.168.10.13:5070;rport;branch=z9hG4bK04640.
Max-Forwards: 20.
To: .
From: ;tag=2359.
Call-ID: 1272483910-4640-andy-h...@192.168.10.13.
CSeq: 2 REGISTER.
Contact: ;expires=3600;q=0.90.
User-Agent: NCH Software Express Talk 4.03.
Content-Length: 0.
.

#
U 2010/04/28 20:45:25.687274 92.63.137.209:5060 -> 79.121.180.192:38670
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP
192.168.10.13:5070;rport=38670;branch=z9hG4bK04640;received=79.121.180.192.
To:
;tag=c97b4d1cb1f3d0da549e06a8d482ef63.a93d.
From: ;tag=2359.
Call-ID: 1272483910-4640-andy-h...@192.168.10.13.
CSeq: 2 REGISTER.
WWW-Authenticate: Digest realm="voipexpress.co.uk",
nonce="4bd89073000b75de71bff18e6f3b1b75ea9d026629f1".
Server: OpenSIPS (1.6.2-notls (i386/linux)).
Content-Length: 0.
.

#
U 2010/04/28 20:45:37.683605 79.121.180.192:38670 -> 92.63.137.209:5060
REGISTER sip:voipexpress.co.uk SIP/2.0.
Via: SIP/2.0/UDP 192.168.10.13:5070;rport;branch=z9hG4bK14640.
Max-Forwards: 20.
To: .
From: ;tag=2359.
Call-ID: 1272483910-4640-andy-h...@192.168.10.13.
CSeq: 3 REGISTER.
Contact: ;expires=3600;q=0.90.
User-Agent: NCH Software Express Talk 4.03.
Content-Length: 0.
.

#
U 2010/04/28 20:45:37.684962 92.63.137.209:5060 -> 79.121.180.192:38670
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP
192.168.10.13:5070;rport=38670;branch=z9hG4bK14640;received=79.121.180.192.
To:
;tag=c97b4d1cb1f3d0da549e06a8d482ef63.ed8d.
From: ;tag=2359.
Call-ID: 1272483910-4640-andy-h...@192.168.10.13.
CSeq: 3 REGISTER.
WWW-Authenticate: Digest realm="voipexpress.co.uk",
nonce="4bd8907f000c3e962a906408586f31fdad8586892592".
Server: OpenSIPS (1.6.2-notls (i386/linux)).
Content-Length: 0.
.

#
U 2010/04/28 20:45:49.683648 79.121.180.192:38670 -> 92.63.137.209:5060
REGISTER sip:voipexpress.co.uk SIP/2.0.
Via: SIP/2.0/UDP 192.168.10.13:5070;rport;branch=z9hG4bK24640.
Max-Forwards: 20.
To: .
From: ;tag=2359.
Call-ID: 1272483910-4640-andy-h...@192.168.10.13.
CSeq: 4 REGISTER.
Contact: ;expires=3600;q=0.90.
Authorization: Digest
username="testuser1",realm="voipexpress.co.uk",nonce="4bd89073000b75de71
bff18e6f3b1b75ea9d026629f1",uri="sip:voipexpress.co.uk",response="d2dbbfb5e7
36286471256c963873be96",opaque="",algorithm=MD5.
User-Agent: NCH Software Express Talk 4.03.
Content-Length: 0.
.

#
U 2010/04/28 20:45:49.687049 92.63.137.209:5060 -> 79.121.180.192:38670
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.10.13:5070;rport=38670;branch=z9hG4bK24640;received=79.121.180.192.
To:
;tag=c97b4d1cb1f3d0da549e06a8d482ef63.215c.
From: ;tag=2359.
Call-ID: 1272483910-4640-andy-h...@192.168.10.13.
CSeq: 4 REGISTER.
Contact: ;q=0.9;expires=321,
;q=0.9;expires=3600.
Server: OpenSIPS (1.6.2-notls (i386/linux)).
Content-Length: 0.
..



Here's one using X-lite (takes 30 seconds to register):

U 2010/04/28 21:42:29.777132 79.121.180.192:38672 -> 92.63.137.209:5060
REGISTER sip:voipexpress.co.uk SIP/2.0.
Via: SIP/2.0/UDP
192.168.10.13:5072;branch=z9hG4bK-d8754z-664c4957b5641f55-1---d8754z-;rport.
Max-Forwards: 70.
Contact: .
To: "testuser2".
From: "testuser2";tag=9d01cb20.
Call-ID: NTBlZmM2MWM0NGUxZDhiNWExN2E3MzhjOWZkMTU1ZmI..
CSeq: 1 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO.
User-Agent: X-Lite release 1104o stamp 56125.
Content-Length: 0.
.

#
U 2010/04/28 21:42:29.778904 92.63.137.209:5060 -> 79.121.180.192:38672
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP
192.168.10.13:5072;branch=z9hG4bK-d8754z-664c4957b5641f55-1---d8754z-;rport=
38672;received=79.121.180.192.
To:
"testuser2";tag=c97b4d1cb1f3d0da549e06a8d48
2ef63.8145.
From: "testuser2";tag=9d01cb20.
Call-ID: NTBlZmM2MWM0NGUxZDhiNWExN2E3MzhjOWZkMTU1ZmI..
CSeq: 1 REGISTER.
WWW-Authenticate: Digest realm="voipexpress.co.uk",
nonce="4bd89dd3004e370b6dcc60ce56bc6659bd99bd333eca".
Server: OpenSIPS (1.6.2-notls (i386/linux)).
Content-Length: 0.
.

#
U 2010/04/28 21:42:59.771090 79.121.180.192:38672 -> 92.63.137.209:5060
REGISTER sip:voipexpress.co.uk SIP/2.0.
Via: SIP/2.0/UDP
192.168.10.13:5072;branch=z9hG4bK-d8754z-f827ad1654460f24-1---d8754z-;rport.
Max-Forwards: 70.
Contact: .
To: "testuser2".
From: "testuser2";tag=9d01cb20.
Call-ID: NTBlZmM2MWM0NGUxZDhiNWExN2E3MzhjOWZkMTU1ZmI..
CSeq: 2 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO.
User-Agent: X-Lite release 1104o stamp 56125.
Authorization: Digest
username="testuser2",realm="voipexpress.co.uk",nonce="4bd89dd3004e370b6d
cc60ce56bc6659bd99bd333eca",uri="sip:voipexpress.co.uk",response="2e89db5a0c
796236d36cd4c2914f34c6",algorithm=MD5.
Content-Length: 0.
.

#
U 2010/04/28 21:42:59.773982 92.63.137.209:5060 -> 79.121.180.192:38672
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.10.13:5072;branch=z9hG4bK-d8754z

Re: [OpenSIPS-Users] OpenSIPS and Virtual IP implementation

[rajib deka]

Thank you very much Max. Its working now.
Cheers
Rajib

On Wed, Apr 28, 2010 at 10:06 PM, Max Mühlbronner  wrote:

> Hi,
>
> we are running a very similar setup, failover via virtual ips. There is
> an option which allows you to bind opensips to this ip.
>
> *|echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
>
> |*
>
> /proc/sys/net/ipv4/ip_nonlocal_bind
>
>Set this if you want your applications to be able to bind to an
>address which doesn't belong to a device on your system. This can be
>useful when your machine is on a non-permanent (or even dynamic)
>link, so your services are able to start up and bind to a specific
>address when your link is down.
>
> *|Next, you would just need to add the listen lines in Opensips to bind to
> this virtual ip, opensips will bind to this virtual ip even if it is not yet
> available on the system. Should be working great. Hope this helps.
>
>
> Max M.
> |*
>
>
> rajib deka schrieb:
> > Hi List,
> >
> > I have implemented Virtual IP based failover for our OpenSIPS linux
> > cluster. The logic is our two OpenSIPS server will share a same
> > Virtual IP, initially master server will be up with the virtual IP and
> > once the master is down the back up OpenSIPS will take over the
> > Virtual IP. The issue I am facing here is after uping and arping the
> > Virtul IP with eth0 interface (irrespective of master or backup), when
> > I restart OpenSIPS to bind the TCP/UDP ports to Virtual IP OpenSIPS
> > takes more than expected time to start again (restarting). What may be
> > the cause for this? Is there any solution for this? But once OpenSIPS
> > is up it works fine with Virtual IP, also if I restart OpenSIPS only
> > with the physical IP it restarts quickly.
> >
> > --
> > Rajib Deka
> > Software Engineer
> > Servion Global Solution
> > Chennai, India
> >
> > Mobile No: + 91 80157 09130
> > 
> >
> > ___
> > 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
>



-- 
Rajib Deka
Software Engineer
Servion Global Solution
Chennai, India

Mobile No: + 91 80157 09130
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSIPS-Users] takes ages to register

[Ovidiu Sas]

Please keep the mailing list in copy.  Private e-mails will go unanswered.
Can you post a trace of an X-lite trying to register?

Regards,
Ovidiu Sas

On Wed, Apr 28, 2010 at 2:42 PM, Andy Thomas  wrote:
> I AM experiencing the exact same issue with Xlite
> And also if I try and register an Asterisk SIP trunk to the opensips server
> too!
> These are in different locations with different internet connections, so the
> opensips server is the only common thing.
>
> Regards
> Andy
>
>
> -Original Message-
> From: sip.n...@gmail.com [mailto:sip.n...@gmail.com] On Behalf Of Ovidiu Sas
> Sent: 27 April 2010 11:24 PM
> To: Andy Thomas
> Cc: users@lists.opensips.org users
> Subject: Re: [OpenSIPS-Users] OpenSIPS-Users] takes ages to register
>
> Here's my first reply to your initial post:
> http://lists.opensips.org/pipermail/users/2010-April/012300.html
>
> I doubt that you are experiencing the same issue with x-lite.
>
> One thing that you can try is to let opensips to reuse the noce in the
> authentication process:
> http://www.opensips.org/html/docs/modules/devel/auth.html#id228317
> Maybe this will make your SIP UA happy.
>
>
> Regards,
> Ovidiu Sas
>
>
> On Tue, Apr 27, 2010 at 3:54 PM, Andy Thomas  wrote:
>> I never got your first email.
>> It wasn’t in the digest either!
>>
>> I have tried several sip client softphones, including x-lite
>> All of them give the same problem!
>>
>>
>>
>> -Original Message-
>> From: sip.n...@gmail.com [mailto:sip.n...@gmail.com] On Behalf Of Ovidiu
> Sas
>> Sent: 27 April 2010 8:14 PM
>> To: OpenSIPS users mailling list; Andy Thomas
>> Subject: Re: [OpenSIPS-Users] OpenSIPS-Users] takes ages to register
>>
>> As I pointed out in a previous e-mail, the issue is with your client:
>> it should send out the second REGISTER with an Authorization header.
>> Please read the answers that you get before re-posting the same thing
>> again and again.
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Tue, Apr 27, 2010 at 2:47 PM, Andy Thomas 
> wrote:
>>>
>>> Here's a -W trace, I always get 2 unauthorised then 1 authorised OK.
>>> There is a 30-second time span from start to end.
>>>
>>>
>>> #
>>> U 79.121.180.192:38670 -> 92.63.137.209:5060
>>> REGISTER sip:voipexpress.co.uk SIP/2.0.
>>> Via: SIP/2.0/UDP 79.121.180.192:38670;rport;branch=z9hG4bK03148.
>>> Max-Forwards: 20.
>>> To: .
>>> From: ;tag=8625.
>>> Call-ID: 1272311050-3148-andy-h...@192.168.10.13.
>>> CSeq: 2 REGISTER.
>>> Contact: ;expires=3600;q=0.90.
>>> User-Agent: NCH Software Express Talk 4.02.
>>> Content-Length: 0.
>>> .
>>>
>>> #
>>> U 92.63.137.209:5060 -> 79.121.180.192:38670
>>> SIP/2.0 401 Unauthorized.
>>> Via: SIP/2.0/UDP 79.121.180.192:38670;rport=38670;branch=z9hG4bK03148.
>>> To:
>>
> ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.7533.
>>> From: ;tag=8625.
>>> Call-ID: 1272311050-3148-andy-h...@192.168.10.13.
>>> CSeq: 2 REGISTER.
>>> WWW-Authenticate: Digest realm="voipexpress.co.uk",
>> nonce="4bd5ed34000e265ef8398de58d485e50f061b83fcbc0".
>>> Server: OpenSIPS (1.6.2-notls (i386/linux)).
>>> Content-Length: 0.
>>> .
>>>
>>> #
>>> U 79.121.180.192:38670 -> 92.63.137.209:5060
>>> REGISTER sip:voipexpress.co.uk SIP/2.0.
>>> Via: SIP/2.0/UDP 79.121.180.192:38670;rport;branch=z9hG4bK13148.
>>> Max-Forwards: 20.
>>> To: .
>>> From: ;tag=8625.
>>> Call-ID: 1272311050-3148-andy-h...@192.168.10.13.
>>> CSeq: 3 REGISTER.
>>> Contact: ;expires=3600;q=0.90.
>>> User-Agent: NCH Software Express Talk 4.02.
>>> Content-Length: 0.
>>> .
>>>
>>> #
>>> U 92.63.137.209:5060 -> 79.121.180.192:38670
>>> SIP/2.0 401 Unauthorized.
>>> Via: SIP/2.0/UDP 79.121.180.192:38670;rport=38670;branch=z9hG4bK13148.
>>> To:
>>
> ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.3183.
>>> From: ;tag=8625.
>>> Call-ID: 1272311050-3148-andy-h...@192.168.10.13.
>>> CSeq: 3 REGISTER.
>>> WWW-Authenticate: Digest realm="voipexpress.co.uk",
>> nonce="4bd5ed4f2ca92e41b130e201700f7e8517ac933c".
>>> Server: OpenSIPS (1.6.2-notls (i386/linux)).
>>> Content-Length: 0.
>>> .
>>>
>>> #
>>> U 79.121.180.192:38670 -> 92.63.137.209:5060
>>> REGISTER sip:voipexpress.co.uk SIP/2.0.
>>> Via: SIP/2.0/UDP 79.121.180.192:38670;rport;branch=z9hG4bK23148.
>>> Max-Forwards: 20.
>>> To: .
>>> From: ;tag=8625.
>>> Call-ID: 1272311050-3148-andy-h...@192.168.10.13.
>>> CSeq: 4 REGISTER.
>>> Contact: ;expires=3600;q=0.90.
>>> Authorization: Digest
>>
> username="testuser1",realm="voipexpress.co.uk",nonce="4bd5ed34000e265ef8
>>
> 398de58d485e50f061b83fcbc0",uri="sip:voipexpress.co.uk",response="4cb47c6109
>> bce14b54359f285d763017",opaque="",algorithm=MD5.
>>> User-Agent: NCH Software Express Talk 4.02.
>>> Content-Length: 0.
>>> .
>>>
>>> #
>>> U 92.63.137.209:5060 -> 79.121.180.192:38670
>>> SIP/2.0 200 OK.
>>> Via: SIP/2.0/UDP 79.121.180.192:38670;rport=38670;branch=z9hG4bK23148.
>>> To:
>>
> ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.fd52.
>>> From: ;tag=8625.
>>> Call-ID: 1272311050-3148-andy-h...@192.168.10.13.
>>> CSeq: 4 REGISTER.
>>> Contact: ;q=0.9;expires=3600.
>>> Se

Re: [OpenSIPS-Users] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Brett Nemeroff]

I agree with Richard here.. it's nice to be able to isolate branch changes
to not infect other branches. :)

As for the contact header example given above.. I also agree with Richard
that the function should be made to perhaps be a little more intuitive.

Overall, like I said before, I think a lot of these issues can be resolved
with smart scriptwriting. This is a bit OT, but one thing I think that would
help [people like me] out a lot is if the functions themselves would be
smart enough to alert the scriptwriter of doing stupid things.. For example,
there have been a number of posts to the mailing list regarding double
updating headers and getting "weird" results. instead of producing weird
results, I'd think that it'd do something like, only apply the last one
(which I can understand the complexity of saving the original msg along with
all requested changes..), or rejecting any duplicate efforts to change..
Either way, there should be a generated WARNING message to indicate that you
probably didn't want to do that and that it's a scripting error.

That's my $0.02. :)
-Brett


On Wed, Apr 28, 2010 at 1:07 PM, Richard Revels wrote:

> Being able to make changes on a branch and have those changes disappear
> when the branch does is very handy.
>
> So far, the issue of not being able to change a header in script because it
> had already been changed in a function call hasn't been a major issue for me
> either.  I wonder if the example given in another email of needing to add a
> tag after calling fix_natted_contact couldn't be resolved by changing the
> fix_natted_contact function to accept a tag parameter.
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Opensip-cp and xml-rpc-c question

[Sven Schulz]

Nevermind, I was able to get this to work...with help from a co-worker.
Works on CentOS 5.4 64bit

Instead of downloading the latest .tar file, we used SVN and got the latest
xmlrpc-c source. 

Then,
./configure --disable-abyss-threads
make
make install

And then recompiled opensips

On 4/28/10 9:45 AM, "Sven Schulz"  wrote:

> Alex, I just tried what you said and it still doesn¹t work. Are there any
> dependencies for xml-rpc-c that I need? Also, Im using 64 bit, if that
> matters.
> 
> Sven
> 
> 
> On 4/28/10 4:49 AM, "Alex Ionescu"  wrote:
> 
>> Hi Sven,
>> 
>> For your first question :
>> "Can I use mi_datagram instead of mi_xmlrpc for opensips-cp? "
>> Well, it is not suported ... yet. So, unfortunately, you cannot use
>> mi_datagram.
>> 
>> For the second question :
>> "If not, how to I compile xml-rpc-c into Centos5?"
>> We've recently installed CP and OpenSIPS on a Centos 5 server. We've used
>> xmlrpc-c-1.06.38
>> To install it please do : ./configure --disable-abyss-threads (this is very
>> important) ... then you do as usual make all and make install.
>> 
>> I hope you will succeed eventually !
>> 
>> Regards,
>> Alex
>> 
>> 
>> 
>> On 4/27/2010 22:58, Sven Schulz wrote:
>>>  Opensip-cp and xml-rpc-c question 2 part Question:
>>>  
>>>   
>>> 1. Can I use mi_datagram instead of mi_xmlrpc for opensips-cp?
>>> 2. If not, how to I compile xml-rpc-c into Centos5?
>>> 3.  
>>>  
>>> I cant compile the recommended version (.09.10) into 64bit.
>>> If I download the latest SRC, I get these errors at the end of MAKE:
>>>  
>>> /usr/bin/ld: XmlRpcCpp.o: relocation R_X86_64_32 against `a local symbol'
>>> can not be used when making a shared object; recompile with -fPIC
>>> XmlRpcCpp.o: could not read symbols: Bad value
>>> collect2: ld returned 1 exit status
>>> make[2]: *** [libxmlrpc_cpp.so.3.06] Error 1
>>> make[2]: Leaving directory `/usr/src/xmlrpc-c-1.06.38/src/cpp'
>>> make[1]: *** [cpp/all] Error 2
>>> make[1]: Leaving directory `/usr/src/xmlrpc-c-1.06.38/src'
>>> make: *** [src/all] Error 2
>>>  
>>>  
>>> Any help would be appreciated.
>>> 
>>> 
>>> ___
>>> 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

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

Re: [OpenSIPS-Users] UPDATE message and sdp

[Daniel Goepp]

Damn, I'm sorry, I completely missed that example in the doc...my bad...it
shows exactly how to switch the offer/answer based on an sdp in the original
invite or not, then branching to different reply routes and testing for sdp
in the 200 and ACK.  Thanks for pointing that out!

-dg


On Wed, Apr 28, 2010 at 2:51 AM, Bogdan-Andrei Iancu  wrote:

> For such cases (SDP negotiation via 200OK + ACK), see the "s" flag in
> the force_rtp_proxy() function:
>
> http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id271384
>
> Also, you are saying that has_body(sdp) does not work on the ACK ? can
> you post the ACK request you test?
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > One follow up on this...and this pains me...I have a gateway that
> > calls us with no SDP on the INVITE, then we send back a 200 OK w/SDP,
> > and it then sends back an ACK with SDP.  Now I believe that although
> > very uncommon, does not violate the spec.  However in this case, I see
> > that the rtpproxy_answer is set on the 200 OK reply, but the
> > if(has_body("application/sdp")) has no affect on the ACK.  I'm sure
> > I'm missing something here so any thoughts on the matter are greatly
> > appreciated.
> >
> > Thanks
> >
> > -dg
> >
> >
> > On Tue, Apr 27, 2010 at 2:56 PM, Daniel Goepp  > > wrote:
> >
> > And just after replying regarding my success (I have been running
> > this for many months now without problems), I do have a very
> > specific issue related to UPDATE messages.
> >
> > I have added some logging and for the following call, I get:
> >
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Request UPDATE: sip:2021@:5069 -
> > sip:6502734...@192.168.1.110:5060;transport=tcp
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Setting rtpproxy_offer - Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Fixing Contact - Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Relay message
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > new branch route 1 at sip:2021@:5069  -
> > sip:6502734101@:33774;transport=tcp
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > incoming reply route 1 -  - sip:2...@192.168.1.101:5069
> > 
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > Found a response from a private address! -
> > sip:2...@192.168.1.101:5069 
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > Setting rtpproxy_answer - Reply 1
> > Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]:
> > INFO:handle_command: lookup on ports 30882/29328, session timer
> > restarted
> > Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]:
> > INFO:handle_command: lookup on ports 31198/28836, session timer
> > restarted
> >
> > Which to me looks like it is identifying that it needs to fix the
> > SDP, but then in the outbound UPDATE the connection IP is still
> > the private address.  See trace below.  The signaling seems okay
> > otherwise, and the experience that I get is that the endpoint
> > being called to (2021) can no longer see the calling party (we are
> > testing video).  The 200 OK coming back does not have this
> > problem, it's connection IPs in the SDP are rewritten fine, making
> > me think perhaps it's something related to just UPDATE message,
> > but I don't know enough about the inner workings of OpenSIPS.
> > Thoughts?
> >
> > Thanks
> >
> > -dg
> >
> > 
> > 2010-04-27 14:45:49
> > tcp::33774 -> tcp::5060
> >
> > UPDATE sip:2021@:5069 SIP/2.0
> > Via: SIP/2.0/TCP
> > 192.168.1.110:5060
> ;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport
> > Call-ID: 4fdbf3351f217...@192.168.1.110
> > 
> > CSeq: 104 UPDATE
> > Contact: 
> > From: 
> >  >>;tag=7ad977f50f0f9d94
> > To: "Daniel Goepp" 
> >  >>;tag=DC151CA5-80A23EC4
> > Max-Forwards: 70
> > Route: ;lr;transport=tcp;transport=tcp>
> > Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
> > User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)
> > Proxy-Authorization: Digest nonce="*", realm="mydomain.com
> > ", username="6502734101",
> > uri="sip:mydomain.com ", response="***",
> > algorithm=MD5
> > Supported: replaces,100rel,timer,gruu,path,outbound
> > Session-Expires: 500;refresher=uac
> > Min-SE: 90
> > Content-Type: application/sdp
> >

Re: [OpenSIPS-Users] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Richard Revels]

Being able to make changes on a branch and have those changes disappear when 
the branch does is very handy.

So far, the issue of not being able to change a header in script because it had 
already been changed in a function call hasn't been a major issue for me 
either.  I wonder if the example given in another email of needing to add a tag 
after calling fix_natted_contact couldn't be resolved by changing the 
fix_natted_contact function to accept a tag parameter.

Fast is good.  At least in this context.

Richard

On Apr 28, 2010, at 1:45 PM, Bogdan-Andrei Iancu wrote:

> Hi Brett,
> 
> Thanks for the feedback - one of the goals of my email was to see how 
> "serious" and "spreading" is the issue with changes being applied at the 
> end. If the users do actually see here no problem, fine with me :)
> 
> Best regards,
> Bogdan
> 
> Brett Nemeroff wrote:
>>> From a user's perspective...
>> I can clearly see the need to pull information from the original 
>> message as well as the "processed, unsent message". I'm aware of this 
>> issue, but I've never ran into an issue where it's really been a 
>> problem. Typically, these issues are resolved by instead of using 
>> something like message headers, using previously set AVPs in the 
>> script. Maybe my assumption is from my lack of running into the 
>> problem, but I *think* it can be resolved by smart scriptwriting...
>> 
>> I don't know a whole lot about how the message is processed under the 
>> hood, but.. from a user perspective, I'd rather change my 
>> scriptwriting to handle these issues (assuming there is a way to 
>> mitigate the issue) than make an architectural change that would 
>> overall impair performance and scalability.
>> 
>> -Brett
>> 
>> 
>> On Wed, Apr 28, 2010 at 5:40 AM, Bogdan-Andrei Iancu 
>> mailto:bog...@voice-system.ro>> wrote:
>> 
>>Hi,
>> 
>>sorry for crossposting, but I thing this topic is interesting both for
>>users (as experience) and for developers (as solution).
>> 
>>So, right now the code for 2.0 got to a stage were we need to "apply"
>>changes on the received messages (like adding VIA headers, changing
>>headers, etc). And before starting the work on this area, I would like
>>to get some opinions on the available options:
>> 
>>   1) keep the current mechanism for changing the SIP messages by
>>using
>>lumps that are applied only when the message is sent out :
>>  Advantages: code is there and works; the mechanism is very
>>fast ;
>>no need to re-parse the message after the parsing
>>  Disadvantages : from script or code, you are not able to see the
>>previous changes you did on the message, like:
>>if you remove a hdr, it will be marked to be removed,
>>but you will still see it there after the removed
>>if you add a new hdr, you will not be able to see it
>>(it will be actually added only when the message will be sent out)
>>if you replace the contact hdr (like after
>>fix_nated_contact() ) will not see the new contact, but the old one
>>trying to apply 2 changes in the same area (like
>>changing twice the contact) will result in bogus result.
>> 
>>   2) find a new approach that will allow to push in realtime the
>>changes on messages
>>  Advantages: the change will take affect instantly, so all the
>>disadvantages from 1) (as user experience in operating opensips) will
>>disappear .
>>  Disadvantages : the code will probably be slower (the changes
>>part), but will speed up other parts of the code (where you need to
>>manually identify the prev changes);
>>changed parts of the SIP message will require re-parsing
>>(so the code will have to check the state of a header (if parsed
>>or not)
>>before each usage)
>>you will not be able to undo changes on the SIP
>>messages in
>>an easy way (for example during the parallel and serial forking on
>>per-branch changes)
>> 
>>So this is the dilemma: if the current mechanism (with applying
>>changes
>>at the end) such a bad user experience (scripting) in order to try for
>>2.0 a different approach ?
>> 
>>I would like to hear some opinions from both people writing
>>scripts and
>>people writing code.
>> 
>>Thanks and regards,
>>Bogdan
>> 
>>--
>>Bogdan-Andrei Iancu
>>www.voice-system.ro 
>> 
>> 
>>___
>>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] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Bogdan-Andrei Iancu]

Hi Brett,

Thanks for the feedback - one of the goals of my email was to see how 
"serious" and "spreading" is the issue with changes being applied at the 
end. If the users do actually see here no problem, fine with me :)

Best regards,
Bogdan

Brett Nemeroff wrote:
> >From a user's perspective...
> I can clearly see the need to pull information from the original 
> message as well as the "processed, unsent message". I'm aware of this 
> issue, but I've never ran into an issue where it's really been a 
> problem. Typically, these issues are resolved by instead of using 
> something like message headers, using previously set AVPs in the 
> script. Maybe my assumption is from my lack of running into the 
> problem, but I *think* it can be resolved by smart scriptwriting...
>
> I don't know a whole lot about how the message is processed under the 
> hood, but.. from a user perspective, I'd rather change my 
> scriptwriting to handle these issues (assuming there is a way to 
> mitigate the issue) than make an architectural change that would 
> overall impair performance and scalability.
>
> -Brett
>
>
> On Wed, Apr 28, 2010 at 5:40 AM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Hi,
>
> sorry for crossposting, but I thing this topic is interesting both for
> users (as experience) and for developers (as solution).
>
> So, right now the code for 2.0 got to a stage were we need to "apply"
> changes on the received messages (like adding VIA headers, changing
> headers, etc). And before starting the work on this area, I would like
> to get some opinions on the available options:
>
>1) keep the current mechanism for changing the SIP messages by
> using
> lumps that are applied only when the message is sent out :
>   Advantages: code is there and works; the mechanism is very
> fast ;
> no need to re-parse the message after the parsing
>   Disadvantages : from script or code, you are not able to see the
> previous changes you did on the message, like:
> if you remove a hdr, it will be marked to be removed,
> but you will still see it there after the removed
> if you add a new hdr, you will not be able to see it
> (it will be actually added only when the message will be sent out)
> if you replace the contact hdr (like after
> fix_nated_contact() ) will not see the new contact, but the old one
> trying to apply 2 changes in the same area (like
> changing twice the contact) will result in bogus result.
>
>2) find a new approach that will allow to push in realtime the
> changes on messages
>   Advantages: the change will take affect instantly, so all the
> disadvantages from 1) (as user experience in operating opensips) will
> disappear .
>   Disadvantages : the code will probably be slower (the changes
> part), but will speed up other parts of the code (where you need to
> manually identify the prev changes);
> changed parts of the SIP message will require re-parsing
> (so the code will have to check the state of a header (if parsed
> or not)
> before each usage)
> you will not be able to undo changes on the SIP
> messages in
> an easy way (for example during the parallel and serial forking on
> per-branch changes)
>
> So this is the dilemma: if the current mechanism (with applying
> changes
> at the end) such a bad user experience (scripting) in order to try for
> 2.0 a different approach ?
>
> I would like to hear some opinions from both people writing
> scripts and
> people writing code.
>
> Thanks and regards,
> Bogdan
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro 
>
>
> ___
> 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
>   


-- 
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] Opensips 1.6.2 w/ Control Panel 4.0 - Problem w/ CDRViews and Dialog

[Erick Chinchilla Berrocal]

 

 

From: Erick Chinchilla Berrocal [mailto:er...@netcrc.net] 
Sent: Wednesday, April 28, 2010 11:08 AM
To: 'OpenSIPS users mailling list'
Subject: RE: [OpenSIPS-Users] Opensips 1.6.2 w/ Control Panel 4.0 - Problem
w/ CDRViews and Dialog

 

Alex this is my current setup 

-  /var/www/opensips-cp/config/db.inc.php

//database driver mysql or pgsql

$config->db_driver = "mysql";  

 

 //database host

 $config->db_host = "localhost";

 

 //database port - leave empty for default

 $config->db_port = "";

 

 //database connection user

$config->db_user = "root";

 

 //database connection password

 $config->db_pass = "passwd root";

 

//database name

$config->db_name = "opensips";

 

 if (!empty($config->db_port) ) $config->db_host = $config->db_host . ":" .
$config->db_port;

 

?>

 

-  /var/www/opensips-cp/config/boxes.global.inc.php

/* DEFINITION OF BOXES (servers)
*/

// each server is a box

 

$box_id=0;

 

// mi host:port pair || fifo_file

$boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";

 

// monit host:port

$boxes[$box_id]['monit']['conn']="127.0.0.1:2812";

$boxes[$box_id]['monit']['user']="admin";

$boxes[$box_id]['monit']['pass']="monit";

$boxes[$box_id]['monit']['has_ssl']=0;

 

 

// description (appears in mi , monit )

$boxes[$box_id]['desc']="Primary SIP server";

 

 

$boxes[$box_id]['assoc_id']=1;

 

// enable local smonitor charts on this box : 0=disabled 1=enabled

// (cron)

$boxes[$box_id]['smonitor']['charts']=1;

 

-  Opensips.cfg

-  # - mi_fifo params -

-  modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")

-  modparam("mi_fifo", "fifo_mode", 0666)

 

Thanks

Erick Ch.

 

From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Alex Ionescu
Sent: Wednesday, April 28, 2010 3:07 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Opensips 1.6.2 w/ Control Panel 4.0 - Problem
w/ CDRViews and Dialog

 

Hi Erick,

The global db.inc.php (the one you have in /var/www/opensips-cp/config/) is
used by all the modules as long as they don't find something more specific
defined into their config files (like, for example, if you want a different
db setup for module domains you can edit
/var/www/opensips-cp/config/tools/system/domains/db.inc.php - and this will
override the global db setup ).

Dialog takes the call information using a MI command. So you must have
OpenSIPS Control Panel and OpenSIPS configured properly (you must choose
between xmlrpc and fifo) - see the OpenSIPS config file (to enable mi_xmlrpc
module or the mi_fifo) and also check the config/boxes.global.inc.php to
have the correct MI connection parameters set up.

Regards,
Alex







-- 
Alex Ionescu
www.voice-system.ro 





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

Re: [OpenSIPS-Users] OpenSIPS and Virtual IP implementation

[Max Mühlbronner]

Hi,

we are running a very similar setup, failover via virtual ips. There is 
an option which allows you to bind opensips to this ip.

*|echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

|*

/proc/sys/net/ipv4/ip_nonlocal_bind

Set this if you want your applications to be able to bind to an
address which doesn't belong to a device on your system. This can be
useful when your machine is on a non-permanent (or even dynamic)
link, so your services are able to start up and bind to a specific
address when your link is down.

*|Next, you would just need to add the listen lines in Opensips to bind to this 
virtual ip, opensips will bind to this virtual ip even if it is not yet 
available on the system. Should be working great. Hope this helps.


Max M.
|*


rajib deka schrieb:
> Hi List,
>  
> I have implemented Virtual IP based failover for our OpenSIPS linux 
> cluster. The logic is our two OpenSIPS server will share a same 
> Virtual IP, initially master server will be up with the virtual IP and 
> once the master is down the back up OpenSIPS will take over the 
> Virtual IP. The issue I am facing here is after uping and arping the 
> Virtul IP with eth0 interface (irrespective of master or backup), when 
> I restart OpenSIPS to bind the TCP/UDP ports to Virtual IP OpenSIPS  
> takes more than expected time to start again (restarting). What may be 
> the cause for this? Is there any solution for this? But once OpenSIPS 
> is up it works fine with Virtual IP, also if I restart OpenSIPS only 
> with the physical IP it restarts quickly.
>
> -- 
> Rajib Deka
> Software Engineer
> Servion Global Solution
> Chennai, India
>
> Mobile No: + 91 80157 09130
> 
>
> ___
> 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] UPDATE message and sdp

[Daniel Goepp]

Thanks, I will look into this.

-dg


On Wed, Apr 28, 2010 at 2:51 AM, Bogdan-Andrei Iancu  wrote:

> For such cases (SDP negotiation via 200OK + ACK), see the "s" flag in
> the force_rtp_proxy() function:
>
> http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id271384
>
> Also, you are saying that has_body(sdp) does not work on the ACK ? can
> you post the ACK request you test?
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > One follow up on this...and this pains me...I have a gateway that
> > calls us with no SDP on the INVITE, then we send back a 200 OK w/SDP,
> > and it then sends back an ACK with SDP.  Now I believe that although
> > very uncommon, does not violate the spec.  However in this case, I see
> > that the rtpproxy_answer is set on the 200 OK reply, but the
> > if(has_body("application/sdp")) has no affect on the ACK.  I'm sure
> > I'm missing something here so any thoughts on the matter are greatly
> > appreciated.
> >
> > Thanks
> >
> > -dg
> >
> >
> > On Tue, Apr 27, 2010 at 2:56 PM, Daniel Goepp  > > wrote:
> >
> > And just after replying regarding my success (I have been running
> > this for many months now without problems), I do have a very
> > specific issue related to UPDATE messages.
> >
> > I have added some logging and for the following call, I get:
> >
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Request UPDATE: sip:2021@:5069 -
> > sip:6502734...@192.168.1.110:5060;transport=tcp
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Setting rtpproxy_offer - Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Fixing Contact - Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Relay message
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > new branch route 1 at sip:2021@:5069  -
> > sip:6502734101@:33774;transport=tcp
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > incoming reply route 1 -  - sip:2...@192.168.1.101:5069
> > 
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > Found a response from a private address! -
> > sip:2...@192.168.1.101:5069 
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > Setting rtpproxy_answer - Reply 1
> > Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]:
> > INFO:handle_command: lookup on ports 30882/29328, session timer
> > restarted
> > Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]:
> > INFO:handle_command: lookup on ports 31198/28836, session timer
> > restarted
> >
> > Which to me looks like it is identifying that it needs to fix the
> > SDP, but then in the outbound UPDATE the connection IP is still
> > the private address.  See trace below.  The signaling seems okay
> > otherwise, and the experience that I get is that the endpoint
> > being called to (2021) can no longer see the calling party (we are
> > testing video).  The 200 OK coming back does not have this
> > problem, it's connection IPs in the SDP are rewritten fine, making
> > me think perhaps it's something related to just UPDATE message,
> > but I don't know enough about the inner workings of OpenSIPS.
> > Thoughts?
> >
> > Thanks
> >
> > -dg
> >
> > 
> > 2010-04-27 14:45:49
> > tcp::33774 -> tcp::5060
> >
> > UPDATE sip:2021@:5069 SIP/2.0
> > Via: SIP/2.0/TCP
> > 192.168.1.110:5060
> ;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport
> > Call-ID: 4fdbf3351f217...@192.168.1.110
> > 
> > CSeq: 104 UPDATE
> > Contact: 
> > From: 
> >  >>;tag=7ad977f50f0f9d94
> > To: "Daniel Goepp" 
> >  >>;tag=DC151CA5-80A23EC4
> > Max-Forwards: 70
> > Route: ;lr;transport=tcp;transport=tcp>
> > Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
> > User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)
> > Proxy-Authorization: Digest nonce="*", realm="mydomain.com
> > ", username="6502734101",
> > uri="sip:mydomain.com ", response="***",
> > algorithm=MD5
> > Supported: replaces,100rel,timer,gruu,path,outbound
> > Session-Expires: 500;refresher=uac
> > Min-SE: 90
> > Content-Type: application/sdp
> > Content-Length: 455
> >
> > v=0
> > o=tandberg 17 2 IN IP4 192.168.1.110
> > s=-
> > c=IN IP4 192.168.1.110
> > b=CT:768
> > t=0 0
> > m=audio 2354 RTP/AVP 100 102
> > c=IN IP4 192.168.1.110
> > b=TIAS:64000

Re: [OpenSIPS-Users] UPDATE message and sdp

[Daniel Goepp]

I am using rtpproxy_offer and rtpproxy_answer as the doc indicated that
force_rtp_proxy was depreciated, however I will try it in this situation to
see if it works.

-dg


On Wed, Apr 28, 2010 at 2:49 AM, Bogdan-Andrei Iancu  wrote:

> Hi Daniel,
>
> Are you doing force_rtp_proxy for the UPDATE request?
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > And just after replying regarding my success (I have been running this
> > for many months now without problems), I do have a very specific issue
> > related to UPDATE messages.
> >
> > I have added some logging and for the following call, I get:
> >
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Request UPDATE: sip:2021@:5069 -
> > sip:6502734...@192.168.1.110:5060;transport=tcp
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Setting rtpproxy_offer - Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Fixing Contact - Route 1
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> > Relay message
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: new
> > branch route 1 at sip:2021@:5069  -
> > sip:6502734101@:33774;transport=tcp
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > incoming reply route 1 -  - sip:2...@192.168.1.101:5069
> > 
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > Found a response from a private address! - sip:2...@192.168.1.101:5069
> > 
> > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> > Setting rtpproxy_answer - Reply 1
> > Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]: INFO:handle_command:
> > lookup on ports 30882/29328, session timer restarted
> > Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]: INFO:handle_command:
> > lookup on ports 31198/28836, session timer restarted
> >
> > Which to me looks like it is identifying that it needs to fix the SDP,
> > but then in the outbound UPDATE the connection IP is still the private
> > address.  See trace below.  The signaling seems okay otherwise, and
> > the experience that I get is that the endpoint being called to (2021)
> > can no longer see the calling party (we are testing video).  The 200
> > OK coming back does not have this problem, it's connection IPs in the
> > SDP are rewritten fine, making me think perhaps it's something related
> > to just UPDATE message, but I don't know enough about the inner
> > workings of OpenSIPS.  Thoughts?
> >
> > Thanks
> >
> > -dg
> >
> > 
> > 2010-04-27 14:45:49
> > tcp::33774 -> tcp::5060
> >
> > UPDATE sip:2021@:5069 SIP/2.0
> > Via: SIP/2.0/TCP
> > 192.168.1.110:5060
> ;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport
> > Call-ID: 4fdbf3351f217...@192.168.1.110
> > 
> > CSeq: 104 UPDATE
> > Contact: 
> > From: 
> >  >>;tag=7ad977f50f0f9d94
> > To: "Daniel Goepp" 
> >  >>;tag=DC151CA5-80A23EC4
> > Max-Forwards: 70
> > Route: ;lr;transport=tcp;transport=tcp>
> > Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
> > User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)
> > Proxy-Authorization: Digest nonce="*", realm="mydomain.com
> > ", username="6502734101", uri="sip:mydomain.com
> > ", response="***", algorithm=MD5
> > Supported: replaces,100rel,timer,gruu,path,outbound
> > Session-Expires: 500;refresher=uac
> > Min-SE: 90
> > Content-Type: application/sdp
> > Content-Length: 455
> >
> > v=0
> > o=tandberg 17 2 IN IP4 192.168.1.110
> > s=-
> > c=IN IP4 192.168.1.110
> > b=CT:768
> > t=0 0
> > m=audio 2354 RTP/AVP 100 102
> > c=IN IP4 192.168.1.110
> > b=TIAS:64000
> > a=rtpmap:100 G7221/16000
> > a=fmtp:100 bitrate=32000
> > a=rtpmap:102 telephone-event/8000
> > a=fmtp:102 0-15
> > a=sendrecv
> > m=video 2356 RTP/AVP 97
> > b=TIAS:768000
> > a=rtpmap:97 H264/9
> > a=fmtp:97
> > profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
> > a=sendrecv
> > a=content:main
> > a=label:11
> >
> > 
> > 2010-04-27 14:45:49
> > udp::5060 -> udp::5069
> >
> > UPDATE sip:2021@:5069 SIP/2.0
> > Record-Route: ;lr;transport=tcp>
> > Via: SIP/2.0/UDP ;branch=z9hG4bK7e7f.ef3c6013.0;i=9
> > Via: SIP/2.0/TCP
> > 192.168.1.110:5060
> ;received=;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport=33774
> > Call-ID: 4fdbf3351f217...@192.168.1.110
> > 
> > CSeq: 104 UPDATE
> > Contact: :33774;transport=tcp>
> > From: 
> >  >>;tag=7ad977f50f0f9d94
> > To: "Daniel Goepp" 
> >  >>;tag=DC151CA5-80A23EC4
> > Max-Forwards: 69
> > Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY

[OpenSIPS-Users] [NEW] exchanging info between dialogs

[Bogdan-Andrei Iancu]

Hi,

just added to the dialog module a new function that allow you to 
exchange data between dialogs - mainly to extract data from a different 
ongoing dialog.

Such functionality is vital in complex scenarios (PBX related) like 
attended call transfer - in such cases you may want to route a new call 
based on information of existing dialogs.

Real case example:

OpenSIPS is doing dispatching over a set of Asterisk boxes (which 
act as SIP servers).
A calls B and the call is established (by dispatching from OpenSIPS) 
via A1 Asterisk server
A wants to transfer B to a new party C, so A makes a new call to C 
-> this call must end on A1 also, without going via dispatcher in openSIPS.
So, when A calls C, OpenSIPS will check if A has an already existing 
call and if so, it will send the new call to the same Asterisk box as 
the existing call.

In such a case, for each call, you need to attached to the call (as 
dialog variables) the callee, caller and the Asterisk box . When a new 
call is coming, you check if the new caller is already involved in a 
call and if so, fetch the value of the proxy in order to send to the 
same box.

For more about the technical details of the function, see
   http://www.opensips.org/html/docs/modules/devel/dialog.html#id272137

Regards,
Bogdan

-- 
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] Relaying of RTP packets between two opensips/mediaproxy

[Adrian Georgescu]

MediaProxy is designed to work only on public IP addresses. Only the  
end-points can or may have private IP addresses. If your server has a  
private IP address it cannot detect if the end-points are behind NAT  
or not.

As a general rule servers must run on a public IP address otherwise  
you will sooner or later run into problems that are very expensive to  
solve.

Adrian

On Apr 28, 2010, at 5:00 PM, José María Jiménez wrote:

> Hi all,
>
> I'm testing a VoIP architecture in order to make a call between two  
> IP phones in a LOCAL network environment (I'm not using any public  
> IP) where the packets through 2 proxies (composed by a OpenSIPS, a  
> MediaProxy module and a MediaProxy) and an Asterisk. After several  
> attempts of configuring OpenSIPS and MediaProxy, I can't achieve RTP  
> relaying between P1, P2 and Asterisk.
>
> VoIP Architecture:
>
>192.x.x.x172.x.x.x172.y.x.x
> +--+--- 
> ++
>
> S1-+
>   |
>   +<---SIP/RTP---> P1 <---SIP/RTP---> P2 <---SIP/RTP---> A
>   |
> S2 -+
>
>
>S1 = Softphone 1
>S2 = Softphone 2
>
>P1 = Proxy 1 ( OpenSIPS + MediaProxy )
>P2 = Proxy 2 ( OpenSIPS + MediaProxy )
>
>A = Asterisk
>
> SIP traffic works correctly:
> - The phones are registred (REGISTER) in Asterisk. OpenSIPS 1 and 2  
> only relay the SIP packets.
> - The caller sends the initial "INVITE" to P1, P1 to P2 and P2 to  
> Asterisk.
>
> When I make a call, signaling works correctly but audio (RTP)  
> doesn't. The phones send their RTP packets to Proxy1, But P1 is  
> unable to forward them to P2. I know it can be due to NAT problems,  
> but I still have some doubts:
>
> 1) About the NAT problem, Does it affect to local networks? All  
> elements of this architecture are in differents local networks  
> (phones in 192.x.x.x, proxies in 172.x.x.x, asterisk in 172.y.x.x)  
> and every element of the solution knows how to routing IP packets  
> from one network to another, so... is NAT affecting to this VoIP  
> architecture?
>
> 2) Another question... It's possible relaying RTP traffic from one  
> MediaProxy directly to another, right?
>
> Thanks in advance for your help :) I have read a lot about NAT but I  
> still don't understand if this affects to my VoIP architecture if I  
> work just with private IPs.
>
> José M.
>
> ___
> 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

[OpenSIPS-Users] Relaying of RTP packets between two opensips/mediaproxy

[José María Jiménez]

Hi all,

I'm testing a VoIP architecture in order to make a call between two IP
phones in a LOCAL network environment (I'm not using any public IP) where
the packets through 2 proxies (composed by a OpenSIPS, a MediaProxy module
and a MediaProxy) and an Asterisk. After several attempts of configuring
OpenSIPS and MediaProxy, I can't achieve RTP relaying between P1, P2 and
Asterisk.

VoIP Architecture:

   192.x.x.x172.x.x.x172.y.x.x
+--+---++

S1-+
  |
  +<---SIP/RTP---> P1 <---SIP/RTP---> P2 <---SIP/RTP---> A
  |
S2 -+


   S1 = Softphone 1
   S2 = Softphone 2

   P1 = Proxy 1 ( OpenSIPS + MediaProxy )
   P2 = Proxy 2 ( OpenSIPS + MediaProxy )

   A = Asterisk

SIP traffic works correctly:
- The phones are registred (REGISTER) in Asterisk. OpenSIPS 1 and 2 only
relay the SIP packets.
- The caller sends the initial "INVITE" to P1, P1 to P2 and P2 to Asterisk.

When I make a call, signaling works correctly but audio (RTP) doesn't. The
phones send their RTP packets to Proxy1, But P1 is unable to forward them to
P2. I know it can be due to NAT problems, but I still have some doubts:

1) About the NAT problem, Does it affect to local networks? All elements of
this architecture are in differents local networks (phones in 192.x.x.x,
proxies in 172.x.x.x, asterisk in 172.y.x.x) and every element of the
solution knows how to routing IP packets from one network to another, so...
is NAT affecting to this VoIP architecture?

2) Another question... It's possible relaying RTP traffic from one
MediaProxy directly to another, right?

Thanks in advance for your help :) I have read a lot about NAT but I still
don't understand if this affects to my VoIP architecture if I work just with
private IPs.

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

Re: [OpenSIPS-Users] OpenSIPS defunct processes

[Bogdan-Andrei Iancu]

Hi David,

by chance, using the "exec" module  ?

Or, can you list the modules you are using ?

Regards,
Bogdan

David Cunningham wrote:
> Hello,
>
> Thank you for the reply. I checked the parent of the zombie processes,
> and they seem to be "SIP receiver" processes as per the following "ps
> -ef" extract and "opensipsctl fifo ps" information.
> We're not running the "respawn" patch.
>
> Any more advice very welcome, thanks again!
>
>
> user  5830 1  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5832  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5833  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5834  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5835  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5836  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5837  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5838  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5839  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5840  5830  0 06:38 ?00:00:01 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5841  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5842  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5843  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5844  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5845  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5846  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5847  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5848  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5849  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5850  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  5851  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
> /var/run/user/opensips.pid
> user  7260  5833  0 08:30 ?00:00:00 [opensips] 
> user  7261  5833  0 08:30 ?00:00:00 [opensips] 
> user  7262  5833  0 08:30 ?00:00:00 [opensips] 
> user  7263  5833  0 08:30 ?00:00:00 [opensips] 
> user  7264  5833  0 08:30 ?00:00:00 [opensips] 
> user  7265  5833  0 08:30 ?00:00:00 [opensips] 
> user  9770  5835  0 08:37 ?00:00:00 [opensips] 
> user  9771  5835  0 08:37 ?00:00:00 [opensips] 
> user  9772  5835  0 08:37 ?00:00:00 [opensips] 
> user  9838  5834  0 08:38 ?00:00:00 [opensips] 
> user  9839  5834  0 08:38 ?00:00:00 [opensips] 
> user 15519  5833  0 08:57 ?00:00:00 [opensips] 
> user 15520  5833  0 08:57 ?00:00:00 [opensips] 
> user 15521  5833  0 08:57 ?00:00:00 [opensips] 
> user 15522  5833  0 08:57 ?00:00:00 [opensips] 
>
>
> [r...@hostname ~]# opensipsctl fifo ps
> Process::  ID=0 PID=5830 Type=attendant
> Process::  ID=1 PID=5832 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
> Process::  ID=2 PID=5833 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
> Process::  ID=3 PID=5834 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
> Process::  ID=4 PID=5835 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
> Process::  ID=5 PID=5836 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
> Process::  ID=6 PID=5837 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
> Process::  ID=7 PID=5838 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
> Process::  ID=8 PID=5839 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
> Process::  ID=9 PID=5840 Type=timer
> Process::  ID=10 PID=5841 Type=timer
> Process::  ID=11 PID=5842 Type=MI FIFO
> Process::  ID=12 PID=5843 Type=TCP receiver
> Process::  ID=13 PID=5844 Type=TCP receiver
> Process::  ID=14 PID=5845 Type=TCP receiver
> Process::  ID=15 PID=5846 Type=TCP receiver
> Process::  ID=16 PID=5847 Type=TCP receiver
> Process::  ID=17 PID=5848 Type=TCP receiver
> Process::  ID=18 PID=5849 Type=TCP receiver
> Process::  ID=19 PID=5850 Type=TCP receiver
> Process::  ID=20 PID=5851 Type=TCP main
>
>
>
> On Mon, Apr 26, 2010 at 12:22 PM, Bogdan-Andrei Iancu
>  wrote:
>   
>> Hi David,
>>
>> Let's try and see what's the parent process of the zombie procs -> check
>> with ps and correlate (for the name) with "opensipsctl fifo ps"
>>
>> I guess the parent of the zombies should be the "attendant proc" .  BTW,
>> are you running with the "respawn" patch ?
>>
>> Regards,
>> Bogdan
>>
>> David Cunningham wrote

Re: [OpenSIPS-Users] OpenSIPS defunct processes

[David Cunningham]

Hello,

Thank you for the reply. I checked the parent of the zombie processes,
and they seem to be "SIP receiver" processes as per the following "ps
-ef" extract and "opensipsctl fifo ps" information.
We're not running the "respawn" patch.

Any more advice very welcome, thanks again!


user  5830 1  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5832  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5833  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5834  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5835  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5836  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5837  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5838  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5839  5830  0 06:38 ?00:00:16 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5840  5830  0 06:38 ?00:00:01 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5841  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5842  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5843  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5844  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5845  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5846  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5847  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5848  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5849  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5850  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  5851  5830  0 06:38 ?00:00:00 /sbin/opensips -m 256 -P
/var/run/user/opensips.pid
user  7260  5833  0 08:30 ?00:00:00 [opensips] 
user  7261  5833  0 08:30 ?00:00:00 [opensips] 
user  7262  5833  0 08:30 ?00:00:00 [opensips] 
user  7263  5833  0 08:30 ?00:00:00 [opensips] 
user  7264  5833  0 08:30 ?00:00:00 [opensips] 
user  7265  5833  0 08:30 ?00:00:00 [opensips] 
user  9770  5835  0 08:37 ?00:00:00 [opensips] 
user  9771  5835  0 08:37 ?00:00:00 [opensips] 
user  9772  5835  0 08:37 ?00:00:00 [opensips] 
user  9838  5834  0 08:38 ?00:00:00 [opensips] 
user  9839  5834  0 08:38 ?00:00:00 [opensips] 
user 15519  5833  0 08:57 ?00:00:00 [opensips] 
user 15520  5833  0 08:57 ?00:00:00 [opensips] 
user 15521  5833  0 08:57 ?00:00:00 [opensips] 
user 15522  5833  0 08:57 ?00:00:00 [opensips] 


[r...@hostname ~]# opensipsctl fifo ps
Process::  ID=0 PID=5830 Type=attendant
Process::  ID=1 PID=5832 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
Process::  ID=2 PID=5833 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
Process::  ID=3 PID=5834 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
Process::  ID=4 PID=5835 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
Process::  ID=5 PID=5836 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
Process::  ID=6 PID=5837 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
Process::  ID=7 PID=5838 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
Process::  ID=8 PID=5839 Type=SIP receiver udp:xxx.xxx.xxx.xxx:5060
Process::  ID=9 PID=5840 Type=timer
Process::  ID=10 PID=5841 Type=timer
Process::  ID=11 PID=5842 Type=MI FIFO
Process::  ID=12 PID=5843 Type=TCP receiver
Process::  ID=13 PID=5844 Type=TCP receiver
Process::  ID=14 PID=5845 Type=TCP receiver
Process::  ID=15 PID=5846 Type=TCP receiver
Process::  ID=16 PID=5847 Type=TCP receiver
Process::  ID=17 PID=5848 Type=TCP receiver
Process::  ID=18 PID=5849 Type=TCP receiver
Process::  ID=19 PID=5850 Type=TCP receiver
Process::  ID=20 PID=5851 Type=TCP main



On Mon, Apr 26, 2010 at 12:22 PM, Bogdan-Andrei Iancu
 wrote:
> Hi David,
>
> Let's try and see what's the parent process of the zombie procs -> check
> with ps and correlate (for the name) with "opensipsctl fifo ps"
>
> I guess the parent of the zombies should be the "attendant proc" .  BTW,
> are you running with the "respawn" patch ?
>
> Regards,
> Bogdan
>
> David Cunningham wrote:
>> Hello,
>>
>> Thanks again for your assistance!
>>
>> We're not using the mi_xmlrpc module.
>>
>> Were you suggesting using gdb on the zombi process? I tried and got
>> the following:
>>
>> user 31183 12140  0 10:31 ?        00:00:00 [opensips] 
>> [r...@sip01 ~]# gdb /sbin/opensips 31183
>> GNU gdb Fedora (6.8-37.el5)
>> Copyright

Re: [OpenSIPS-Users] Are there in OpenSIPS modules like AGI on asterisk ?

[Brett Nemeroff]

Sam,
Of course, opensips doesn't support most traditional centrex services.
Howeever, you may be able to get some of what you are looking for
using avp_db_query
-Brett




On Apr 28, 2010, at 8:57 AM, samoh  wrote:

>
> Hi Bogdan,
>
> I really want to have a possibility to run a script on  OpenSIPS or
> external
> of OpenSIPS, I want to run a script in python or other language as a
> way to
> query my database to configure the call by calling (that is just an
> example)
> not to be dependent on any module.
> I am doing my internship in a company that has its own script about
> asterisk
> and architecture of the database and my target is to developpe an IP
> Centrex
> with Opensips in order to don't touch to the present architecture
> (Database)
> and my solution must be independent of mudules so that allows any
> other
> developpement on this IP Centrex.
>
> I really don't know how to do, it's some days I'm looking but no
> idea yet.
>
> is there a function which allows to end a call after N minut ?
>
> Thanks.
>
> Best regards.
> Sam.
> --
> View this message in context: 
> http://opensips-open-sip-server.1449251.n2.nabble.com/Are-there-in-OpenSIPS-modules-like-AGI-on-asterisk-tp4967382p4974578.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

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

Re: [OpenSIPS-Users] Are there in OpenSIPS modules like AGI on asterisk ?

[samoh]

Hi Bogdan,

I really want to have a possibility to run a script on  OpenSIPS or external
of OpenSIPS, I want to run a script in python or other language as a way to
query my database to configure the call by calling (that is just an example)
not to be dependent on any module.
I am doing my internship in a company that has its own script about asterisk
and architecture of the database and my target is to developpe an IP Centrex
with Opensips in order to don't touch to the present architecture (Database)
and my solution must be independent of mudules so that allows any other
developpement on this IP Centrex.

I really don't know how to do, it's some days I'm looking but no idea yet.

is there a function which allows to end a call after N minut ?

Thanks.

Best regards.
Sam.
-- 
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Are-there-in-OpenSIPS-modules-like-AGI-on-asterisk-tp4967382p4974578.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] Opensip-cp and xml-rpc-c question

[Sven Schulz]

Alex, I just tried what you said and it still doesn¹t work. Are there any
dependencies for xml-rpc-c that I need? Also, Im using 64 bit, if that
matters.

Sven


On 4/28/10 4:49 AM, "Alex Ionescu"  wrote:

> Hi Sven,
> 
> For your first question :
> "Can I use mi_datagram instead of mi_xmlrpc for opensips-cp? "
> Well, it is not suported ... yet. So, unfortunately, you cannot use
> mi_datagram.
> 
> For the second question :
> "If not, how to I compile xml-rpc-c into Centos5?"
> We've recently installed CP and OpenSIPS on a Centos 5 server. We've used
> xmlrpc-c-1.06.38 
> To install it please do : ./configure --disable-abyss-threads (this is very
> important) ... then you do as usual make all and make install.
> 
> I hope you will succeed eventually !
> 
> Regards,
> Alex
> 
> 
> 
> On 4/27/2010 22:58, Sven Schulz wrote:
>>  Opensip-cp and xml-rpc-c question 2 part Question:
>>  
>>   
>> 1. Can I use mi_datagram instead of mi_xmlrpc for opensips-cp?
>> 2. If not, how to I compile xml-rpc-c into Centos5?
>> 3.  
>>  
>> I cant compile the recommended version (.09.10) into 64bit.
>> If I download the latest SRC, I get these errors at the end of MAKE:
>>  
>> /usr/bin/ld: XmlRpcCpp.o: relocation R_X86_64_32 against `a local symbol' can
>> not be used when making a shared object; recompile with -fPIC
>> XmlRpcCpp.o: could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>> make[2]: *** [libxmlrpc_cpp.so.3.06] Error 1
>> make[2]: Leaving directory `/usr/src/xmlrpc-c-1.06.38/src/cpp'
>> make[1]: *** [cpp/all] Error 2
>> make[1]: Leaving directory `/usr/src/xmlrpc-c-1.06.38/src'
>> make: *** [src/all] Error 2
>>  
>>  
>> Any help would be appreciated.
>> 
>> 
>> ___
>> 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

[OpenSIPS-Users] OpenSIPS and Virtual IP implementation

[rajib deka]

Hi List,

I have implemented Virtual IP based failover for our OpenSIPS linux cluster.
The logic is our two OpenSIPS server will share a same Virtual IP, initially
master server will be up with the virtual IP and once the master is down the
back up OpenSIPS will take over the Virtual IP. The issue I am facing here
is after uping and arping the Virtul IP with eth0 interface (irrespective of
master or backup), when I restart OpenSIPS to bind the TCP/UDP ports
to Virtual IP OpenSIPS  takes more than expected time to start again
(restarting). What may be the cause for this? Is there any solution for
this? But once OpenSIPS is up it works fine with Virtual IP, also if I
restart OpenSIPS only with the physical IP it restarts quickly.

-- 
Rajib Deka
Software Engineer
Servion Global Solution
Chennai, India

Mobile No: + 91 80157 09130
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] avoid down time caused by mysql server connection lost

[Bogdan-Andrei Iancu]

Hi Julien,

I see you get a crash there :(can you post the backtrace ?

Thanks,
Bogdan

Julien Chavanton wrote:
>
> Hi, I have single point of failure for Opensips with siptrace and CDR, 
> if the Mysql server is disconnected from the network opensip will stop 
> working, I would rather continue to accept calls without storing 
> CDR/trace or use a secondary mysql connection.
>
> Is there any recommendation / best practice ?
>
>  config
>
> modparam("siptrace", "db_url", "mysql://login:passw...@x.x.x.x/opensips")
>
> modparam("acc", "db_url", "mysql://login:passw...@x.x.x.x/opensips")
>
>  log
>
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]: 
> INFO:core:handle_sigs: child process 4835 exited by a signal 11
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4844]: 
> CRITICAL:core:receive_fd: EOF on 24
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]: 
> INFO:core:handle_sigs: core was generated
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]: 
> INFO:core:handle_sigs: terminating due to SIGCHLD
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4840]: 
> INFO:core:sig_usr: signal 15 received
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4834]: 
> INFO:core:sig_usr: signal 15 received
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4843]: 
> INFO:core:sig_usr: signal 15 received
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4842]: 
> INFO:core:sig_usr: signal 15 received
>
> 
>
> ___
> 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] Issue with rls module?

[Anca Vamanu]

Andres2 Cores2 wrote:
> Thank you Anca
>
> In fact I am using the user-agent (picked it up from one config file), 
> either my client either opensips.
>   if($hdr(User-Agent) =~ "me")
>   {
> xlog("L_DBG","RLS subscribe");
> $var(ret_code)= rls_handle_subscribe();
>  if($var(ret_code)== 10){
>  handle_subscribe();
>   }
>}
>else
>{
>   xlog(" route 2 subscribe normal --- \n");
>handle_subscribe();
>}
>
> Now, after some fixes of the configuration, it seems the flow is 
> correctly managed.
> There is still one point I am not sure. I had some issues with the 
> NOTIFY sent by PS to RLS
> that was not correctly managed and I fixed it by adding this condition 
> for NOTIFY
>
> if 
> ((is_method("SUBSCRIBE")||is_method("NOTIFY")) && $rd == "10.62.0.155") {
> # in-dialog subscribe requests
> route(2);
> exit;
> }
>
> Where route(2) invokes rls_handle_notify() for NOTIFY requests.
>
> Do you think it is fine? It is not perfectly clear what is called the 
> "in-dialog" subscribe requests.
>
Yes, the check is all right. The most common check is if "uri == 
myself", because then it is sure that the Notify is addressed to 
OpenSIPS. The stricter check is uri== "what you set in server_address 
prameter for module rls".
That comment line with in-dialog requests is put there because that if 
you look in the default configuration file - initial and in-dialog 
rquests are processed separately. The type is determined at the 
beginning and there are two different block for the two types of 
messages. So, for Subscribes route(2) is called in two places in the 
script - once for the initial ones and also for the in dialog ones. 
Anyhow that comment is not something you should worry about.

Regards,

-- 
Anca Vamanu
www.voice-system.ro


> Thanks for all.
> Andrew
>
>
> 2010/4/28 Anca Vamanu mailto:a...@opensips.org>>
>
> Hi Andrew,
>
> Thanks for your appreciation.
> The thing that you need to take care with RLS are the Subscribe
> messages
> sent by the RLS server ( because this is the mechanism - when
> receiving
> a Subscribe for RLS the rls server will send more Subscribe
> messages to
> the presence server, and I see that you have the presence server
> collocated with rls). You need to make sure that these are handled by
> the presence server and that they do not go into rls again. For
> this you
> can check the source of the message and if it is the same machine just
> call handle_subscribe.
>
> if(is_method("SUBSCRIBE") && si == "_local_ip_")
>handle_subscribe();
>
> If you watch the network trace and log where each subscribe goes for
> processing and still notice this errors, post again an email on
> the list.
>
> Regards,
>
> --
> Anca Vamanu
> www.voice-system.ro 
>
>
>
>
> Andres2 Cores2 wrote:
> > Hi,
> >
> > First of all we would like to thank the whole opensips team. For
> > testing our client, we are mainly interested in the presence and rls
> > topics and found that a pretty good set of features is available
> right
> > now, so thanks for your job.
> >
> > During our tests we encountered an issue running opensips 1.6 in
> > rls-server mode (simple presence works fine). It seems to us it is
> > just a configuration issue or a bug in the routing rules, but we
> can't
> > find out it.
> >
> > From the client point of view I cannot succeed in receiving presence
> > Notify messages body, only rlmi parts are provided.
> >
> > In fact it seems rls_handle_subscribe has issues when trying to send
> > Subscribes to Presence on behalf of rls. I have systematically
> errors
> > "presence:get_stored_info: record not found in hash_table" and
> > sometimes "Duplicate entry
> > 'sip:alice-l...@promethee.test.com-cbb99ea81711c30ed9c0edf6' for
> key 2"
> >
> > Typically:
> > Apr 26 13:45:57 [20047] ERROR:db_mysql:db_mysql_do_prepared_query:
> > driver error: Duplicate entry
> > 'sip:alice-l...@promethee.test.com-cbb99ea81711c30ed9c0edf6' for
> key 2
> > Apr 26 13:45:57 [20047] ERROR:presence:update_db_subs: unsuccessful
> > sql insert
> > Apr 26 13:46:01 [20045] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 13:46:01 [20045] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 13:46:11 [20045] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 13:46:11 [20045] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 13:46:21 [20045] ERROR:presence:get_stored_info: record not
> > foun

Re: [OpenSIPS-Users] avoid down time caused by mysql server connection lost

[Brad Bendy]

Hi,

Use db_virtual and have it write to a second mysql box or flat file,
works VERY well.

Then import the entries from flat file into mysql once it's back up and
your back in business, the switch will not crash if it loses connection
to mysql then.


On Wed, 2010-04-28 at 14:21 +0100, Julien Chavanton wrote:

> Hi, I have single point of failure for Opensips with siptrace and CDR,
> if the Mysql server is disconnected from the network opensip will stop
> working, I would rather continue to accept calls without storing
> CDR/trace or use a secondary mysql connection.
> 
> Is there any recommendation / best practice ?
> 
>  config
> 
> modparam("siptrace", "db_url",
> "mysql://login:passw...@x.x.x.x/opensips")
> 
> modparam("acc", "db_url", "mysql://login:passw...@x.x.x.x/opensips")
> 
>  log
> 
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]:
> INFO:core:handle_sigs: child process 4835 exited by a signal 11
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4844]:
> CRITICAL:core:receive_fd: EOF on 24
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]:
> INFO:core:handle_sigs: core was generated
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]:
> INFO:core:handle_sigs: terminating due to SIGCHLD
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4840]:
> INFO:core:sig_usr: signal 15 received
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4834]:
> INFO:core:sig_usr: signal 15 received
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4843]:
> INFO:core:sig_usr: signal 15 received
> Apr 28 12:28:34 osip /usr/local/sbin/opensips[4842]:
> INFO:core:sig_usr: signal 15 received
> 
> 
> ___
> 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

[OpenSIPS-Users] avoid down time caused by mysql server connection lost

[Julien Chavanton]

Hi, I have single point of failure for Opensips with siptrace and CDR, if the 
Mysql server is disconnected from the network opensip will stop working, I 
would rather continue to accept calls without storing CDR/trace or use a 
secondary mysql connection.

Is there any recommendation / best practice ?

 config

modparam("siptrace", "db_url", "mysql://login:passw...@x.x.x.x/opensips")

modparam("acc", "db_url", "mysql://login:passw...@x.x.x.x/opensips")

 log

Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]: INFO:core:handle_sigs: 
child process 4835 exited by a signal 11
Apr 28 12:28:34 osip /usr/local/sbin/opensips[4844]: CRITICAL:core:receive_fd: 
EOF on 24
Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]: INFO:core:handle_sigs: 
core was generated
Apr 28 12:28:34 osip /usr/local/sbin/opensips[4819]: INFO:core:handle_sigs: 
terminating due to SIGCHLD
Apr 28 12:28:34 osip /usr/local/sbin/opensips[4840]: INFO:core:sig_usr: signal 
15 received
Apr 28 12:28:34 osip /usr/local/sbin/opensips[4834]: INFO:core:sig_usr: signal 
15 received
Apr 28 12:28:34 osip /usr/local/sbin/opensips[4843]: INFO:core:sig_usr: signal 
15 received
Apr 28 12:28:34 osip /usr/local/sbin/opensips[4842]: INFO:core:sig_usr: signal 
15 received

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

Re: [OpenSIPS-Users] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Bogdan-Andrei Iancu]

Stanisław Pitucha wrote:
> On 28/04/10 11:40, Bogdan-Andrei Iancu wrote:
>   
>> So, right now the code for 2.0 got to a stage were we need to "apply" 
>> changes on the received messages (like adding VIA headers, changing 
>> headers, etc). And before starting the work on this area, I would like 
>> to get some opinions on the available options:
>>
>> 1) keep the current mechanism for changing the SIP messages by using 
>> lumps that are applied only when the message is sent out :
>> 
>
> The problem for me was that sometimes you want to change things that are
> affected by by previous calls you have to do. For example you cannot
> easily fix the contact and the apply a parameter to the end. You cannot
> put those 2 changes together, since one comes from the script logic and
> the other from the internal function. (problem I run into in the nat
> proxy - after masking I cannot add ;expires=...)
>   

yes, these are the most common problems - when you try to do 2 changes 
over the same text chunk...
>   
>> 2) find a new approach that will allow to push in realtime the 
>> changes on messages
>> 
>
> There's some middle ground here, where you can at least use fast string
> operations (yay - yet another string type!). I'm not sure if this would
> play well with custom allocators, but a couple of years ago I was using
> http://www.and.org/vstr/ - it promises modifications without realloc()
> calls (does something like lumps internally).
> Afair it was good quality and not modified for a long time.
> But you'd still have to find a way of quick reparsing the message...
> region invalidation, so you don't reparse more than needed?
> first-known-dirty, first-known-good pointers? Most people don't need
> reading the changes back really, so if you only marked the range of
> headers as invalid, it could create a nice lazy-reparsing solution.
>   
indeed - what I have in mind as solution will be splitting the message 
buffer into per-header buffer ; as changes will affect only 1 buffer 
(typically), you will have to re-generate only the buffer for a single 
header (and eventually re-parse it later, on demand).
This approach will limit the impact of the changes and the overhead will 
be less. On the other hand, ops over the entire message buffer (like 
search, replace) will not work anymore, but I do not consider this an 
issue as I think, in SIP, all ops should operate over headers - like the 
hdr is the brick of the SIP message and you should not start playing 
with what is between bricks ;)
>   
>> So this is the dilemma: if the current mechanism (with applying changes 
>> at the end) such a bad user experience (scripting) in order to try for 
>> 2.0 a different approach ?
>> 
>
> I like changing changes and I like the speed... hard choice. If partial
> reparsing is not realistic, maybe you could just approach it from a
> completely different prespective. Since the new routing is available
> from a normal programming language anyways, maybe just exporting the
> interface to lumps is enough? This way you could do the change of a
> change if you *really* wanted it.
> Or what the kama/s-r guys are doing - add a function that "flattens" the
> message and reparses it on request.
>   
yes, I'm aware of that approach, but I do not like it so much - I mean 
is a good hack that solved the problem is the easiest way, but not in 
the best ways because:
- you need (as script level) to be aware of the changes and to trigger 
the merging of the changes into the message - it is something too geek 
and low level for the script level - the script is about SIP. I'm afraid 
people will not have full understanding of that functionality and they 
will not used in the right places or will over-use it (abuse it)
- the penalty is really high - the whole buffer is regenerated and 
completely reparsed.

Regards,
Bogdan

> Stan
>
> ___
> 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] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Brett Nemeroff]

>From a user's perspective...
I can clearly see the need to pull information from the original message as
well as the "processed, unsent message". I'm aware of this issue, but I've
never ran into an issue where it's really been a problem. Typically, these
issues are resolved by instead of using something like message headers,
using previously set AVPs in the script. Maybe my assumption is from my lack
of running into the problem, but I *think* it can be resolved by smart
scriptwriting...

I don't know a whole lot about how the message is processed under the hood,
but.. from a user perspective, I'd rather change my scriptwriting to handle
these issues (assuming there is a way to mitigate the issue) than make an
architectural change that would overall impair performance and scalability.

-Brett


On Wed, Apr 28, 2010 at 5:40 AM, Bogdan-Andrei Iancu  wrote:

> Hi,
>
> sorry for crossposting, but I thing this topic is interesting both for
> users (as experience) and for developers (as solution).
>
> So, right now the code for 2.0 got to a stage were we need to "apply"
> changes on the received messages (like adding VIA headers, changing
> headers, etc). And before starting the work on this area, I would like
> to get some opinions on the available options:
>
>1) keep the current mechanism for changing the SIP messages by using
> lumps that are applied only when the message is sent out :
>   Advantages: code is there and works; the mechanism is very fast ;
> no need to re-parse the message after the parsing
>   Disadvantages : from script or code, you are not able to see the
> previous changes you did on the message, like:
> if you remove a hdr, it will be marked to be removed,
> but you will still see it there after the removed
> if you add a new hdr, you will not be able to see it
> (it will be actually added only when the message will be sent out)
> if you replace the contact hdr (like after
> fix_nated_contact() ) will not see the new contact, but the old one
> trying to apply 2 changes in the same area (like
> changing twice the contact) will result in bogus result.
>
>2) find a new approach that will allow to push in realtime the
> changes on messages
>   Advantages: the change will take affect instantly, so all the
> disadvantages from 1) (as user experience in operating opensips) will
> disappear .
>   Disadvantages : the code will probably be slower (the changes
> part), but will speed up other parts of the code (where you need to
> manually identify the prev changes);
> changed parts of the SIP message will require re-parsing
> (so the code will have to check the state of a header (if parsed or not)
> before each usage)
> you will not be able to undo changes on the SIP messages in
> an easy way (for example during the parallel and serial forking on
> per-branch changes)
>
> So this is the dilemma: if the current mechanism (with applying changes
> at the end) such a bad user experience (scripting) in order to try for
> 2.0 a different approach ?
>
> I would like to hear some opinions from both people writing scripts and
> people writing code.
>
> Thanks and regards,
> Bogdan
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
>
>
> ___
> 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] Issue with rls module?

[Andres2 Cores2]

Thank you Anca

In fact I am using the user-agent (picked it up from one config file),
either my client either opensips.
  if($hdr(User-Agent) =~ "me")
  {
xlog("L_DBG","RLS subscribe");
$var(ret_code)= rls_handle_subscribe();
 if($var(ret_code)== 10){
 handle_subscribe();
  }
   }
   else
   {
  xlog(" route 2 subscribe normal --- \n");
   handle_subscribe();
   }

Now, after some fixes of the configuration, it seems the flow is correctly
managed.
There is still one point I am not sure. I had some issues with the NOTIFY
sent by PS to RLS
that was not correctly managed and I fixed it by adding this condition for
NOTIFY

if ((is_method("SUBSCRIBE")||is_method("NOTIFY")) &&
$rd == "10.62.0.155") {
# in-dialog subscribe requests
route(2);
exit;
}

Where route(2) invokes rls_handle_notify() for NOTIFY requests.

Do you think it is fine? It is not perfectly clear what is called the
"in-dialog" subscribe requests.

Thanks for all.
Andrew


2010/4/28 Anca Vamanu 

> Hi Andrew,
>
> Thanks for your appreciation.
> The thing that you need to take care with RLS are the Subscribe messages
> sent by the RLS server ( because this is the mechanism - when receiving
> a Subscribe for RLS the rls server will send more Subscribe messages to
> the presence server, and I see that you have the presence server
> collocated with rls). You need to make sure that these are handled by
> the presence server and that they do not go into rls again. For this you
> can check the source of the message and if it is the same machine just
> call handle_subscribe.
>
> if(is_method("SUBSCRIBE") && si == "_local_ip_")
>handle_subscribe();
>
> If you watch the network trace and log where each subscribe goes for
> processing and still notice this errors, post again an email on the list.
>
> Regards,
>
> --
> Anca Vamanu
> www.voice-system.ro
>
>
>
>
> Andres2 Cores2 wrote:
> > Hi,
> >
> > First of all we would like to thank the whole opensips team. For
> > testing our client, we are mainly interested in the presence and rls
> > topics and found that a pretty good set of features is available right
> > now, so thanks for your job.
> >
> > During our tests we encountered an issue running opensips 1.6 in
> > rls-server mode (simple presence works fine). It seems to us it is
> > just a configuration issue or a bug in the routing rules, but we can't
> > find out it.
> >
> > From the client point of view I cannot succeed in receiving presence
> > Notify messages body, only rlmi parts are provided.
> >
> > In fact it seems rls_handle_subscribe has issues when trying to send
> > Subscribes to Presence on behalf of rls. I have systematically errors
> > "presence:get_stored_info: record not found in hash_table" and
> > sometimes "Duplicate entry
> > 'sip:alice-l...@promethee.test.com-cbb99ea81711c30ed9c0edf6' for key 2"
> >
> > Typically:
> > Apr 26 13:45:57 [20047] ERROR:db_mysql:db_mysql_do_prepared_query:
> > driver error: Duplicate entry
> > 'sip:alice-l...@promethee.test.com-cbb99ea81711c30ed9c0edf6' for key 2
> > Apr 26 13:45:57 [20047] ERROR:presence:update_db_subs: unsuccessful
> > sql insert
> > Apr 26 13:46:01 [20045] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 13:46:01 [20045] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 13:46:11 [20045] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 13:46:11 [20045] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 13:46:21 [20045] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 13:46:21 [20045] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 14:25:40 [20586] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 14:25:40 [20586] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 14:25:45 [20586] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 14:25:45 [20586] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 14:25:50 [20586] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 14:25:50 [20586] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 14:25:55 [20586] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 14:25:55 [20586] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 14:26:05 [20586] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 14:26:05 [20586] ERROR:presence:handle_subscribe: getting
> > stored info
> > Apr 26 14:26:09 [20586] ERROR:presence:get_stored_info: record not
> > found in hash_table
> > Apr 26 14:26:09 [20586] ERROR:presence:handle_subscribe: getting
> > stored info
> >
> > My m

Re: [OpenSIPS-Users] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Stanisław Pitucha]

On 28/04/10 11:40, Bogdan-Andrei Iancu wrote:
> So, right now the code for 2.0 got to a stage were we need to "apply" 
> changes on the received messages (like adding VIA headers, changing 
> headers, etc). And before starting the work on this area, I would like 
> to get some opinions on the available options:
> 
> 1) keep the current mechanism for changing the SIP messages by using 
> lumps that are applied only when the message is sent out :

The problem for me was that sometimes you want to change things that are
affected by by previous calls you have to do. For example you cannot
easily fix the contact and the apply a parameter to the end. You cannot
put those 2 changes together, since one comes from the script logic and
the other from the internal function. (problem I run into in the nat
proxy - after masking I cannot add ;expires=...)

> 2) find a new approach that will allow to push in realtime the 
> changes on messages

There's some middle ground here, where you can at least use fast string
operations (yay - yet another string type!). I'm not sure if this would
play well with custom allocators, but a couple of years ago I was using
http://www.and.org/vstr/ - it promises modifications without realloc()
calls (does something like lumps internally).
Afair it was good quality and not modified for a long time.
But you'd still have to find a way of quick reparsing the message...
region invalidation, so you don't reparse more than needed?
first-known-dirty, first-known-good pointers? Most people don't need
reading the changes back really, so if you only marked the range of
headers as invalid, it could create a nice lazy-reparsing solution.

> So this is the dilemma: if the current mechanism (with applying changes 
> at the end) such a bad user experience (scripting) in order to try for 
> 2.0 a different approach ?

I like changing changes and I like the speed... hard choice. If partial
reparsing is not realistic, maybe you could just approach it from a
completely different prespective. Since the new routing is available
from a normal programming language anyways, maybe just exporting the
interface to lumps is enough? This way you could do the change of a
change if you *really* wanted it.
Or what the kama/s-r guys are doing - add a function that "flattens" the
message and reparses it on request.

Stan

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

[OpenSIPS-Users] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Bogdan-Andrei Iancu]

Hi,

sorry for crossposting, but I thing this topic is interesting both for 
users (as experience) and for developers (as solution).

So, right now the code for 2.0 got to a stage were we need to "apply" 
changes on the received messages (like adding VIA headers, changing 
headers, etc). And before starting the work on this area, I would like 
to get some opinions on the available options:

1) keep the current mechanism for changing the SIP messages by using 
lumps that are applied only when the message is sent out :
   Advantages: code is there and works; the mechanism is very fast ; 
no need to re-parse the message after the parsing
   Disadvantages : from script or code, you are not able to see the 
previous changes you did on the message, like:
 if you remove a hdr, it will be marked to be removed, 
but you will still see it there after the removed
 if you add a new hdr, you will not be able to see it 
(it will be actually added only when the message will be sent out)
 if you replace the contact hdr (like after 
fix_nated_contact() ) will not see the new contact, but the old one
 trying to apply 2 changes in the same area (like 
changing twice the contact) will result in bogus result.

2) find a new approach that will allow to push in realtime the 
changes on messages
   Advantages: the change will take affect instantly, so all the 
disadvantages from 1) (as user experience in operating opensips) will 
disappear .
   Disadvantages : the code will probably be slower (the changes 
part), but will speed up other parts of the code (where you need to 
manually identify the prev changes);
 changed parts of the SIP message will require re-parsing 
(so the code will have to check the state of a header (if parsed or not) 
before each usage)
 you will not be able to undo changes on the SIP messages in 
an easy way (for example during the parallel and serial forking on 
per-branch changes)

So this is the dilemma: if the current mechanism (with applying changes 
at the end) such a bad user experience (scripting) in order to try for 
2.0 a different approach ?

I would like to hear some opinions from both people writing scripts and 
people writing code.

Thanks and regards,
Bogdan

-- 
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] Issue with rls module?

[Anca Vamanu]

Hi Andrew,

Thanks for your appreciation.
The thing that you need to take care with RLS are the Subscribe messages 
sent by the RLS server ( because this is the mechanism - when receiving 
a Subscribe for RLS the rls server will send more Subscribe messages to 
the presence server, and I see that you have the presence server 
collocated with rls). You need to make sure that these are handled by 
the presence server and that they do not go into rls again. For this you 
can check the source of the message and if it is the same machine just 
call handle_subscribe.

if(is_method("SUBSCRIBE") && si == "_local_ip_")
handle_subscribe();

If you watch the network trace and log where each subscribe goes for 
processing and still notice this errors, post again an email on the list.

Regards,

-- 
Anca Vamanu
www.voice-system.ro




Andres2 Cores2 wrote:
> Hi,
>
> First of all we would like to thank the whole opensips team. For 
> testing our client, we are mainly interested in the presence and rls 
> topics and found that a pretty good set of features is available right 
> now, so thanks for your job.
>
> During our tests we encountered an issue running opensips 1.6 in 
> rls-server mode (simple presence works fine). It seems to us it is 
> just a configuration issue or a bug in the routing rules, but we can't 
> find out it.
>
> From the client point of view I cannot succeed in receiving presence 
> Notify messages body, only rlmi parts are provided.
>
> In fact it seems rls_handle_subscribe has issues when trying to send 
> Subscribes to Presence on behalf of rls. I have systematically errors 
> "presence:get_stored_info: record not found in hash_table" and 
> sometimes "Duplicate entry 
> 'sip:alice-l...@promethee.test.com-cbb99ea81711c30ed9c0edf6' for key 2"
>
> Typically:
> Apr 26 13:45:57 [20047] ERROR:db_mysql:db_mysql_do_prepared_query: 
> driver error: Duplicate entry 
> 'sip:alice-l...@promethee.test.com-cbb99ea81711c30ed9c0edf6' for key 2
> Apr 26 13:45:57 [20047] ERROR:presence:update_db_subs: unsuccessful 
> sql insert
> Apr 26 13:46:01 [20045] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 13:46:01 [20045] ERROR:presence:handle_subscribe: getting 
> stored info
> Apr 26 13:46:11 [20045] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 13:46:11 [20045] ERROR:presence:handle_subscribe: getting 
> stored info
> Apr 26 13:46:21 [20045] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 13:46:21 [20045] ERROR:presence:handle_subscribe: getting 
> stored info
> Apr 26 14:25:40 [20586] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 14:25:40 [20586] ERROR:presence:handle_subscribe: getting 
> stored info
> Apr 26 14:25:45 [20586] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 14:25:45 [20586] ERROR:presence:handle_subscribe: getting 
> stored info
> Apr 26 14:25:50 [20586] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 14:25:50 [20586] ERROR:presence:handle_subscribe: getting 
> stored info
> Apr 26 14:25:55 [20586] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 14:25:55 [20586] ERROR:presence:handle_subscribe: getting 
> stored info
> Apr 26 14:26:05 [20586] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 14:26:05 [20586] ERROR:presence:handle_subscribe: getting 
> stored info
> Apr 26 14:26:09 [20586] ERROR:presence:get_stored_info: record not 
> found in hash_table
> Apr 26 14:26:09 [20586] ERROR:presence:handle_subscribe: getting 
> stored info
>
> My main settings for presence and rls modules are:
>
> modparam("presence|presence_xml", 
> "db_url","mysql://opensips:opensip...@localhost/opensips")
> modparam("presence", "server_address", "sip:p...@10.62.0.155:5060 
> ")
> modparam("presence", "clean_period",  30)
> modparam("presence_xml", "integrated_xcap_server", 1)
>
> modparam("pua", "db_url", 
> "mysql://opensips:opensip...@localhost/opensips")
>
> # -- rls parameters --
> modparam("rls","db_url", "mysql://opensips:opensip...@localhost/opensips")
> modparam("rls", "server_address", "sip:r...@10.62.0.155:5060 
> ")
> modparam("rls", "integrated_xcap_server", 1)
> modparam("rls", "xcap_root","http://promethee.test.com:/xcap-root"; )
> modparam("rls", "presence_server", "sip:p...@10.62.0.155:5060 
> ")
> modparam("rls", "to_presence_code", 10)
> modparam("xcap_client","periodical_query",1)
> modparam("xcap_client","query_period",10)
> modparam("xcap_client","db_url", 
> "mysql://opensips:opensip...@localhost/opensips")
>
> I can send you the routing rules if neeeded.
>
> Could you please help us?
>
> Many thanks
>
> Andrew
> 
>
> ___
> Users mailing list
> Users@lists.op

Re: [OpenSIPS-Users] OpenSIPS behind Static NAT (Amazon EC2)

[Bogdan-Andrei Iancu]

Hi Brendan,

So the ACK you receive is :

U 66.90.153.244:5060 -> 10.241.38.192:5060
ACK sip:7005551...@10.192.162.85 SIP/2.0.
Via: SIP/2.0/UDP  
192.168.1.103 
;rport;branch=z9hG4bKc0a8016701764bd73d74328807240306.
Content-Length: 0.
Call-ID: 993ae890-1dd1-11b2-9e7a-a4ef9db84...@192.168.1.103.
CSeq: 1 ACK.
From: "unknown";tag=10868511971184976398.
Max-Forwards: 70.
Route: .
To: ;tag=as47bd2a02.
User-Agent: SJphone/1.60.299a/L (SJ Labs).
.


where  10.192.162.85 is the Asterisk IP, right ?

and you mentioned that Opensips is looping this ACK - can you post also 
the ACK send out for the first time by opensips ?


Regards,
Bogdan

Brendan Sterne wrote:
> Greetings,
>
> I am experimenting with using OpenSIPS in Amazon EC2 to distribute  
> calls to Asterisk instances (also running in Amazon EC2).  The  
> challenge is that servers on Amazon EC2 have private IPs to  
> communicate with each other, but different public IPs when accessed  
> from without EC2.   Basically Amazon has a Static NAT setup that does  
> IP translation (but not port translation).  Amazon provides a public  
> DNS name that resolves to the public host IP outside of Amazon EC2,  
> and to the private host IP inside of Amazon EC2.
>
> I know that it is not recommended to use OpenSIPS behind a NAT, but  
> I'm curious if I can make this work.  Right now I'm focusing on  
> inbound calls, SIP call control only (I will use nathelper / rtpproxy  
> as necessary to help with media later).
>
> Here's the scenario for the invite:
> Soft Phone   ---> EC2 Firewall ->  OpenSIPS  -> Asterisk
>
> The INVITE,100,200 works fine - I have opensips redirect to the  
> Asterisk using
>rewritehostport();
> And I use record_route_preset() to record the Public DNS in the  
> route.  This will create a Route Set that will work both ways (from  
> the Soft Phone, and from the Asterisk).
>   record_route_preset()
>
> The problem I'm having is with the ACK.  It is being routed from the  
> Soft Phone to the OpenSIPS via it's Amazon DNS name 
> (ec2-204-236-245-16.compute-1.amazonaws.com 
> ), but the OpenSIPS isn't recognizing the name as a local alias.  I  
> have alias set:  alias="ec2-204-236-245-16.compute-1.amazonaws.com: 
> 5060", but the opensips log shows "Topmost URI is NOT myself" (you can  
> see more below).  I have attached my config, logs, and a sip trace.
>
> Any suggestions are appreciated.
>
>
> My setup
> ===
>
> SJPhone, behind NAT, private IP: 192.168.1.103, public IP: 66.90.153.244
> Opensips, Amazon EC2, DNS ec2-204-236-245-16.compute-1.amazonaws.com,  
> private IP 10.241.38.192, public IP 204.236.245.16
> Asterisk, Amazon EC2, DNS ec2-204-236-221-166.compute-1.amazonaws.com,  
> private IP 10.192.162.85, public IP 204.236.221.166
>
>
> My opensips.cfg
> =
>
> debug=9
> log_stderror=no
> log_facility=LOG_LOCAL0
> fork=yes
> children=4
> port=5060
> advertised_address="ec2-204-236-245-16.compute-1.amazonaws.com"
> alias="ec2-204-236-245-16.compute-1.amazonaws.com:5060"
>
> mpath="/usr/local/lib/opensips/modules/"
> loadmodule "db_mysql.so"
> loadmodule "signaling.so"
> loadmodule "sl.so"
> loadmodule "tm.so"
> loadmodule "rr.so"
> loadmodule "maxfwd.so"
> loadmodule "usrloc.so"
> loadmodule "textops.so"
> loadmodule "mi_fifo.so"
> loadmodule "uri.so"
> loadmodule "xlog.so"
>
> loadmodule "mi_xmlrpc.so"
> loadmodule "dialplan.so"
> loadmodule "nathelper.so"
> modparam("mi_xmlrpc", "port", 8000)
> modparam("mi_xmlrpc", "log_file", "/var/log/abyss.log")
> modparam("dialplan", "db_url", "mysql://:@localhost/ 
> opensips")
> modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock")
>
> modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
> modparam("rr", "enable_full_lr", 1)
> modparam("rr", "append_fromtag", 0)
> modparam("uri", "use_uri_table", 0)
>
> route{
>
>   xlog("L_INFO","CVAPP: route($rm/$du/$fu/$tu)");
>
>  if (!mf_process_maxfwd_header("10")) {
>  sl_send_reply("483","Too Many Hops");
>  exit;
>  }
>
>
>  if (!has_totag()) {
>
>  xlog("L_INFO","CVAPP:   initial request");
>
>  # CANCEL processing
>  if (is_method("CANCEL"))
>  {
>  if (t_check_trans())
>  t_relay();
>  exit;
>  }
>
>  t_check_trans();
>
>  # record routing
>  if (!is_method("REGISTER|MESSAGE")) {
>  xlog("L_INFO","CVAPP:   recording route");
>  
> record_route_preset("ec2-204-236-245-16.compute-1.amazonaws.com 
> ");
>  }
>
>  # requests for my domain
>  if (uri==myself)
>  {
>  sl_send_reply("503", "Service Unavailable");
>  exit;
>  }
>
>  route

Re: [OpenSIPS-Users] UPDATE message and sdp

[Bogdan-Andrei Iancu]

For such cases (SDP negotiation via 200OK + ACK), see the "s" flag in 
the force_rtp_proxy() function:
 http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id271384

Also, you are saying that has_body(sdp) does not work on the ACK ? can 
you post the ACK request you test?

Regards,
Bogdan

Daniel Goepp wrote:
> One follow up on this...and this pains me...I have a gateway that 
> calls us with no SDP on the INVITE, then we send back a 200 OK w/SDP, 
> and it then sends back an ACK with SDP.  Now I believe that although 
> very uncommon, does not violate the spec.  However in this case, I see 
> that the rtpproxy_answer is set on the 200 OK reply, but the 
> if(has_body("application/sdp")) has no affect on the ACK.  I'm sure 
> I'm missing something here so any thoughts on the matter are greatly 
> appreciated.
>
> Thanks
>
> -dg
>
>
> On Tue, Apr 27, 2010 at 2:56 PM, Daniel Goepp  > wrote:
>
> And just after replying regarding my success (I have been running
> this for many months now without problems), I do have a very
> specific issue related to UPDATE messages.
>
> I have added some logging and for the following call, I get:
>
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> Request UPDATE: sip:2021@:5069 -
> sip:6502734...@192.168.1.110:5060;transport=tcp
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> Setting rtpproxy_offer - Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> Fixing Contact - Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> Relay message
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]:
> new branch route 1 at sip:2021@:5069  -
> sip:6502734101@:33774;transport=tcp
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> incoming reply route 1 -  - sip:2...@192.168.1.101:5069
> 
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> Found a response from a private address! -
> sip:2...@192.168.1.101:5069 
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]:
> Setting rtpproxy_answer - Reply 1
> Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]:
> INFO:handle_command: lookup on ports 30882/29328, session timer
> restarted
> Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]:
> INFO:handle_command: lookup on ports 31198/28836, session timer
> restarted
>
> Which to me looks like it is identifying that it needs to fix the
> SDP, but then in the outbound UPDATE the connection IP is still
> the private address.  See trace below.  The signaling seems okay
> otherwise, and the experience that I get is that the endpoint
> being called to (2021) can no longer see the calling party (we are
> testing video).  The 200 OK coming back does not have this
> problem, it's connection IPs in the SDP are rewritten fine, making
> me think perhaps it's something related to just UPDATE message,
> but I don't know enough about the inner workings of OpenSIPS. 
> Thoughts?
>
> Thanks
>
> -dg
>
> 
> 2010-04-27 14:45:49
> tcp::33774 -> tcp::5060
>
> UPDATE sip:2021@:5069 SIP/2.0
> Via: SIP/2.0/TCP
> 192.168.1.110:5060;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport
> Call-ID: 4fdbf3351f217...@192.168.1.110
> 
> CSeq: 104 UPDATE
> Contact: 
> From:  >;tag=7ad977f50f0f9d94
> To: "Daniel Goepp"  >;tag=DC151CA5-80A23EC4
> Max-Forwards: 70
> Route: ;lr;transport=tcp;transport=tcp>
> Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
> User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)
> Proxy-Authorization: Digest nonce="*", realm="mydomain.com
> ", username="6502734101",
> uri="sip:mydomain.com ", response="***",
> algorithm=MD5
> Supported: replaces,100rel,timer,gruu,path,outbound
> Session-Expires: 500;refresher=uac
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 455
>
> v=0
> o=tandberg 17 2 IN IP4 192.168.1.110
> s=-
> c=IN IP4 192.168.1.110
> b=CT:768
> t=0 0
> m=audio 2354 RTP/AVP 100 102
> c=IN IP4 192.168.1.110
> b=TIAS:64000
> a=rtpmap:100 G7221/16000
> a=fmtp:100 bitrate=32000
> a=rtpmap:102 telephone-event/8000
> a=fmtp:102 0-15
> a=sendrecv
> m=video 2356 RTP/AVP 97
> b=TIAS:768000
> a=rtpmap:97 H264/9
> a=fmtp:97
> profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
> a=sendrecv
>  

Re: [OpenSIPS-Users] UPDATE message and sdp

[Bogdan-Andrei Iancu]

Hi Daniel,

Are you doing force_rtp_proxy for the UPDATE request?

Regards,
Bogdan

Daniel Goepp wrote:
> And just after replying regarding my success (I have been running this 
> for many months now without problems), I do have a very specific issue 
> related to UPDATE messages.
>
> I have added some logging and for the following call, I get:
>
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: 
> Request UPDATE: sip:2021@:5069 - 
> sip:6502734...@192.168.1.110:5060;transport=tcp
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: 
> Setting rtpproxy_offer - Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: 
> Fixing Contact - Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: 
> Relay message
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: new 
> branch route 1 at sip:2021@:5069  - 
> sip:6502734101@:33774;transport=tcp
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: 
> incoming reply route 1 -  - sip:2...@192.168.1.101:5069 
> 
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: 
> Found a response from a private address! - sip:2...@192.168.1.101:5069 
> 
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: 
> Setting rtpproxy_answer - Reply 1
> Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]: INFO:handle_command: 
> lookup on ports 30882/29328, session timer restarted
> Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]: INFO:handle_command: 
> lookup on ports 31198/28836, session timer restarted
>
> Which to me looks like it is identifying that it needs to fix the SDP, 
> but then in the outbound UPDATE the connection IP is still the private 
> address.  See trace below.  The signaling seems okay otherwise, and 
> the experience that I get is that the endpoint being called to (2021) 
> can no longer see the calling party (we are testing video).  The 200 
> OK coming back does not have this problem, it's connection IPs in the 
> SDP are rewritten fine, making me think perhaps it's something related 
> to just UPDATE message, but I don't know enough about the inner 
> workings of OpenSIPS.  Thoughts?
>
> Thanks
>
> -dg
>
> 
> 2010-04-27 14:45:49
> tcp::33774 -> tcp::5060
>
> UPDATE sip:2021@:5069 SIP/2.0
> Via: SIP/2.0/TCP 
> 192.168.1.110:5060;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport
> Call-ID: 4fdbf3351f217...@192.168.1.110 
> 
> CSeq: 104 UPDATE
> Contact: 
> From:  >;tag=7ad977f50f0f9d94
> To: "Daniel Goepp"  >;tag=DC151CA5-80A23EC4
> Max-Forwards: 70
> Route: ;lr;transport=tcp;transport=tcp>
> Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
> User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)
> Proxy-Authorization: Digest nonce="*", realm="mydomain.com 
> ", username="6502734101", uri="sip:mydomain.com 
> ", response="***", algorithm=MD5
> Supported: replaces,100rel,timer,gruu,path,outbound
> Session-Expires: 500;refresher=uac
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 455
>
> v=0
> o=tandberg 17 2 IN IP4 192.168.1.110
> s=-
> c=IN IP4 192.168.1.110
> b=CT:768
> t=0 0
> m=audio 2354 RTP/AVP 100 102
> c=IN IP4 192.168.1.110
> b=TIAS:64000
> a=rtpmap:100 G7221/16000
> a=fmtp:100 bitrate=32000
> a=rtpmap:102 telephone-event/8000
> a=fmtp:102 0-15
> a=sendrecv
> m=video 2356 RTP/AVP 97
> b=TIAS:768000
> a=rtpmap:97 H264/9
> a=fmtp:97 
> profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
> a=sendrecv
> a=content:main
> a=label:11
>
> 
> 2010-04-27 14:45:49
> udp::5060 -> udp::5069
>
> UPDATE sip:2021@:5069 SIP/2.0
> Record-Route: ;lr;transport=tcp>
> Via: SIP/2.0/UDP ;branch=z9hG4bK7e7f.ef3c6013.0;i=9
> Via: SIP/2.0/TCP 
> 192.168.1.110:5060;received=;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport=33774
> Call-ID: 4fdbf3351f217...@192.168.1.110 
> 
> CSeq: 104 UPDATE
> Contact: :33774;transport=tcp>
> From:  >;tag=7ad977f50f0f9d94
> To: "Daniel Goepp"  >;tag=DC151CA5-80A23EC4
> Max-Forwards: 69
> Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
> User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)
> Proxy-Authorization: Digest nonce="*", realm="mydomain.com 
> ", username="6502734101", uri="sip:mydomain.com 
> ", response="", algorithm=MD5
> Supported: replaces,100rel,timer,gruu,path,outbound
> Session-Expires: 500;refresher=uac
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 455
>
> v=0
> o=tandberg 17 2 IN IP4 192.168.1.110
> s=-
> c=IN IP4 192.168.1.1

Re: [OpenSIPS-Users] Supporting unsolicited Notify

[Bogdan-Andrei Iancu]

Hi Aditya,

If the NOTIFY is a part of an ongoing call (sequential request), it 
should be routed based on route set information - the opensips default 
script takes care of this part (via loose_route-ing)...

Maybe you can post a SIP trace of the call with such NOTIFY.

Regards,
Bogdan


Aditya Kumar wrote:
> Hi All,
>
> I am planning to use open sip for my application.can you pl tell if 
> the following is supported or not?
>
>
> The opensips will act as a proxy server.
> My clients will be talking using open sip to a external proxy.
> once the call is established, external proxy will send the NOTIFY as 
> part of the call.
>
> As there is no Associated subscription,
> is there a  way I can set/Make the Opensips to forward the message 
> received from the proxy to the clients?
>
> pl let me know if I am not clear
>
>
> TIA.
>
>
> 
>
> ___
> 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] Strange errors forwarding requests

[Bogdan-Andrei Iancu]

Hi Erik,

Try to log in opensips the destination (as $ru and $du) to see where 
opensips tries to send the failing INVITEs - maybe there are some bogus 
IPs.

Regards,
Bogdan

Erik Versaevel wrote:
> Hi all,
>
> I'm building a setup in which opensips is acting as registar for my endpoints 
> and loadbalancing
> calls made by those endpoint over an cluster of asterisk machines. (so that 
> if we need more asterisk
> power, we just have to add another destination to the loadbalancer module)
> Opensips is listening on multiple IP addresses and uses the loadbalancer 
> module to poll my asterisk
> machines and select the destination.
> My problem is that every now and then opensips fails to forward an invite to 
> my asterisk cluster and
> generates
>
>   "ERROR:core:udp_send: sendto(sock,0x77b81280,1353,0,0x77b81b04,16): 
> Operation not permitted(1)"
>
> there is some iptables filtering on this machine, however it is not showing 
> drops in the logfile (and it keeps
> occuring even without any iptable rules).
> I tried stracing opensips but all i get is:
>
>   opensipstrace.7423:sendto(6, "INVITE 
> sip:e164_dst_phone...@opensips_ip_address SIP/2.0
>   Record-Route: 
> 
>   Via: SIP/2.0/UDP OPENSIPS_IP_ADDRESS;branch=z9hG4bK3177.1e0e38b7.0
>   Via: SIP/2.0/UDP 
> 192.168.178.44:5060;received=CPE_IP_ADDRESS;rport=61008;branch=z9hG4bK2010Apr222938466E164_DST_PHONE_NR
>   To: 
>   From: \"3961\" ;tag=AI05ED431A05432EB8
>   Call-ID: aif001c45e85f79...@192.168.178.44
>   CSeq: 2 INVITE
>   Max-Forwards: 69
>   Contact: 
>   Accept: application/sdp
>   Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER
>   Allow-Events: dialog,message-summary
>   P-Preferred-Identity: 
>   Privacy: none
>   User-Agent: SomeStrangeDude
>   Content-Type: application/sdp
>   Content-Length: 324
>   I-FromDisp: 
>   I-FromUri: E164PHONE_NR
>   I-CustId: 3961
>   
>   v=0
>   o=intelligate 1133701155 1133701155 IN IP4 192.168.178.44
>   s=call
>   c=IN IP4 CPE_IP_ADDRESS
>   t=0 0
>   m=audio 5004 RTP/AVP 18 8 101
>   a=rtpmap:18 G729/8000
>   a=fmtp:18 annexb=no
>   a=rtpmap:8 PCMA/8000
>   a=rtpmap:101 telephone-event/8000
>   a=fmtp:101 0-15
>   a=sendrecv
>   a=ptime:20
>   a=direction:active
>   a=oldmediaip:192.168.178.44
>   ", 1253, 0, {sa_family=AF_INET, sin_port=htons(5060), 
> sin_addr=inet_addr("ASTERISK_IP_ADDRESS")}, 16) = -1 EPERM (Operation not 
> permitted)
>
> I also use the uac_replace_from() to mangle the from header so asterisk uses 
> the correct user/peer/client to connect the call (codec/dialplan etc).
> I'm having trouble reproducing the error as it's not allways occuring, the 
> errors i straced where mainly the initial invite towards my asterisk
> cluster and a few 200 OK's which didn't get processed correctly.
>
> Any clues on how to debug this further?
>
> Kind regards,
>
> Erik Versaevel
>
>
>
>
> ___
> 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] Are there in OpenSIPS modules like AGI on asterisk ?

[Bogdan-Andrei Iancu]

Hi Sam,

OpenSIPS can be remotely provisioned only via DB and MI (Management 
Interface) commands - so you need to adapt your scripts to this. If you 
need help on how to do certain ops, let me know.

Regards,
Bogdan


samoh wrote:
> Hi everybody,
>
> I'm working on a project OpenSIPS which involves replacing the existing
> Asterisk servers on the enterprise to OpenSIPS but I am confronting a
> problem, I will absolutely not change the basic patterns of current data,
> yet I managed to make a script that periodically retrieves the data needed
> for authentication and saves them in the subscriber table, I'd like to know
> is there a way to get scripts like that for AGI with asterisk which allows
> me to use the same scripts already present on asterisk or modified.
>
> Best regards.
> Sam.
>   


-- 
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] Info about rtpproxy and opensips working together on different hosts...

[Bogdan-Andrei Iancu]

Hi Roberto,

I checked the RTPproxy code and the only case where you get the 
"ERR:handle_command: can't create listener " error without any previous 
error is for cases:
- the system user you are running rtpproxy as, does not have 
permission to bind on the listening IP (- l option in rtpproxy)
- you already have another application (like Asterisk) already using 
the same listening IP and port range as configured in RTPProxy.

Regards,
Bogdan

Roberto Ovani wrote:
> Il giovedì 22/04/10 18.37, Laszlo ha scritto:
>>
>>
>> 2010/4/22 Roberto Ovani > >
>>
>> Il mercoledì 21/04/10 14.30, Laszlo ha scritto:
>>>
>>>
>>> 2010/4/21 Roberto Ovani >> >
>>>
>>> Il mercoledì 21/04/10 13.49, Laszlo ha scritto:
 gcc -v
>>> _The host with OPENSIPS :
>>> _Using built-in specs.
>>> Target: i486-linux-gnu
>>> Configured with: ../src/configure -v
>>> --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
>>> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
>>> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
>>> --enable-shared --enable-multiarch --enable-linker-build-id
>>> --with-system-zlib --libexecdir=/usr/lib
>>> --without-included-gettext --enable-threads=posix
>>> --with-gxx-include-dir=/usr/include/c++/4.4
>>> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu
>>> --enable-libstdcxx-debug --enable-objc-gc
>>> --enable-targets=all --disable-werror --with-arch-32=i486
>>> --with-tune=generic --enable-checking=release
>>> --build=i486-linux-gnu --host=i486-linux-gnu
>>> --target=i486-linux-gnu
>>> Thread model: posix
>>> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
>>> _
>>> The host with RTPPROXY : _
>>> Using built-in specs.
>>> Target: i486-linux-gnu
>>> Configured with: ../src/configure -v
>>> --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
>>> --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
>>> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
>>> --enable-shared --with-system-zlib --libexecdir=/usr/lib
>>> --without-included-gettext --enable-threads=posix
>>> --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
>>> --program-suffix=-4.3 --enable-clocale=gnu
>>> --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
>>> --enable-targets=all --enable-checking=release
>>> --build=i486-linux-gnu --host=i486-linux-gnu
>>> --target=i486-linux-gnu
>>> Thread model: posix
>>> gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) _
>>>
>>> _Thanks in advance
>>> Roberto
>>>
>>>
>>> By default it will compile with -O2 optimization. Can you
>>> recompile it with -O0
>>> Please run CFLAGS=-O0 ./configure, then make and make install
>>> and restart rtpproxy.
>>>
>>> -Laszlo
>>>
>>>  
>>>
>>
>>
>> I'm having problems with all: opensips-rtpproxy etc...
>> so, I'm trying to show my system  :
>> *
>> 1st LOCATION *:
>> Wan Side : opensips.roberto.org  
>> (it's not real, but for example)
>> Lan Side, there are:
>> - opensips server (i forwarded 5060 udp to Opensips-server's lan
>> address)
>> - a sip client on a laptop, user 1003 (sjphone for mac)
>>
>> *2nd LOCATION* :
>> Wan Side : rtpproxy.roberto.org 
>> Lan side, there are :
>> - RtpProxy server (i forwarderd 7890udp to RTPPRoxy-Server's lan
>> address, and also the range between udp 1 and udp 64999, to
>> be sure)
>> - a sip client, user 1002 (X-Lite for windows)
>>
>> *3rd LOCATION (home-sweet-home)* :
>> In the Lan, there's a Sip client, user 1000 (Sjphone on my macbook)
>>
>> In attachment, there's my opensips.cfg.
>>
>> I need to create a system that can make call everyone to
>> everyother (independently from WHERE the clients ARE, if in the
>> same lan as servers, or behind nats, etc... )
>>
>> Could you please tell me some example cfg code for this purpose?
>>
>> If you need, I also have logs from Opensips-server-host and from
>> RTPProxy-host (var/log/syslog) and a bit of tcpdump. This log
>> refers to a call from 1000 to 1003 and from 1003 to 1000.
>>
>> I used the one from Gonçalves' Book (about opensips 1.6), but I'm
>> having problems I'm also a newbie, so it's still a bit hard
>> for me to have a complete vision of everything in this voip
>> system
>>
>>
>> Thanks in advance
>> Roberto
>>
>>
>> Did you recompile rtpproxy like how I mentioned?
>> BTW, I have found something, maybe it can be interesting for you 
>> too(and can be related to your problem):
>>
>> http://www.mail-archive.com/us...@rtpproxy.org/msg00113.html
>>

Re: [OpenSIPS-Users] CDRTool Rating: Does not rate some calls

[Mike O'Connor]

Hi Adrian
>>
>> Where as a call to 132221 (ie the special) is rated as '
>> diverted-on-net' and is displayed as
>> 132...@sip.xxx.xx.xx
>
> This means that in your OpenSIPS configuration login did not set
> correctly the CanonicalURI.
>
Ok taking your explaination above I edited the CanonicalURI to say
0061132...@sip.xxx.xx.xx. This correctly rated the call.

So my next question is this, why does 0884567532 and rewritten correctly
to 0061884567532 and 132221 not.

What does the rewriting ?

Thanks
Mike

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

Re: [OpenSIPS-Users] OpenSIPS and SIP source routing

[Bogdan-Andrei Iancu]

yes, as using dialplan module, you can create some rule to automatically 
translate from the DOMAIN of the incoming call to the IP of the 
corresponding Asterisk:


if (!db_translate("1","$rd/$rd")) {
send_reply("404","domain not found");
exit;
}
t_relay();


and try  
http://www.opensips.org/html/docs/modules/1.6.x/dialplan.html#id227156  
with 1.4.1.4. String conversion (equal detection, replacement).

Regards,
Bogdan

Labus wrote:
> Little less...
>
> In my issue I have some organizations in OCS (each organization have self
> sip domain and self PSTN GW).
>
> All calls from OCS go to OpenSIPS (through OCS Mediation). I don't use TEL
> URI instead SIP URI, so OpenSIPS receive something like this:
> us...@domain1.loc, us...@domain1.loc, us...@domain1.loc and all these users
> I need routed to Asterisk1 (PSTN-GW1), but if OpenSIPS receive
> us...@domain35.loc (other sip domain) I need routed this call to other
> Asterisk35 (PSTN-GW35).
>
> route{
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483","Too Many Hops");
> exit;
> };
> if (msg:len >=  2048 ) {
> sl_send_reply("513", "Message too big");
> exit;
> };
> if (loose_route())
> {
> append_hf("P-hint: rr-enforced\r\n");
> route(1);
> };
> if (is_method("PUBLISH|SUBSCRIBE|NOTIFY|REGISTER"))
> {
> sl_send_reply("501", "Method $rm not implemented");
> exit;
> };
>
> if (src_ip==X.X.X.X)    FROM OCS SERVER
> {
> xlog("Request from OCS \n");
> remove_hf("Contact");
> append_hf("P-hint: outbound\r\n");
> if($rm=="INVITE" && uri=="us...@domain1.loc")
> {
> sethostport("A.A.A.A:5060");   ###  PSTN-GW1 
> xlog("***");
> xlog("DOMAIN1 outbound call from OCS.\n");
> xlog("From uri=[$fu]\n");
> xlog("Request's method=[$rm]\n");
> xlog("Request's uri=[$ru]\n");
> xlog("To uri=[$tu]\n");
> xlog("***");
> if (!t_relay("udp:A.A.A.A:5060"))
> {
> sl_reply_error();
> };
> exit;
>}
>else  if($rm=="INVITE" && uri=="us...@domain35.loc")
>{
> sethostport("B.B.B.B:5060");   ###  PSTN-GW35
> xlog("***");
> xlog("DOMAIN35 outbound call from OCS.\n");
> xlog("From uri=[$fu]\n");
> xlog("Request's method=[$rm]\n");
> xlog("Request's uri=[$ru]\n");
> xlog("To uri=[$tu]\n");
> xlog("***");
> if (!t_relay("udp:B.B.B.B:5060"))
> {
> sl_reply_error();
> };
> exit;
>};
> }
> else# When incoming call from PSTN-GW NN route this to OCS throught
> route1
> {
> route(1);
> };
> }
>
>
> route[1] {
> # When incoming call from PSTN-GW NN route this to OCS
> sethostport("X.X.X.X:5060");
> if (!t_relay("tcp:X.X.X.X:5060")) {
> sl_reply_error();
> };
> exit;
> }
>
> onreply_route {
> xlog("-REPLY-");
> xlog("Reply route");
> xlog("From uri=[$fu]\n");
> xlog("Request's method=[$rm]\n");
> xlog("Request's uri=[$ru]\n");
> xlog("To uri=[$tu]\n");
> xlog("IP source=[$src_ip]\n");
> xlog("---");
> exit;
> }
>
>   


-- 
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] Opensips 1.6.2 w/ Control Panel 4.0 - Problem w/ CDRViews and Dialog

[Alex Ionescu]

Hi Erick,

The global db.inc.php (the one you have in /var/www/opensips-cp/config/) 
is used by all the modules as long as they don't find something more 
specific defined into their config files (like, for example, if you want 
a different db setup for module *domains* you can edit 
*/var/www/opensips-cp/config/tools/system/domains/db.inc.php* - and this 
will override the global db setup ).


Dialog takes the call information using a MI command. So you must have 
OpenSIPS Control Panel and OpenSIPS configured properly (you must choose 
between xmlrpc and fifo) - see the OpenSIPS config file (to enable 
mi_xmlrpc module or the mi_fifo) and also check the 
config/boxes.global.inc.php to have the correct MI connection parameters 
set up.


Regards,
Alex
On 4/27/2010 18:24, Erick Chinchilla Berrocal wrote:


FYI

According the manual

http://opensips-cp.sourceforge.net/ Dialog Module (dialog)

one option is change the setup in the file

/opensips-cp/config/tools/system/dialog/db.inc.php

in the configuration I don't have this file only those following. 
Please confirm if need the file "db.inc.php"


/etc/opensips# ls -al /var/www/opensips-cp/config/tools/system/dialog/

total 16

drwxr-xr-x  2 www-data www-data 4096 2010-04-26 13:46 .

drwxr-xr-x 16 www-data www-data 4096 2010-04-26 11:49 ..

-rw-r--r--  1 www-data www-data 1243 2010-03-08 12:54 local.inc.php

-rw-r--r--  1 www-data www-data 1094 2010-03-08 12:54 menu.inc.php

Look this file in the other modules and get. In the 
modules.../tools/...  are in default setup


/etc/opensips# find / -name db.inc.php

/var/www/opensips-cp/config/tools/admin/add_admin/db.inc.php

/var/www/opensips-cp/config/tools/admin/list_admins/db.inc.php

/var/www/opensips-cp/config/tools/users/user_management/db.inc.php

/var/www/opensips-cp/config/tools/users/alias_management/db.inc.php

/var/www/opensips-cp/config/tools/system/smonitor/db.inc.php

/var/www/opensips-cp/config/tools/system/cdrviewer/db.inc.php

/var/www/opensips-cp/config/tools/system/permissions/db.inc.php

/var/www/opensips-cp/config/tools/system/domains/db.inc.php

/var/www/opensips-cp/config/tools/system/loadbalancer/db.inc.php

/var/www/opensips-cp/config/tools/system/drouting/db.inc.php

/var/www/opensips-cp/config/tools/system/siptrace/db.inc.php

/var/www/opensips-cp/config/tools/system/pdt/db.inc.php

/var/www/opensips-cp/config/tools/system/nathelper/db.inc.php

/var/www/opensips-cp/config/tools/system/dialplan/db.inc.php

/var/www/opensips-cp/config/tools/system/dispatcher/db.inc.php

/var/www/opensips-cp/config/db.inc.php

- Now, I understand that if only changed this file is ok for all 
modules, can you confirm if is correct


o /var/www/opensips-cp/config/db.inc.php

§ //database driver mysql or pgsql

§  $config->db_driver = "mysql";

§

§  //database host

§  $config->db_host = "localhost";

§

§  //database port - leave empty for default

§  $config->db_port = "";

§

§  //database connection user

§  $config->db_user = "root";

§

§  //database connection password

§  $config->db_pass = "password for root";

§

§  //database name

§  $config->db_name = "opensips";

§

§  if (!empty($config->db_port) ) $config->db_host = $config->db_host 
. ":" . $config->db_port;


I want to test the "Opensips-Control Panel" but for the modules "CDR 
Views" and "Dialog" don't get any information, the same with the 
module "SIPTrace"


Her you can help me I appreciate it

Thanks

Erick Ch.

*From:* users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Erick 
Chinchilla Berrocal

*Sent:* Monday, April 26, 2010 11:35 AM
*To:* 'OpenSIPS users mailling list'
*Subject:* [OpenSIPS-Users] Opensips 1.6.2 w/ Control Panel 4.0 - 
Problem w/ CDRViews and Dialog


FYI

I tried to get (look) the calls in the modules CDRViewer and Dialog 
and not is possible.


The following files have the default configuration and the MySQL 
tables is according the script.


/var/www/opensips-cp/config/tools/system/cdrviewer/local.inc.php

/var/www/opensips-cp/config/tools/system/dialog/local.inc.php

This is the configuration for the modules in the file opensips.cfg

#

loadmodule "db_mysql.so"

loadmodule "signaling.so"

loadmodule "sl.so"

loadmodule "tm.so"

loadmodule "rr.so"

loadmodule "maxfwd.so"

loadmodule "usrloc.so"

loadmodule "registrar.so"

loadmodule "textops.so"

loadmodule "mi_fifo.so"

loadmodule "uri.so"

loadmodule "xlog.so"

loadmodule "acc.so"

#

# - usrloc params -

/* uncomment the following lines if you want to enable DB persistency

   for location entries */

modparam("usrloc", "db_mode",   2)

modparam("usrloc", "db_url",

"mysql://opensips:opensip...@localhost/opensips")

modparam("usrloc", "use_domain", 1)

modparam("usrloc", "nat_bflag", 3)

modparam("usrloc", "user_column", "username")

modparam("usrloc", "domain_column", "domain")

modparam("usrloc", "contact_column", "contact")

modparam("usrloc", "expires_column", "expires")

modparam("usrloc", "q_co

Re: [OpenSIPS-Users] Version of OpenSIPS CP

[Alex Ionescu]

Hi Sergio,

You are free to choose between 3.0 and 4.0. But I'd go with the latest 
version -> 4.0


Regards,
Alex
On 4/27/2010 20:26, Sergio Gutierrez wrote:

Hello all.

What version of OpenSIPS Control panel Should I use with OpenSIPS 1.5.X?

Thanks and regards.

--
Sergio Gutiérrez


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



--
Alex Ionescu
www.voice-system.ro

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

Re: [OpenSIPS-Users] Opensip-cp and xml-rpc-c question

[Alex Ionescu]

Hi Sven,

For your first question :
"Can I use mi_datagram instead of mi_xmlrpc for opensips-cp? "
Well, it is not suported ... yet. So, unfortunately, you cannot use 
mi_datagram.


For the second question :
"If not, how to I compile xml-rpc-c into Centos5?"
We've recently installed CP and OpenSIPS on a Centos 5 server. We've 
used *xmlrpc-c-1.06.38*
To install it please do : *./configure --disable-abyss-threads* (this is 
very important) ... then you do as usual *make all* and *make install*.


I hope you will succeed eventually !

Regards,
Alex



On 4/27/2010 22:58, Sven Schulz wrote:

2 part Question:

   1. Can I use mi_datagram instead of mi_xmlrpc for opensips-cp?
   2. If not, how to I compile xml-rpc-c into Centos5?


I cant compile the recommended version (.09.10) into 64bit.
If I download the latest SRC, I get these errors at the end of MAKE:

/usr/bin/ld: XmlRpcCpp.o: relocation R_X86_64_32 against `a local 
symbol' can not be used when making a shared object; recompile with -fPIC

XmlRpcCpp.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [libxmlrpc_cpp.so.3.06] Error 1
make[2]: Leaving directory `/usr/src/xmlrpc-c-1.06.38/src/cpp'
make[1]: *** [cpp/all] Error 2
make[1]: Leaving directory `/usr/src/xmlrpc-c-1.06.38/src'
make: *** [src/all] Error 2


Any help would be appreciated.


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



--
Alex Ionescu
www.voice-system.ro

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

Re: [OpenSIPS-Users] cdrtool: looking in the wrong location for radacct table when mysql on the same IP address?

[Paul Wise]

On Wed, 2010-04-28 at 08:47 +0200, Adrian Georgescu wrote:

> It could be that the php mysql library on your system has a bug and is  
> confusing the connection. What system and version libraries are you  
> using?

I'm using the 5.0.4/lenny release of Debian GNU/Linux with these:

php5 5.2.6
php5-mysql 5.2.6
libmysqlclient 5.0.51a
mysql-server 5.0.51a
cdrtool 7.1.1
opensips 1.6

-- 
bye,
pabs

http://bonedaddy.net/pabs3/


signature.asc
Description: This is a digitally signed message part
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] dialog module

[wüber]

Hi Richard,

great! it works fine!
Thank you Bogdan, I have realized now that I can not bind Opensips on
0.0.0.0!

Thanks a lot both for your posts.

Carmelo
-- 
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/dialog-module-tp4967644p4973123.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