[OpenSIPS-Users] Automated Testing Scenario with OpenSIPS

Nick Khamis symack at gmail.com
Wed Mar 20 00:04:52 CET 2013


If you want to learn SIP, learn OpenSIPS :). Good luck on your project!

N.

On 3/19/13, Pink Cupcake <pinkcupcake1979 at gmail.com> wrote:
> You're in the ballpark, Nick. I'm working on a design for a new system that
> includes a SIP component, and while I'd prefer if the end-to-end solution
> stuck with UDP, there are some technical reasons why TCP may be required,
> and it's not something I'd be able to work around.
>
> So far OpenSIPS has been relatively easy to work with and so I'm continuing
> my experiments with it, while a colleague is investigating Kamailio. I may
> stick with OpenSIPS irrespective of what my colleague goes ahead with,
> simply because I want a SIP server solution that will be the easiest to use
> in an automated testing environment -- my goal being to test a SIP user
> agent and not to care much about the server side.
>
> -PKCK
>
>
> On Tue, Mar 19, 2013 at 3:34 PM, Nick Khamis <symack at gmail.com> wrote:
>
>> Hello PKCK,
>>
>> I am not sure but I can only think of a few reasons why you would like
>> to run SIP on the TCP protocol, and none that are even good reasons as
>> that. Are you sure you need to run OpenSIPS on TCP? UDP should suffice
>> 99% pf the time. I take it you're just experimenting.
>>
>> N.
>>
>> On 3/19/13, Pink Cupcake <pinkcupcake1979 at gmail.com> wrote:
>> > It looks like I answered my question almost immediately after sending
>> > my
>> > last message (of course!) -- I was invoking opensips thusly:
>> >
>> > ./sbin/opensips -D -f
>> > /path/to/opensips/1.8.2/opensips-with-local-changes.cfg
>> >
>> > I just read that OpenSIPS will not be able to listen on more than one
>> > interface unless it forks, and since it always must listen on UDP, it
>> will
>> > skip listening on TCP if it must.
>> >
>> > It looks like the -D parameter prevents OpenSIPS from forking, which
>> means
>> > no TCP port connection; if I run that command without the -D, TCP
>> > connections seem to work.
>> >
>> > Of course I liked using -D because it made it easy to start/stop
>> > OpenSIPS
>> > (just with a ^C). I'm assuming that "daemon mode" means it's going to
>> leave
>> > a pid file around somewhere to make it easier to skill using a shell
>> > (or
>> > shell script), so I'm off to find out if that's the case.
>> >
>> > -PKCK
>> >
>> >
>> > On Tue, Mar 19, 2013 at 2:45 PM, Pink Cupcake
>> > <pinkcupcake1979 at gmail.com>wrote:
>> >
>> >> Thanks, Nick. I'm having a read through it now.
>> >>
>> >> I fixed my initial problem, though, and it was a pretty silly mistake:
>> >> I
>> >> had OpenSIPS and my SIP client (Jitsi) both using the same port. Oops!
>> >> I
>> >> switched Jitsi over to ports 55060/55061 and then things started
>> working.
>> >>
>> >> Working, at least with UDP. I need to get TCP working now.
>> >>
>> >> The default configuration file has TCP disabled. Searching for
>> >> information
>> >> on how to set up TCP is quite difficult. The PDF you linked to has a
>> >> few
>> >> tips, luckily. But not enough to get it working.
>> >>
>> >> Here's a portion of my config file:
>> >>
>> >> #listen=udp:127.0.0.1:5060   # CUSTOMIZE ME
>> >> listen=udp:172.16.23.79:5060   # CUSTOMIZE ME
>> >> listen=tcp:172.16.23.79:5060   # CUSTOMIZE ME
>> >> #disable_tcp=yes
>> >> disable_tcp=no
>> >> tcp_children=4
>> >>
>> >> When I try to connect with Jitsi, or with telnet, and sniff the
>> >> traffic
>> >> with Wireshark, I can see a SYN sent from Jitsi->OpenSIPS and a
>> >> RST/ACK
>> >> returned, but that's it. I don't think the TCP connection is getting
>> >> properly established, and Jitsi bails out saying it can't create a
>> >> connection.
>> >>
>> >> Jitsi does successfully connect to OpenSIPS if I set the proxy
>> >> transport
>> >> setting to UDP in Jitsi.
>> >>
>> >> What do I need to do to take OpenSIPS, from out of the box, and get it
>> to
>> >> accept REGISTERs/INVITEs on TCP and not UDP?
>> >>
>> >> -PKCK
>> >>
>> >>
>> >>
>> >> On Fri, Feb 8, 2013 at 4:49 PM, Nick Khamis <symack at gmail.com> wrote:
>> >>
>> >>> Pink,
>> >>>
>> >>> A great resource that can get you up and going in at most a week can
>> >>> be found here:
>> >>>
>> >>>
>> >>>
>> >>>
>> http://www.google.com/url?q=http://www.h6315.com/ast_book/Building%2520Telephony%2520Systems%2520with%2520OpenSIPS%25201.6.pdf&sa=U&ei=AJ0VUdahEvG10AGl4IDIDA&ved=0CB8QFjAA&sig2=q5gYZ0W2OeVVhS-YaZ0xjg&usg=AFQjCNFrbF0lgZG6kcTaZwI5uu-azQSx-w
>> >>>
>> >>> Happy Routing!
>> >>>
>> >>> Nick.
>> >>>
>> >>> On 2/8/13, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > On 02/08/2013 12:17 AM, Pink Cupcake wrote:
>> >>> >> Hi Bogdan-Andrei,
>> >>> >>
>> >>> >> Your response really doesn't help me or deal with the questions I
>> >>> >> laid
>> >>> >> out in my original post. Perhaps I was not being clear. Let me
>> >>> >> start
>> >>> >> over.
>> >>> >>
>> >>> > Well, my answer was related to the error logs you posted :).
>> >>> >
>> >>> >>
>> >>> >>
>> >>> >> I need to implement an automated testing scenario on an OS X build
>> >>> >> machine.
>> >>> >>
>> >>> >> The test requires two different SIP UAs -- which are both running
>> >>> >> locally on the same machine -- to successfully engage in a SIP
>> >>> >> call. In order for two UAs to talk to one another, they need to be
>> >>> >> registered with a SIP server.
>> >>> >>
>> >>> >> I am trying to determine if OpenSIPS can be used as the server
>> >>> >> component in my testing scenario.
>> >>> >>
>> >>> >> Since this is an integration test and doesn't require any state
>> being
>> >>> >> retained, the test steps look like this: (1) bring up an OpenSIPS
>> >>> >> server in userspace, (2) have the two SIP UA clients register with
>> >>> >> that server, as simply as possible, (3) have the two SIP UA
>> >>> >> clients
>> >>> >> engage in and then end a SIP call, (4) stop the SIP UA clients,
>> >>> >> (5)
>> >>> >> shut down the server.
>> >>> >>
>> >>> >> If anything is unclear from the above, please reply back.
>> >>> > Clear and no issues here,
>> >>> >
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> Please can someone answer the following:
>> >>> >>
>> >>> >> If I can run OpenSIPS in userspace, I would also not like to have
>> >>> >> it
>> >>> >> "installed" on the build machine. I used the "prefix" parameter to
>> >>> >> `make install` into a separate directory and I am attempting to
>> >>> >> run
>> >>> >> OpenSIPS from that directory.
>> >>> >>  It looks like I can run OpenSIPS in userspace. Is that correct?
>> >>> > true
>> >>> >>
>> >>> >> From the documentation is looks like OpenSIPS does not use a
>> database
>> >>> >> by default, and keeps everything in memory. Is that correct?
>> >>> > true
>> >>> >>
>> >>> >> Can any SIP UA client "REGISTER" with OpenSIPS when it is launched
>> in
>> >>> >> the "default" mode? If so, is there any special way the clients
>> >>> >> should
>> >>> >> send the request?
>> >>> > if using the opensips default script, no authentication will be
>> >>> > required
>> >>> > - but you need to use in the REGISTER RURI the IP of the server (so
>> >>> > that
>> >>> > opensips will consider them be handled locally).
>> >>> >>
>> >>> >> If it is necessary for OpenSIPS to be run with a database in order
>> to
>> >>> >> allow clients to register? If so, will the db_text module suffice?
>> If
>> >>> >> so, how do I perform this configuration (given my testing
>> >>> >> scenario)?
>> >>> > no, no need for DB - by default, in cfg, the usrloc module comes
>> >>> > with
>> >>> > no
>> >>> > DB support.
>> >>> >
>> >>> > Regards,
>> >>> > Bogdan
>> >>> >>
>> >>> >>
>> >>> >> PKCK
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> On Thu, Feb 7, 2013 at 5:13 AM, Bogdan-Andrei Iancu
>> >>> >> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>> >>> >>
>> >>> >>     Hi,
>> >>> >>
>> >>> >>     Without a trace I cannot tell for sure, but I suspect your
>> >>> >> clients
>> >>> >>     send several REGISTER requests without increasing the CSEQ no
>> >>> >>     (which is mandatory) - this is the meaning of the error you
>> >>> >> get.
>> >>> >>
>> >>> >>     So, to be sure, make a network capture with the sip traffic
>> >>> >>     (ngrep) and see what are the replies from opensips.
>> >>> >>
>> >>> >>     Regards,
>> >>> >>
>> >>> >>     Bogdan-Andrei Iancu
>> >>> >>     OpenSIPS Founder and Developer
>> >>> >>     http://www.opensips-solutions.com
>> >>> >>
>> >>> >>
>> >>> >>     On 02/07/2013 12:01 AM, Pink Cupcake wrote:
>> >>> >>>     Hello,
>> >>> >>>
>> >>> >>>     I'm investigating the suitability of OpenSIPS for use in a
>> >>> >>> new
>> >>> >>>     system we are designing. Not only for use in a production
>> >>> >>>     environment, but also how it can be used to facilitate
>> automated
>> >>> >>>     integration tests.
>> >>> >>>
>> >>> >>>     I have a automated testing scenario where I need to have two
>> SIP
>> >>> >>>     UAs that need to have a SIP session. What I would like to do
>> >>> >>> is
>> >>> >>>     bring up a SIP server (in userspace) before the integration
>> test
>> >>> >>>     starts, and bring it down after the integration test ends
>> >>> >>>     (fails/succeeds). The automated test will run on OS X.
>> >>> >>>
>> >>> >>>     I downloaded OpenSIPS and built it on my iMac without any
>> >>> >>> major
>> >>> >>>     problems. I am able to run it in userspace simply by calling
>> >>> >>> it
>> >>> >>>     from the command line like `/sbin/opensips -D -f
>> >>> >>>     /path/to/opensips.cfg`.
>> >>> >>>
>> >>> >>>     In section D of the INSTALL file, "opensips with Persistent
>> Data
>> >>> >>>     Storage", it says:
>> >>> >>>
>> >>> >>>     "The default configuration is very simple and features many
>> >>> >>>     simplifications.
>> >>> >>>     In particular, it does not authenticate users and loses User
>> >>> >>>     Location database
>> >>> >>>     on reboot. To provide persistence, keep user credentials and
>> >>> >>>     remember users'
>> >>> >>>     locations across reboots, opensips can be configured to use
>> >>> >>>     MySQL. Before you
>> >>> >>>     proceed, you need to make sure MySQL is installed on your
>> >>> >>> box."
>> >>> >>>
>> >>> >>>     This sounds ideal to me; I don't need any real kind of
>> >>> >>> account
>> >>> >>>     management or authentication. I would like OpenSIPS to start,
>> >>> >>>     accept whatever REGISTER/INVITE from my two UAs, and then
>> >>> >>> stop
>> >>> >>>     after I'm done. I would prefer not to require any database
>> >>> >>> and
>> >>> >>>     keep it all in-memory, so there's nothing to clean up before
>> >>> >>> or
>> >>> >>>     after the test (and no other dependencies to clean up before
>> and
>> >>> >>>     after, e.g. MySQL databases).
>> >>> >>>
>> >>> >>>     However, I can't seem to connect a SIP UA client to OpenSIPS
>> >>> >>> when
>> >>> >>>     it's started up like this. I am trying to connect with Jitsi,
>> >>> >>> a
>> >>> >>>     Mac client, as well as the ipjsua test app that ships with
>> >>> >>> the
>> >>> >>>     pjsip C library. (I am able to connect both of those to the
>> >>> >>>     sip2sip.info <http://sip2sip.info> service, so I know they
>> >>> >>> are
>> >>> >>>     both functional.)
>> >>> >>>
>> >>> >>>     With Jitsi, I set up a SIP account with Advanced settings
>> >>> >>>     (username: test1, password: test1, display name: test1,
>> >>> >>>     registrar: 127.0.0.1, port: 5060, manual proxy configuration,
>> >>> >>>     proxy: 127.0.0.1, port: 5060).
>> >>> >>>
>> >>> >>>     Log output from opensips in Console.app looks like this:
>> >>> >>>
>> >>> >>>     13-02-06 1:48:21.934 PM opensips: WARNING:core:warn: warning
>> >>> >>> in
>> >>> >>>     config file /path/to/opensips-with-local-changes.cfg, line
>> >>> >>> 50,
>> >>> >>>     column 13-16: tls support not compiled in
>> >>> >>>     13-02-06 1:48:22.010 PM opensips: WARNING:core:main: no fork
>> >>> >>> mode
>> >>> >>>     13-02-06 1:48:22.011 PM opensips: NOTICE:core:main: version:
>> >>> >>>     opensips 1.8.2-notls (x86_64/darwin)
>> >>> >>>     13-02-06 1:48:22.013 PM opensips: NOTICE:signaling:mod_init:
>> >>> >>>     initializing module ...
>> >>> >>>     13-02-06 1:50:58.328 PM opensips:
>> >>> >>>     ERROR:registrar:update_contacts: invalid cseq for aor <test1>
>> >>> >>>     13-02-06 1:51:02.335 PM opensips:
>> >>> >>>     ERROR:registrar:update_contacts: invalid cseq for aor <test1>
>> >>> >>>     13-02-06 1:51:06.342 PM opensips:
>> >>> >>>     ERROR:registrar:update_contacts: invalid cseq for aor <test1>
>> >>> >>>     ...
>> >>> >>>
>> >>> >>>     With ipjsua/pjsip, I use the following configuration
>> >>> >>> switches:
>> >>> >>>
>> >>> >>>     --id sip:test1 at 127.0.0.1 <mailto:sip%3Atest1 at 127.0.0.1>
>> >>> >>>     --registrar sip:127.0.0.1
>> >>> >>>     --realm *
>> >>> >>>     --username test1
>> >>> >>>     --password test1
>> >>> >>>     --nameserver 127.0.0.1
>> >>> >>>     --outbound sip:127.0.0.1
>> >>> >>>
>> >>> >>>     Log output in Console.app looks the same as with Jitsi except
>> >>> >>> for
>> >>> >>>     the "invalid cseq" lines:
>> >>> >>>
>> >>> >>>     13-02-06 1:56:39.004 PM opensips:
>> >>> >>>     ERROR:registrar:update_contacts: invalid cseq for aor <>
>> >>> >>>
>> >>> >>>
>> >>> >>>     What do I need to do to run OpenSIPS in userspace, have it
>> >>> >>> accept
>> >>> >>>     connections from my two SIP UAs, allow them to call each
>> >>> >>> other,
>> >>> >>>     and do it all without requiring a database running?
>> >>> >>>
>> >>> >>>     Do I absolutely require a database? If so, can someone
>> >>> >>> explain
>> >>> >>>     how to configure the db_text module to work for my testing
>> >>> scenario?
>> >>> >>>
>> >>> >>>     Thanks!
>> >>> >>>
>> >>> >>>
>> >>> >>>     _______________________________________________
>> >>> >>>     Users mailing list
>> >>> >>>     Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>> >>> >>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>



More information about the Users mailing list