Re: [OpenSIPS-Users] 3.2.11 vs 3.2.10 authorization

[Maxim Sobolev]

Should be fixed here, thanks for reporting:

https://github.com/OpenSIPS/opensips/commit/d71fbacea6557cc9532e1ac894e41d12800f8e69

Please test and let me know if the problem persists.

Regards,

Maksym

On Wed, Mar 15, 2023 at 9:36 AM Gabe Shepard via Users <
users@lists.opensips.org> wrote:

> Hi,
>We've run into this as well.  Doing a git bisect appears to point to
> commit 72610573a637f1bad60ba07061e05d1652cb93e0 which is related to qop
> validation.  If it helps, I've been testing with a Polycom VVX 450 running
> firmware 6.4.3.
>
> -Gabe
>
> On Tue, Mar 14, 2023 at 4:39 PM Callum Guy  wrote:
>
>> Hi Matt,
>>
>> You are not alone, I have just performed the same update and ran into the
>> same problem!
>>
>> No config changes, just an opensips package update on a CentOS 7 server.
>>
>> My only lead so far is the server referring to a stale nonce in its
>> reply, this may be a red herring as I reverted so quickly I don't have much
>> data!
>>
>> SIP/2.0 401 Unauthorized
>> Via: SIP/2.0/WSS
>> 4dd4fgrikg9v.invalid;received=99.100.77.236;rport=59260;branch=z9hG4bK2984131
>> To: > >;tag=8dca.7f4e487b9989bf9b0212db1e9a1410a8
>> From: ;tag=ad8qlo9gaq
>> Call-ID: 2cjev1ph5gr0m2337tur
>> CSeq: 3 REGISTER
>> WWW-Authenticate: Digest realm="fr-1.rtc.example.net",
>> nonce="j9+Qf6N87TeziTRHnWacqtUl3wCf8nvD2I9jm21q+48A", *stale=true*
>> Content-Length: 0
>>
>> I'll set up a test lab tomorrow and see if I can get to the bottom of it
>> and will continue to follow this thread.
>>
>> Good luck,
>>
>> Callum
>>
>> On Tue, 14 Mar 2023 at 13:05, L S  wrote:
>>
>>> Hi,
>>>
>>> We are trying to upgrade from Opensips 3.2.10 to 3.2.11, but we are
>>> running to an issue with registrations. It's the same server, same opensips
>>> cfg file, but 3.2.10 allows/authorizes the registrations, but 3.2.11
>>> returns 401 Unauthorized.
>>>
>>> The code that checks the credentials is:
>>>
>>> if (is_method("REGISTER|SUBSCRIBE")) {
>>>$avp(password)="xyz";
>>>if (!pv_www_authorize("")) {
>>>www_challenge("");
>>>exit;
>>>   };
>>> consume_credentials();
>>> }
>>>
>>> Again it's same code, the same physical server. What might be causing
>>> this?
>>>
>>> Thanks,
>>> Matt
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>>
>> *0333 332   |  x-on.co.uk   |   **
>>    
>>    **  |  **Practice Index Reviews
>> *
>>
>> *Our new office address: 22 Riduna Park, Melton IP12 1QT.*
>>
>> X-on is a trading name of Storacall Technology Ltd a limited company
>> registered in England and Wales.
>> Registered Office : Glebe Farm, Down Street, Dummer, Basingstoke,
>> Hampshire, England RG25 2AD. Company Registration No. 2578478.
>> The information in this e-mail is confidential and for use by the
>> addressee(s) only. If you are not the intended recipient, please notify
>> X-on immediately on +44(0)333 332  and delete the
>> message from your computer. If you are not a named addressee you must not
>> use, disclose, disseminate, distribute, copy, print or reply to this email. 
>> Views
>> or opinions expressed by an individual
>> within this email may not necessarily reflect the views of X-on or its
>> associated companies. Although X-on routinely screens for viruses,
>> addressees should scan this email and any attachments
>> for viruses. X-on makes no representation or warranty as to the absence
>> of viruses in this email or any attachments.
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
> *Gabe Shepard*
> *Architect, Advanced Applications*
> Phone: 941 960-8205
> Email: gshep...@sangoma.com
> Website: www.sangoma.com
> [image: Facebook]  [image: Linkedin]
>  [image: Twitter]
>  [image: Youtube]
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] RTPProxy Docker Image

[Maxim Sobolev]

Liviu has done some exploration on getting things handled on Kubernetes.
His great presentation is available here:
https://youtu.be/JwO0UmauuT4?t=13034

-Max

On Wed, Dec 21, 2022, 5:04 PM Terrance Devor  wrote:

> Hello David, Similar to what we have with LXC
>
> OpenSIPS - Proxy, Edge Switch, Managing DIDs and Termination routes, CDR,
> LB to Asterisk
> Asterisk - PBX, IVR
> RTPProxy - Media Relay
>
> Everything containerized using docker and deployed to our k8s cluster.
>
> I would appreciate speaking to anyone that has experience in successfully,
> or failed, in trying to do this
>
> On Wed, Dec 21, 2022 at 7:57 PM David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
>> Can you explain more? I.e: params and such?
>> Thanks!
>>
>> On Tue, 20 Dec 2022 at 22:29, Saint Michael  wrote:
>>
>>> Opensips+ RTPProxy only works fine with plain LXC containers,
>>> privileged, which basically have access to all the resources of the
>>> box.
>>> That is the model I use with great success.
>>>
>>> On Tue, Dec 20, 2022 at 2:47 PM Brett Nemeroff 
>>> wrote:
>>> >
>>> > Hello Terrance,
>>> > I wouldn't really recommend this. RTPProxy is going to use a lot of
>>> ports in a very large range. That just doesn't work great in docker, but
>>> even worse in K8S.
>>> >
>>> > I personally would put the RTPProxy outside of K8S. While you might be
>>> able to get it to work, you are likely going against some basic design
>>> concepts in containerization. I feel like the tech should propel the
>>> solution and not be a hindrance to it. In this case, I'm not sure that K8S
>>> is buying you anything of value, but instead creating architectural
>>> challenges.
>>> >
>>> > I'd love to hear feedback or experiences from others. There's always
>>> something to learn :)
>>> > -Brett
>>> >
>>> > On Tue, Dec 20, 2022 at 11:43 AM Terrance Devor 
>>> wrote:
>>> >>
>>> >> Was it something I said?
>>> >>
>>> >> Terrance
>>> >>
>>> >> On Sun, Dec 18, 2022 at 12:50 PM Terrance Devor 
>>> wrote:
>>> >>>
>>> >>> Hello Everyone,
>>> >>>
>>> >>> Wow! Blast from the past... I am a long time member of this list,
>>> been a while.
>>> >>>
>>> >>> Question, anyone successful in deploying RTPProxy to a dockerized
>>> environment? Preferably to a Kubernetes managed environment.
>>> >>>
>>> >>> Please Help Team :)
>>> >>>
>>> >>> Kind Regards,
>>> >>> Terrance
>>> >>
>>> >> ___
>>> >> 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
>>>
>> --
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.w...@gmail.com
>> phone: +34669448337
>> ___
>> 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] nonce password

[Maxim Sobolev]

Richard, as part of the RFC8760 work we've changed nonce algorithm to be
more secure and do not expose as much info to a potential attacker starting
with 3.1. It also prevents qop/algorithm "downgrade" attacks on a stateless
proxy. But as Bogdan pointed out, there are some options to ignore
validation of nonce and just verify digest, which might provide some help
in your situation.

-Maksym


On Wed, Nov 2, 2022, 11:18 AM Richard Revels via Users <
users@lists.opensips.org> wrote:

> If I set a nonce password on a opensips 3.x proxy and the same one on
> opensips 2.x proxy it is expected behaviour that it still wont match if
> call starts on opensips 2, is challenged, then INVITE is sent to opensips 3
> proxy?
>
>
>
> [image: BandwidthMaroon.png]
>
>
>
> Richard Revels  •  System Architect II
>
> 900 Main Campus Drive, Suite 100, Raleigh, NC 27606
>
>
>
> m: 919-578-3421  •  o: 919-727-4614
>
> e: rrev...@bandwidth.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] opensips 3.2.2 Segfault on debian 11 bullseye

[Maxim Sobolev]

Merged here, thanks for reporting:

https://github.com/OpenSIPS/opensips/commit/3f9fb0923207e320a27926433f50e0c39a1c643c
(master)
https://github.com/OpenSIPS/opensips/commit/83fee1c7a42f6d01b8d770088728791a03727b6
(3.2)

-Max

On Mon, Sep 27, 2021 at 12:46 PM Rob Dyck  wrote:

> Thank you
> With the patch applied I can confirm that the users are registering
> without
> incident..
> Rob
>
> On Monday, September 27, 2021 10:52:15 A.M. PDT Maxim Sobolev wrote:
> > Hi Rob / Liviu,
> >
> > I browsed quickly through the code and I think the following clause may
> be
> > a culprit:
> >
> > if (calc_ha1) {
> > /* Only plaintext passwords are stored in database,
> >  * we have to calculate HA1 */
> > cprms.creds.open = &(const struct
> digest_auth_credential){
> > .realm = *_domain, .user = _username->whole, .passwd
> =
> > result};
> > cprms.use_hashed = 0;
> > }
> >
> > Compiler might deallocate / overwrite struct digest_auth_credential after
> > exiting that block causing subsequent call to auth_api.calc_HA1() to
> access
> > bogus pointer.
> >
> > Rob, can you try applying the following commit and recompile/reinstall
> the
> > module in question and see if it helps?
> >
> >
> https://github.com/sippy/opensips/commit/fea6a1d60d70f64971dff3ec2dc83f7ddc0
> > 0389d
> >
> > Thanks!
> >
> > -Max
> >
> > On Mon, Sep 27, 2021 at 12:48 AM Liviu Chircu 
> wrote:
> > > On 27.09.2021 03:56, Rob Dyck wrote:
> > > > I am seeing the same. opensips-3.2.2 compiled from git source on
> Fedora.
> > >
> > > Thank you for the help, gents!  Let's see if I can reproduce it...
> > > should be fairly straightforward.
> > >
> > > Best,
> > >
> > > --
> > > Liviu Chircu
> > > www.twitter.com/liviuchircu | www.opensips-solutions.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] opensips 3.2.2 Segfault on debian 11 bullseye

[Maxim Sobolev]

Hi Rob / Liviu,

I browsed quickly through the code and I think the following clause may be
a culprit:

if (calc_ha1) {
/* Only plaintext passwords are stored in database,
 * we have to calculate HA1 */
cprms.creds.open = &(const struct digest_auth_credential){
.realm = *_domain, .user = _username->whole, .passwd =
result};
cprms.use_hashed = 0;
}

Compiler might deallocate / overwrite struct digest_auth_credential after
exiting that block causing subsequent call to auth_api.calc_HA1() to access
bogus pointer.

Rob, can you try applying the following commit and recompile/reinstall the
module in question and see if it helps?

https://github.com/sippy/opensips/commit/fea6a1d60d70f64971dff3ec2dc83f7ddc00389d

Thanks!

-Max

On Mon, Sep 27, 2021 at 12:48 AM Liviu Chircu  wrote:

> On 27.09.2021 03:56, Rob Dyck wrote:
> > I am seeing the same. opensips-3.2.2 compiled from git source on Fedora.
>
> Thank you for the help, gents!  Let's see if I can reproduce it...
> should be fairly straightforward.
>
> Best,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.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] Reading contents of a file - OpenSIPS 3.1

[Maxim Sobolev]

Who doubted it?! I personally think db_text is absolutely brilliant, cuts
devtesting effort 10x easily.

-Max

On Fri., Nov. 13, 2020, 7:31 a.m. johan,  wrote:

> And so is the usefulness of db_text proven :-)
> On 13/11/2020 16:06, Ovidiu Sas wrote:
>
> Take a look at db_text and sql_cacher modules!
>
> Regards,
> Ovidiu Sas
>
> On Fri, Nov 13, 2020 at 09:50 Mark Allen  wrote:
>
>> Just would like to consult the hive mind. I want to read the contents of
>> a multi-line text file to be used by my OpenSIPS config. Ideally, I'll get
>> a key:value CSV pair from the file and store each pair in memcache - e.g.
>>
>> file contains:
>>
>> a, 113
>> b, 214
>> c, 771
>>
>> read it in line by line and cache_store() with the letter as the
>> attribute and the number as the value.
>>
>> I was thinking that I could use exec() to 'cat' the contents of the file,
>> storing stdout in an AVP, and then work through that array splitting letter
>> and number with a string transformation ready for cache_store(). However,
>> if I do this the full file contents are stored as a single string in the
>> first value with "#012" added in place of the new lines.
>>
>> Obviously, I can use a string transform s.select{} using #012 as a
>> delimiter in an intermediary step, but am I just doing this the hard way?
>> Is there a better way to achieve this?
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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] Reading contents of a file - OpenSIPS 3.1

[Maxim Sobolev]

Use app_python? Parsing is trivial and you can call internal function
i.e. cache_store()
right from your Python code.

-Max

On Fri., Nov. 13, 2020, 6:50 a.m. Mark Allen,  wrote:

> Just would like to consult the hive mind. I want to read the contents of a
> multi-line text file to be used by my OpenSIPS config. Ideally, I'll get a
> key:value CSV pair from the file and store each pair in memcache - e.g.
>
> file contains:
>
> a, 113
> b, 214
> c, 771
>
> read it in line by line and cache_store() with the letter as the attribute
> and the number as the value.
>
> I was thinking that I could use exec() to 'cat' the contents of the file,
> storing stdout in an AVP, and then work through that array splitting letter
> and number with a string transformation ready for cache_store(). However,
> if I do this the full file contents are stored as a single string in the
> first value with "#012" added in place of the new lines.
>
> Obviously, I can use a string transform s.select{} using #012 as a
> delimiter in an intermediary step, but am I just doing this the hard way?
> Is there a better way to achieve this?
> ___
> 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] SIP Chronicles, recap and upcoming episode on Friday @ 7pm UTC

[Maxim Sobolev]

OOPS, typo, the link to Sandro's episode is below:

https://youtu.be/6EKVDyAx2Yo

-Max

On Thu, Nov 5, 2020 at 11:01 AM Maxim Sobolev  wrote:

> Hey SipTubies,
>
> Just a quick recap: if you missed any of latest episodes of SIP Chronicles
> here we go:
>
> Very interesting historical-looking firegrill-side chat with Paul Kyzivat
> of IETF: https://youtu.be/kvLuJhsnF-c
>
> Great conversation with Sandro Gauci (SIPVicious, Enable Security) about
> recent developments: https://youtu.be/kvLuJhsnF-c
>
> For #12 I think we'll do something different: turn the lens around and do
> a live coding / testing / whatever jam session with Turbomax at controls
> doing all 3 of those things at once as well as answering questions from the
> audience. The official goal is to benchmark our RFC8760 implementation
> under simulated fire and see how it fares to the old-good master branch
> with the sub-target to measure a relative drop/increase of peak performance
> of processing digest auth. In the process I expect to get OpenSIPS up
> flying at x00,000 CPS altitude and land it safely at few improvements.
>
> Some pics of the workhorse we are going to bench with are attached, this
> is a small but mighty 8-core Xeon-D 1541 with 64GB of ECC RAM. We'll see if
> simulated fire erupts into a real one. We will go over the process of
> setting up OpenSIPS on Ubuntu 20.x and using either
> https://github.com/sippy/b2bua or https://github.com/sobomax/microsippy
> or combination of both to source incoming traffic and measure latency.
>
> https://youtu.be/SYzqka4I34M
>
> Bring your own beer, snacks - it's going to be a long session and see you
> tomorrow. :)
>
> -Max
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Thanks for the great online event!

[Maxim Sobolev]

Hey folks, just wanted my gratitude to everyone who made OpenSIPS
Distributed Summit 2020 such a great event! Org team, presenters, viewers:
without any of you it won't be possible!! I look forward to seeing you all
in person eventually, but also I hope we now be able to continue doing this
more often in an online format of one form or another as well.

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

Re: [OpenSIPS-Users] OpenSips Summit 2020 Recordings

[Maxim Sobolev]

Yes, everything is going to be streamed live on YouTube OpenSIPS channel
and recordings will be freely available there afterwards.

-Max

On Tue., Aug. 25, 2020, 2:32 a.m. Grant Bagdasarian, <
grantbagdasar...@gmail.com> wrote:

> Hi all,
>
> Will the sessions be recorded and made available online?
>
> Regards,
>
> Grant
> ___
> 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] Sylk Mobile

[Maxim Sobolev]

Interesting work Adrian! Any chance you can be interested in coming over to
our SIP Chronicles videocast to talk about it and perhaps do a live demo? 

https://www.youtube.com/playlist?list=PL-U7hOT8zFXoSMgHLfVj_CX4MvFjD2gcj

Let me know, we don't have anyone booked yet for this coming Saturday.

Thanks!

-Max

-Max

On Thu., Aug. 6, 2020, 11:07 p.m. Adrian Georgescu, 
wrote:

> Hi,
>
> We just published Sylk Mobile, a react-native mobile client for Android
> and iOS.
>
> The server side is running OpenSIPS + Janus.
>
>
> https://lists.ag-projects.com/pipermail/sipbeyondvoip/2020-August/003469.html
>
> Enjoy!
> Adrian
>
> ___
> 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 Workshop at Cluecon

[Maxim Sobolev]

Hey OpenSIPS Users, if you missed it here is a nice session about 3.1
features: https://www.youtube.com/watch?v=nTbzISzIr6U

Thanks Bogdan and Razvan great overview of the Calling API and some
interesting details about media exchange at the end!

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

[OpenSIPS-Users] SIP Chronicles Episode #8, featuring Vasilios Tzanoudakis

[Maxim Sobolev]

Dear All,

Thank you once again for your interest in our series. It's time for a new
episode, tomorrow we are going to have Vasilios Tzanoudakis with us.

Myself, Giovanni and Denis know Vasilios for number of years, he always
been very active and curious participant of the OpenSIPS Summits. Very
technical and fun to interact with.

Vasilious is going to talk about his experience starting and growing his
VoIP company from 2011 till present day and about getting involved with the
OpenSIPS Community. How this helped him meet with great people and learn
more about SIP in first place and why everyone should be involved with
communities.

He also plans on giving a feedback of current status for the Greek
Businesses VoIP market and some changes seen the changes the last few
months, talk about how new technologies and cloud can help businesses to
continue to operate in situations like Coronavirus lock downs, SIP
Infrastructures of the future using cloud technologies and why we should
consider distributed architectures when building applications and software.

And last but not least  he would give a brief overview of the technologies
and methods he and his team are using internally to implement new platform
and give some information about how VoiceLang uses serverless on their new
platform.

We are going live as usually at 16:30 UTC this Saturday, August 1st.

https://youtu.be/6Da53zPz87Y

Tune up, share, like and subscribe. We got a new group where such
announcements would be posted in the future:

https://groups.google.com/u/1/g/sip-chronicles

See you soon!

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

[OpenSIPS-Users] SIP Chronicles #7, Featuring Ken Rice

[Maxim Sobolev]

Hey, OpenSource folks this is just a friendly reminder. If you liked any of
our first 6 episodes of SIP Chronicles, please consider putting some time
aside this Saturday at 4:30 UTC to see Ken Rice talking about FreeSWITCH,
OpenSIPS and other projects that he is working on.

https://youtu.be/176gzKQOoSQ

See you soon!

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

Re: [OpenSIPS-Users] [OpenSIPS-Devel] OpenSIPS Summit 2020 Distributed is set!

[Maxim Sobolev]

Thumbs up! Let's get distributed. :)

-Max

On Thu., Jul. 16, 2020, 9:09 a.m. Bogdan-Andrei Iancu, 
wrote:

>
> Bye-Bye Amsterdam, welcome Online – the "OpenSIPS Summit 2020" becomes
> the "OpenSIPS Summit Distributed 2020", a free, live and interactive
> online event.
>
> 5th - 11th of September - are you ready to join us?
>
> https://blog.opensips.org/2020/07/16/opensips-summit-2020-distributed/
>
>
> See you over the Internet,
>
> --
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
> OpenSIPS Summit 2020 online
>https://www.opensips.org/events/Summit-2020Distributed/
>
>
> ___
> Devel mailing list
> de...@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] [Announcement] SIP Chronicles #4, featuring Mark J. Crane @ FusionPBX

[Maxim Sobolev]

SIP Folks,

First of all thanks everyone who participated in or just watched our first
3 episodes of SIP Chronicles! I think it's safe to say that both myself and
my partner in crime Giovanni have been pleasantly surprised by the
turn-around numbers and general interest our little initiative has
generated!

We have had time to refine and think over our concept and if you ask me
now, SIP Chronicles is not about a particular product, or technology - it's
first and foremost about stories of amazing, passionate people doing
exciting things with SIP technology!

In that spirit, this Saturday we'll bring another story: the story of Mark
J. Crane and his FusionPBX project.  Even if you have never heard about
FusionPBX or FreeSWITCH (which is unlikely) that might be a great
opportunity to learn and hear Mark's story. Or if you are using either one
already - ask Mark a question!

Please join us this Saturday @ 4:30pm UTC: https://youtu.be/CJB7RjiIJ4s

 Thanks and see you soon! :)

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

Re: [OpenSIPS-Users] Sip traces to remote Homer Server

[Maxim Sobolev]

That IP address in the listen directive should be the *address of the
OpenSIPS machine itself*, since it's going to be the address where the HEP
client socket binds. The destination address is specified in the
modparam( "proto_hep",
"hep_id",  ...).

The only scenario when both addresses are the same is when both OpenSIPS
and Homer are running on the same box, which I suppose is not the case.

-Max

On Tue, Jun 2, 2020 at 7:07 AM Burhan Khan  wrote:

> There is some real IP instead of 1.2.3.4. It is pingable and it's port
> 9060 is accessible from opensips machine.
>
> On Tue, Jun 2, 2020 at 3:57 PM Maxim Sobolev 
> wrote:
>
>> Well, apparently there is no  1.2.3.4 IP configured on your machine, you
>> need to replace it with an actual IP address, or possibly 0.0.0.0 if a
>> particular source address does not matter.
>>
>> -Max
>>
>> -Max
>>
>> On Tue, Jun 2, 2020 at 6:07 AM Burhan Khan  wrote:
>>
>>> Hi
>>>
>>> I am trying to send sip traces from opensips 3.0 to remote Homer server
>>> but it is getting error. Following is my configuration
>>>
>>>
>>> loadmodule "proto_hep.so"
>>>
>>> loadmodule  "tracer.so"
>>>
>>>
>>>
>>> listen=hep_udp:1.2.3.4:9060
>>>
>>>
>>>
>>> modparam("tracer", "trace_on", 1)
>>>
>>> modparam("proto_hep", "hep_id", "[homer] 1.2.3.4:9060;transport=udp")
>>>
>>>
>>> modparam("tracer", "trace_id", "[tid]uri=hep:homer")
>>>
>>>
>>> In route section
>>>
>>>
>>> $var(trace_id) = "tid";
>>>
>>> trace($var(trace_id),  , "sip", );
>>>
>>>  Error is :::
>>>
>>> *ERROR:core:udp_init_listener: bind(27, 0x7ff5729214c4, 16) on *1.2.3.4*:
>>> Cannot assign requested address*
>>> *ERROR:core:trans_init_all_listeners: failed to init listener [*1.2.3.4*],
>>> proto hep_udp*
>>> *ERROR:core:main: failed to init all SIP listeners, aborting*
>>>
>>>
>>>
>>> *Regards*
>>> *Burhan Khan*
>>>
>>> *+46769568906*
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> --
>> Maksym Sobolyev
>> Sippy Software, Inc.
>> Internet Telephony (VoIP) Experts
>> Tel (Canada): +1-778-783-0474
>> Tel (Toll-Free): +1-855-747-7779
>> Fax: +1-866-857-6942
>> Web: http://www.sippysoft.com
>> MSN: sa...@sippysoft.com
>> Skype: SippySoft
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
>
> *Regards*
> *Burhan Khan*
>
> *+46769568906*
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Sip traces to remote Homer Server

[Maxim Sobolev]

Well, apparently there is no  1.2.3.4 IP configured on your machine, you
need to replace it with an actual IP address, or possibly 0.0.0.0 if a
particular source address does not matter.

-Max

-Max

On Tue, Jun 2, 2020 at 6:07 AM Burhan Khan  wrote:

> Hi
>
> I am trying to send sip traces from opensips 3.0 to remote Homer server
> but it is getting error. Following is my configuration
>
>
> loadmodule "proto_hep.so"
>
> loadmodule  "tracer.so"
>
>
>
> listen=hep_udp:1.2.3.4:9060
>
>
>
> modparam("tracer", "trace_on", 1)
>
> modparam("proto_hep", "hep_id", "[homer] 1.2.3.4:9060;transport=udp")
>
>
> modparam("tracer", "trace_id", "[tid]uri=hep:homer")
>
>
> In route section
>
>
> $var(trace_id) = "tid";
>
> trace($var(trace_id),  , "sip", );
>
>  Error is :::
>
> *ERROR:core:udp_init_listener: bind(27, 0x7ff5729214c4, 16) on *1.2.3.4*:
> Cannot assign requested address*
> *ERROR:core:trans_init_all_listeners: failed to init listener [*1.2.3.4*],
> proto hep_udp*
> *ERROR:core:main: failed to init all SIP listeners, aborting*
>
>
>
> *Regards*
> *Burhan Khan*
>
> *+46769568906*
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] UDP fragmentation in reply routes

[Maxim Sobolev]

Well, beware TCP is second-class citizen in the SIP land, for the very same
reasons HTTP is moving away from it in HTTP3/QUIC.

-Max

On Wed., May 20, 2020, 10:52 p.m. Olle Frimanson,  wrote:

> Thanks for the tips will give it a try to see what happens, but I guess
> TCP is the solution.
>
> Br Olle
>
> Skickat från min iPhone
>
> > 21 maj 2020 kl. 07:41 skrev junkmail :
> >
> > Yea that is it.
> >
> > so if you are doing something like tcpdump  udp port 5060 or udp port
> 5080 etc.  you would have to change it to the specific host IP that you are
> testing with.
> >
> > so more like tcpdump host 10.1.1.1 or something like that to make sure
> that you see all the traffic.   Or I am sure there is a way to tell TCPdump
> to capture fragments but I am a bit too lazy to look it up.  But that was
> why I was not seeing the fragments.
> >
> >
> >
> > 20.05.2020 15:46 に Maxim Sobolev さんは書きました:
> >> Olle, this is what he has been warning you about. See, the
> >> fragmentation is done at IP level, so that if your UDP packet gets
> >> fragmented, only the first fragment is going to contain a UDP header
> >> with a port number. Therefore, if you are using a port number(s) as a
> >> capture filter with your tcpdump then you won't see those subsequent
> >> fragment(s). You should be using IP with destination address as a
> >> filter for example and not UDP with a port number(s). Or combine udp
> >> rule with rule that would only match IP fragment(s).
> >> -Max
> >>> On Wed, May 20, 2020 at 12:57 PM Olle Frimanson 
> >>> wrote:
> >>> Hi thanks for the tip, how dit you find it? I just capture 3 ports
> >>> in my tcpdump.
> >>> Br Olle
> >>> Skickat från min iPhone
> >>>> 20 maj 2020 kl. 19:18 skrev junkmail :
> >>>> Sorry that is what I was trying to let you know.  Is that I had
> >>> thought the same thing that the Fragment was not even sent, but it
> >>> was just because of the tcpdump filter I had not that it actually
> >>> wasn't being sent.  If you have not try capturing all IP traffic to
> >>> a host IP and see if you see it.
> >>>> 20.05.2020 11:11 に Olle Frimanson さんは書きました:
> >>>>> Hi the issue on my side is that it’s not the network that is
> >>> the
> >>>>> problem the second fragment is not even sent. I also kind on lean
> >>> to
> >>>>> TCP at the moment but it would be good to get a comment from
> >>> Opensips
> >>>>> team on this if and how they setup the sockets and if there is a
> >>>>> difference on different routes
> >>>>> Br Olle
> >>>>> Skickat från min iPhone
> >>>>>>> 20 maj 2020 kl. 17:14 skrev junkmail :
> >>>>>> Hello, I had run into the same issue.  One thing I was a bit
> >>> mistaken because I was using tcpdump and doing a capture filter of
> >>> port 5060 or the such.  So I was missing the Fragment in my sniff as
> >>> it does not include the UDP header.  Just something to be aware of.
> >>> But I was having problems specifically traffic inside of GCP <
> >>> google cloud.  As well as traffic traversing the VPN to GCP.   I am
> >>> not certain about what changed for internal to GCP but that started
> >>> working and now the only thing using TCP is over VPNs.   Sorry not a
> >>> lot of information here. but my best guess is either the
> >>> firewall/router on my side or Googles is dropping the UDP fragment.
> >>> I didn't dig into it much further as TCP fixed the issue and this
> >>> was just a transit between opensisps systems.
> >>>>>> 19.05.2020 01:21 に o...@zaark.com さんは書きました:
> >>>>>>> Hi, this happens one single opensips instance server it
> >>> receives the
> >>>>>>> inbound packet fine, then when its send out on the same
> >>> interface
> >>>>>>> it’s fragmented, so I don’t think it’s network or router
> >>> switch
> >>>>>>> related. Have seen such problems in the past in virtual
> >>> environments
> >>>>>>> but this is not the case now.
> >>>>>>> My prime suspect is Centos since it send out the first part of
> >>> the
> >>>>>>> fragmented packet but not the following part that would
> >>> complete the
> >>>>>>>

Re: [OpenSIPS-Users] UDP fragmentation in reply routes

[Maxim Sobolev]

Olle, this is what he has been warning you about. See, the fragmentation is
done at IP level, so that if your UDP packet gets fragmented, only the
first fragment is going to contain a UDP header with a port number.
Therefore, if you are using a port number(s) as a capture filter with your
tcpdump then you won't see those subsequent fragment(s). You should be
using IP with destination address as a filter for example and not UDP with
a port number(s). Or combine udp rule with rule that would only match IP
fragment(s).

-Max

On Wed, May 20, 2020 at 12:57 PM Olle Frimanson  wrote:

> Hi thanks for the tip, how dit you find it? I just capture 3 ports in my
> tcpdump.
>
> Br Olle
>
> Skickat från min iPhone
>
> > 20 maj 2020 kl. 19:18 skrev junkmail :
> >
> > Sorry that is what I was trying to let you know.  Is that I had thought
> the same thing that the Fragment was not even sent, but it was just because
> of the tcpdump filter I had not that it actually wasn't being sent.  If you
> have not try capturing all IP traffic to a host IP and see if you see it.
> >
> >
> > 20.05.2020 11:11 に Olle Frimanson さんは書きました:
> >> Hi the issue on my side is that it’s not the network that is the
> >> problem the second fragment is not even sent. I also kind on lean to
> >> TCP at the moment but it would be good to get a comment from Opensips
> >> team on this if and how they setup the sockets and if there is a
> >> difference on different routes
> >> Br Olle
> >> Skickat från min iPhone
> >>>> 20 maj 2020 kl. 17:14 skrev junkmail :
> >>> Hello, I had run into the same issue.  One thing I was a bit mistaken
> because I was using tcpdump and doing a capture filter of port 5060 or the
> such.  So I was missing the Fragment in my sniff as it does not include the
> UDP header.  Just something to be aware of.  But I was having problems
> specifically traffic inside of GCP < google cloud.  As well as traffic
> traversing the VPN to GCP.   I am not certain about what changed for
> internal to GCP but that started working and now the only thing using TCP
> is over VPNs.   Sorry not a lot of information here. but my best guess is
> either the firewall/router on my side or Googles is dropping the UDP
> fragment.  I didn't dig into it much further as TCP fixed the issue and
> this was just a transit between opensisps systems.
> >>> 19.05.2020 01:21 に o...@zaark.com さんは書きました:
> >>>> Hi, this happens one single opensips instance server it receives the
> >>>> inbound packet fine, then when its send out on the same interface
> >>>> it’s fragmented, so I don’t think it’s network or router switch
> >>>> related. Have seen such problems in the past in virtual environments
> >>>> but this is not the case now.
> >>>> My prime suspect is Centos since it send out the first part of the
> >>>> fragmented packet but not the following part that would complete the
> >>>> packet.
> >>>> But indeed it is a strange bug, since it does not always happen.
> >>>> BR/Olle
> >>>> FRÅN: Users  FÖR Giovanni
> >>>> Maruzzelli
> >>>> SKICKAT: den 19 maj 2020 09:13
> >>>> TILL: OpenSIPS users mailling list 
> >>>> ÄMNE: Re: [OpenSIPS-Users] UDP fragmentation in reply routes
> >>>> Can be a problem of the virtual env, and/or the router/switch...
> >>>> Try substitute real hardware to virtual, and different models of
> >>>> router/switch
> >>>> In a LAN, UDP fragmentation is not supposed to be a problem at all...
> >>>> answered from mobile, please pardon terseness and typos,
> >>>> -giovanni
> >>>>> On Tue, May 19, 2020, 08:05  wrote:
> >>>>> Thanks for the reply Max,
> >>>>> we are doing all we can to make the packets smaller, but before we
> >>>>> move over to TCP, which is most likely our next step, I wanted to
> >>>>> explore what could be happening.
> >>>>> AFAIK the application have some control of this since these are
> >>>>> parameters that partly can be set when you open a socket, that’s
> >>>>> why I wonders if Opensips might use those parameters or not,
> >>>>> especially since we have so very different behaviour in different
> >>>>> directions.
> >>>>> BR/Olle
> >>>>> FRÅN: Users  FÖR Maxim Sobolev
> >>>>> SKICKAT: den 18 maj 2020 22:03
> >>>>> TILL: OpenSIPS users mailling list 
> >>>&

Re: [OpenSIPS-Users] UDP fragmentation in reply routes

[Maxim Sobolev]

Smells like a OS/kernel bug to me. There is little application can do in
that regard, UDP fragmentation/reassembly happens at much lower layers of
the OSI stack.

However, as a workaround as long as SIP goes you can try to reduce your SIP
signalling packet size by using compact version of SIP headers, as well as
dropping headers that are not used. That would save you 100-150 bytes per
SIP message perhaps. I don't know if OpenSIP can do that in the proxy mode
out of the box though, so you might want to add b2b into the flow.

-Max

On Mon., May 18, 2020, 12:34 p.m. Olle Frimanson,  wrote:

> Hi,
>
>
>
> We have an issue on our home proxy (opensips 2.4.6), when it receives  200
> OK (over UDP)  from our Freeswitch and the package size is higher than the
> MTU size , we sometimes get fragmentation  of the UDP packets, but only the
> first part of the fragmented package is sent to our edge proxy. Is this a
> known issue or is it a OS bug?
>
>
>
> We have not yet spotted any pattern on this and in most cases bigger
> packets with MTU around 1600 bytes gets through without an issue.
>
>
>
> I can add that in the other direction in the normal request routes we
> don’t have any issue at all can have packets > 2000 bytes without any
> issues.
>
> Does Opensips use IP_MTU_DISCOVER or how is fragmentation controlled and is 
> it expected to have different behavior in reply routes vs other routes?
>
> We use Centos 7 in a virtual server environment.
>
>
>
> I was hoping someone can share some light on this strange issue.
>
>
>
> BR/Olle
> ___
> 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] [RTPproxy] catch_dtmf module has landed in rtpproxy/master

[Maxim Sobolev]

Thanks, Gohar! Very good questions:

1. Module relies on RFC2833 (DTMF Events). No in-band decoding is
implemented at the moment.

2. Module is observer-only for now. It doesn't try to block or in any way
alter the RTP stream being forwarded. Hovewer, that might be something to
consider as a next step, in fact it might be almost trivial to replace the
actual digits with some junk.

Our goal with this initial release was to provide something that could be
immediately useful and unblock OpenSIPS work in this area. Big part of the
effort went to refine and build up interfaces on rtpproxy side to make
future development easier for this functionality as well as allow us and
others implementing various packet-processing options (i.e. bridge_srtp
certainly high on priority list). Also, the module infrastructure is
decoupled from the core, so it should allow using all kinds of crazy
external code libraries (DSP, voice recognition etc), without compromising
our core integrity when the functionality is not used.

-Max

On Thu., May 14, 2020, 7:25 p.m. Gohar Ahmed,  wrote:

> Hi,
> That's big news indeed. Quick question though, is it capable of capturing
> inband DTMF and possibly drop them ?
>
> Looking forward for next episode of SIP chronicles.
>
> Best Regards,
> Gohar Ahmed
>
> On Thu., May 14, 2020, 9:10 p.m. Maxim Sobolev, 
> wrote:
>
>> Hi Razvan & OpenSIPS-users,
>>
>> This is just a quick heads up about catch_dtmf functionality being
>> available in the rtpproxy/master effective immediately. It is needed for
>> the DTMF call control feature in OpenSIPS 3.1. The only difference between
>> it and rtpp_2_1_dtmf code is that in order to enable the feature in master
>> one needs to load catch_dtmf module either by using "--dso
>> /some/where/rtpp_catch_dtmf.so" or by providing configuration file
>> with catch_dtmf section in modules:
>>
>> modules {
>> [...]
>> catch_dtmf {
>> load = /some/where/rtpp_catch_dtmf.so
>> }
>> }
>>
>> The module code has been developed in collab with Razvan + sponsored by
>> the OpenSIPS Solutions and comes with the test case providing 95%
>> coverage*. Any feedback is highly appeciated, as usually, happy DTMF'ing!
>>
>> -Max
>> *)
>> https://coveralls.io/builds/30800066/source?filename=modules/catch_dtmf/rtpp_catch_dtmf.c
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "rtpproxy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rtpproxy+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/rtpproxy/CAH7qZfuucLr2TYrYFT6X%2B9WL%3D7xay7pJsExUxAhp5gb4UL5%2Bsg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/rtpproxy/CAH7qZfuucLr2TYrYFT6X%2B9WL%3D7xay7pJsExUxAhp5gb4UL5%2Bsg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] catch_dtmf module has landed in rtpproxy/master

[Maxim Sobolev]

Hi Razvan & OpenSIPS-users,

This is just a quick heads up about catch_dtmf functionality being
available in the rtpproxy/master effective immediately. It is needed for
the DTMF call control feature in OpenSIPS 3.1. The only difference between
it and rtpp_2_1_dtmf code is that in order to enable the feature in master
one needs to load catch_dtmf module either by using "--dso
/some/where/rtpp_catch_dtmf.so" or by providing configuration file
with catch_dtmf section in modules:

modules {
[...]
catch_dtmf {
load = /some/where/rtpp_catch_dtmf.so
}
}

The module code has been developed in collab with Razvan + sponsored by the
OpenSIPS Solutions and comes with the test case providing 95% coverage*.
Any feedback is highly appeciated, as usually, happy DTMF'ing!

-Max
*)
https://coveralls.io/builds/30800066/source?filename=modules/catch_dtmf/rtpp_catch_dtmf.c
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 3.1 Status Enquiry

[Maxim Sobolev]

Mark, in case you've missed it here is some more details (more like a lot
more details) about new release plans coming directly from the OpenSIPS
team:

https://youtu.be/Pxh4Sz9oqnk?t=614

Hope it helps. :)

-Max

On Wed, May 13, 2020 at 2:38 AM Mark Farmer  wrote:

> Hi everyone
>
> Firstly I apologise for asking at all and I have read this:
>
> https://blog.opensips.org/2020/03/25/opensips-3-1-interim-update/
>
> However, over the next couple of months I will be building a new
> production platform using OpenSIPS and I would much prefer to use 3.1 than
> 3.0 or 2.4
>
> Given the challenges that we are all facing and the perfectly reasonable
> delay of the annual summit, are we still on for a release soon? I am
> personally quite comfortable to use 3.1 and patch it later on but I need to
> reassure others that it is safe enough to do so.
>
> To clarify, I am not looking for dates, just a best guess :)
>
> Thank you!
> Mark.
>
> ___
> 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] Opensips + rtpproxy issue

[Maxim Sobolev]

Oh, sorry, looks like the proper way to check that is via using -V option.

[ssp-root@macmini2 /home/ssp]$ rtpproxy -V
2.2.alpha.3794729c-dirty

Let us know if that upgrade helped. Thanks!

-Max

On Wed, May 6, 2020 at 2:09 AM Miha  wrote:

> Hello Maxim
>
> I removed package via apt and then install it via source/git.
>
> But from what I see version is still the same:
> How would I know for sure that the version is something like 2.1?
>
> ./rtpproxy -version
> Basic version: 20040107
> Extension 20040107: Basic RTP proxy functionality
> Extension 20050322: Support for multiple RTP streams and MOH
> Extension 20060704: Support for extra parameter in the V command
> Extension 20071116: Support for RTP re-packetization
> Extension 20071218: Support for forking (copying) RTP stream
> Extension 20080403: Support for RTP statistics querying
> Extension 20081102: Support for setting codecs in the update/lookup command
> Extension 20081224: Support for session timeout notifications
> Extension 20090810: Support for automatic bridging
> Extension 20140323: Support for tracking/reporting load
> Extension 20140617: Support for anchoring session connect time
> Extension 20141004: Support for extendable performance counters
> Extension 20150330: Support for allocating a new port ("Un"/"Ln" commands)
> Extension 20150420: Support for SEQ tracking and new rtpa_ counters; Q
> command extended
> Extension 20150617: Support for the wildcard %%CC_SELF%% as a disconnect
> notify target
> Extension 20191015: Support for the && sub-command specifier
> Extension 20200226: Support for the N command to stop recording
>
>
>
> Maxim Sobolev je 5/6/2020 ob 2:22 AM napisal:
>
> Hi Miha, sorry to hear about your issues. In order to troubleshoot it
> further could you please also provide rtpproxy package version as reported
> by the system package manager (apt, rpm etc) if the software has been
> installed via that channel or branch name if it's been built from sources?
> Unfortunately version reporting of the --version command has been bit
> crippled until recently, already improved in latest master and 2.1 I
> believe.
>
> In general performance under virtual environment has not been terrific,
> due to some design choices made early in our work. Hovewer I believe it
> should be much better in 2.0 and 2.1 vs. 1.x series. Some of it is
> inherently due to VM scheduling jitter, some is because we are unwilling to
> put it into unsafe domain (i.e. kernel mode). As a rule of thumb, you might
> expect 3-5x drop in max pps until jitter becomes an issue as compared to
> running on comparable bare metal. Spinning multiple instances might help to
> mitigate some of it though, but it also depends on hypervisor version and
> even particular CPU generation.
>
> -Max
>
> On Tue., May 5, 2020, 6:10 a.m. Miha via Users, 
> wrote:
>
>> Hello
>>
>> we have virtualized opensips and rtpproxy running on the same server
>> which is virtualized in vmware infrastructure. Servers are not old, also
>> traffic is not so big (cca 50 simultaneous calls). when there is a peak cca
>> 80 simultaneous calls RTP starts to break.
>>
>> is there any special setting/flag to be set, so that I can optimze this?
>> load on VM is very low.
>>
>> rtpproxy -version
>> Basic version: 20040107
>>
>> Opensips is 2.1
>>
>>
>> thank you for help.
>> Miha
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>

-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Opensips + rtpproxy issue

[Maxim Sobolev]

Hi Miha, sorry to hear about your issues. In order to troubleshoot it
further could you please also provide rtpproxy package version as reported
by the system package manager (apt, rpm etc) if the software has been
installed via that channel or branch name if it's been built from sources?
Unfortunately version reporting of the --version command has been bit
crippled until recently, already improved in latest master and 2.1 I
believe.

In general performance under virtual environment has not been terrific, due
to some design choices made early in our work. Hovewer I believe it should
be much better in 2.0 and 2.1 vs. 1.x series. Some of it is inherently due
to VM scheduling jitter, some is because we are unwilling to put it into
unsafe domain (i.e. kernel mode). As a rule of thumb, you might expect 3-5x
drop in max pps until jitter becomes an issue as compared to running on
comparable bare metal. Spinning multiple instances might help to mitigate
some of it though, but it also depends on hypervisor version and even
particular CPU generation.

-Max

On Tue., May 5, 2020, 6:10 a.m. Miha via Users, 
wrote:

> Hello
>
> we have virtualized opensips and rtpproxy running on the same server which
> is virtualized in vmware infrastructure. Servers are not old, also traffic
> is not so big (cca 50 simultaneous calls). when there is a peak cca 80
> simultaneous calls RTP starts to break.
>
> is there any special setting/flag to be set, so that I can optimze this?
> load on VM is very low.
>
> rtpproxy -version
> Basic version: 20040107
>
> Opensips is 2.1
>
>
> thank you for help.
> Miha
> ___
> 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] Join us for SIP Chronicles Live #1a, featuring Bogdan and Razvan!!!

[Maxim Sobolev]

Folks,

We were frankly positively overwhelmed with the amount of interest for such
an event from the OpenSIPS community!!! So here we go, instead of pushing
it back another two weeks we decided to deliver two shows tomorrow instead
of just one! Back-To-back as we say. With about 1 hour break in between to
stretch your legs and refill the popcorn bowl.

In the second part of the first episode Bogdan and Razvan present their
latest work on CallCenter functionality and demonstrate how they can make
good use of SaraPhone to make it even cooler. 7pm UTC, it would be a good
show to put you into sleep mode eventually.

https://youtu.be/cea0B-oad3w

See you tomorrow!

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

Re: [OpenSIPS-Users] Join us for SIP Chronicles Live #1, featuring Giovanni Maruzzelli

[Maxim Sobolev]

Thanks Bogdan, I am glad that you liked the idea! Yes, very good question.
We will have a slot (or few) where questions from the audience can be
answered interactively. Originally we were planning to take questions over
YouTube chat, but maybe it would be also cool if Giovanni can deploy his
cool phone so people can actually call in and ask? At which point we could
also publish a SIP URI for anyone to  ring in directly as well and drill
speaker on his answers.

Eventually I hope to feel brave enough to deploy Jitsi Meet, but probably
not until this whole ordeal is over unless I get some more help from a
community, which is also an option. :)

-Max

On Tue, Apr 21, 2020 at 9:00 AM Bogdan-Andrei Iancu 
wrote:

> Hi Maxim,
>
> Great idea, let's keep the communities connected and up to date - after
> all this is what we do - we do communication systems :)
>
> Giovanni, I will be there !
>
> BTW, is this an interactive session, in the way that questions can be
> asked?
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>
> On 4/20/20 9:59 PM, Maxim Sobolev wrote:
>
> Dear Real-Time Friends and Colleagues!
>
> As many of you we have been totally devastated that we will have no chance
> to see you in the next few months to come. :-/ Some people in the community
> believe it might be years. I don’t necessarily agree with that opinion
> myself.
>
> Over the course of the last few years our team had a great time extending
> live coverage for some of those events that have been affected, got some
> experience and equipment. Instead of just waiting for the virus to clear,
> we decided to organize a series of bi-weekly live casts with some of the
> speakers that we have hoped to see at those events presenting their latest
> developments live and then answering questions from the audience.
>
> So without further ado, let me introduce our first guest Giovanni
> Maruzzelli, who is going to introduce his newest project SaraPhone (
> https://github.com/gmaruzz/saraphone).
>
> Join us this Saturday, April 25th 4:30pm UTC and get a chance to ask
> Giovanni a question about his project live:
>
> https://youtu.be/mF9elIcVGE8
>
> Or if you miss that opportunity, you can always watch the recording later
> on Sippy Labs channel on YouTube and email Giovanni your question at <
> gmar...@gmail.com>.
>
> SaraPhone is a bare bone SIP WebRTC phone, complete with most features
> real companies want to use in real world: HotDesking, Redial, BLFs, MWI,
> DND, PhoneBook, Hold, Transfer, Mute, Attended Transfer, Notifications,
> running on all Browsers both on Desktop and SmartPhone.
>
> SaraPhone is fully integrated with FusionPBX, the full-featured domain
> based multi-tenant PBX and voice switch for FreeSwitch.
>
> Based on SIP.js, SaraPhone works with all WebRTC compliant SIP proxies,
> gateways, and servers (Asterisk, OpenSIPS, Kamailio, Janus, etc).
>
> Initial author is Giovanni Maruzzelli, and SaraPhone gets its name from
> Giovanni's wife, Sara Hosseini.
>
> In addition to providing all of the usual DeskPhone functionality,
> SaraPhone got:
>
>-
>
>Desktop Notification for Incoming Calls
>-
>
>Live MWI update
>-
>
>Real Time BLFs status update
>-
>
>BLF click to call
>-
>
>Caller Name and Number Display
>-
>
>Call Error Cause Display
>-
>
>AutoAnswer
>-
>
>Network Disconnect Reload
>-
>
>Show and Set Caller-ID (incoming-outbound)
>
> Stay healthy, optimistic and productive! Also share, like and subscribe.
> See you soon!!!
>
> Regards,
>
> Max
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>

-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Join us for SIP Chronicles Live #1, featuring Giovanni Maruzzelli

[Maxim Sobolev]

Dear Real-Time Friends and Colleagues!


As many of you we have been totally devastated that we will have no chance
to see you in the next few months to come. :-/ Some people in the community
believe it might be years. I don’t necessarily agree with that opinion
myself.

Over the course of the last few years our team had a great time extending
live coverage for some of those events that have been affected, got some
experience and equipment. Instead of just waiting for the virus to clear,
we decided to organize a series of bi-weekly live casts with some of the
speakers that we have hoped to see at those events presenting their latest
developments live and then answering questions from the audience.

So without further ado, let me introduce our first guest Giovanni
Maruzzelli, who is going to introduce his newest project SaraPhone (
https://github.com/gmaruzz/saraphone).

Join us this Saturday, April 25th 4:30pm UTC and get a chance to ask
Giovanni a question about his project live:

https://youtu.be/mF9elIcVGE8

Or if you miss that opportunity, you can always watch the recording later
on Sippy Labs channel on YouTube and email Giovanni your question at <
gmar...@gmail.com>.

SaraPhone is a bare bone SIP WebRTC phone, complete with most features real
companies want to use in real world: HotDesking, Redial, BLFs, MWI, DND,
PhoneBook, Hold, Transfer, Mute, Attended Transfer, Notifications, running
on all Browsers both on Desktop and SmartPhone.

SaraPhone is fully integrated with FusionPBX, the full-featured domain
based multi-tenant PBX and voice switch for FreeSwitch.

Based on SIP.js, SaraPhone works with all WebRTC compliant SIP proxies,
gateways, and servers (Asterisk, OpenSIPS, Kamailio, Janus, etc).

Initial author is Giovanni Maruzzelli, and SaraPhone gets its name from
Giovanni's wife, Sara Hosseini.

In addition to providing all of the usual DeskPhone functionality,
SaraPhone got:

   -

   Desktop Notification for Incoming Calls
   -

   Live MWI update
   -

   Real Time BLFs status update
   -

   BLF click to call
   -

   Caller Name and Number Display
   -

   Call Error Cause Display
   -

   AutoAnswer
   -

   Network Disconnect Reload
   -

   Show and Set Caller-ID (incoming-outbound)

Stay healthy, optimistic and productive! Also share, like and subscribe.
See you soon!!!

Regards,

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

Re: [OpenSIPS-Users] rtpproxy module not supporting valid payload types

[Maxim Sobolev]

Yes, for sure. As long as the transport is UDP based, the RTPProxy would
just work. The change should be trivial, you can get it fixed locally, test
and then open a pull request against opensips repo.

-Max


On Thu., Apr. 2, 2020, 11:43 a.m. Robert Dyck,  wrote:

> Regarding opensips-3.0
>
> Use case - webrtc client behind NAT
>
>
>
> The rtpproxy module emitted the error message "can't extract media port
> from the message" ( by the way, very misleading ). In reality
> extract_mediainfo fails because it could not find a supported payload type
> in the media description. The payload type in question is
> "UDP/TLS/RTP/SAVPF".
>
>
>
> RFC 5764 section 8 introduces four more RTP types.
>
> DCCP/TLS/RTP/SAVP and SAVPF
>
> UDP/TLS/RTP/SAVP and SAVPF
>
>
>
> Should rtpproxy.c be extended to support these additional RTP types?
>
>
>
> Thank you, Rob
> ___
> 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] [BLOG] Call control using DTMF codes in OpenSIPS 3.1 LTS

[Maxim Sobolev]

Thanks Razvan for contributing a great feature that has been asked for many
times over the last few years! I plan to merge it into the master branch by
May.

-Max

On Thu., Mar. 12, 2020, 5:58 a.m. Антон Ершов,  wrote:

> this is great news
>
> чт, 12 мар. 2020 г. в 15:50, Răzvan Crainea :
>
>> Hi, everyone!
>>
>> I've just published a blog post[1] that describes how you can intercept
>> DTMF codes in OpenSIPS 3.1, and what kind of services you can implement
>> using this feature.
>>
>> [1]
>>
>> https://blog.opensips.org/2020/03/12/call-control-using-dtmf-in-opensips-3-1-lts/
>>
>> Happy reading!
>> --
>> Răzvan Crainea
>> OpenSIPS Core Developer
>>http://www.opensips-solutions.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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] rewrite status-line

[Maxim Sobolev]

I think this response is borderline. RFC3261 specifically mandates SINGLE
character to be used, however the reason phrase might contain as many
spaces as needed, so that it can be argued that in this particular case the
reason phrase is " OK" versus "OK" normally.

---

7.2  Responses

   SIP responses are distinguished from requests by having a Status-Line
   as their start-line.  A Status-Line consists of the protocol version
   followed by a numeric Status-Code and its associated textual phrase,
   with each element separated by a single SP character.

   No CR or LF is allowed except in the final CRLF sequence.

  Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

[...]

Reason-Phrase   =  *(reserved / unreserved / escaped
   / UTF8-NONASCII / UTF8-CONT / SP / HTAB)

---


Technically speaking changing JUST reason phrase in SIP proxy should not
break anything. You don't really need B2BUA to replace say "200 OK" with
"200 Have a Good Day" so it's just a matter of nobody having this need.


-Max


On Fri, Feb 14, 2020 at 6:09 AM johan  wrote:

> To me 200 OK is perfectly valid.   The operator should fix this at his
> side.
> On 14.02.20 15:01, Антон Ершов wrote:
>
> Hello friends!
> we have final equipment that does not meet 200OK correctly. it adds an
> extra space between 200 and OK. from the point of view of rfc is not very
> scary. but there is an operator that cannot handle the given 200OK. I tried
> to fix it with change_reply_status in module sipmsgops.
> but it rewrites the status-line with the same extra space.
> Is this a bug?
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSIPS 3.1 Media Bridging Feature

[Maxim Sobolev]

Very interesting new feature, Razvan! I am curious to hear some more about
it during upcoming OpenSIPS Summit if not earlier! :)

-Max

On Thu, Feb 6, 2020 at 10:28 PM Răzvan Crainea  wrote:

> Hi, Alexey!
>
> No, not at all. Although it might be used for that, I doubt anybody will
> do it :). Although indeed both rtpproxy and rtpengine can do certain
> media injection by them selves, usually this resumes to playing back a
> media file, and that's it. They will not generate any SIP traffic, thus
> it will not be able to mix different calls media (SDP).
> The new module will always operate at the SIP level, it will not "touch"
> the RTP at all. All it will do is to generate certain SIP traffic, and
> exchange SDP information between the calls.
> Using the new media bridging module you will be able to inject actual
> media within a new call, for example you can take an ongoing proxied
> call, and redirect its audio to a conference room.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 2/7/20 8:07 AM, Alexey Kazantsev via Users wrote:
> > Hi, Răzvan
> > Will it be a kind of alternative for RTPEngine?
> > ---
> > BR, Alexey
> > http://alexeyka.zantsev.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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Use RTPPROXY to bridge ipv4/ipv6

[Maxim Sobolev]

Daniel, you can find some v4-v6 examples here:

https://github.com/sippy/voiptests/blob/master/test_run.sh

${RTPPROXY} -p "${RTPP_PIDF}" -d dbug -f -s stdio: -s "${RTPP_SOCK_UDP}" \
  -s "${RTPP_SOCK_CUNIX}" -s "${RTPP_SOCK_UNIX}" -s "${RTPP_SOCK_UDP6}" -s
"${RTPP_SOCK_TCP}" \
  -s "${RTPP_SOCK_TCP6}" -m 12000 -M 15000 -6 '/::' -l '0.0.0.0'
${RTPP_NOTIFY_ARG}

In your case that would be (note "/" in front of IPv6 addr):

/bin/rtpproxy -F -l "200.200.200.200" -6 "/2607:3f00:2
"

-Max

On Thu, Aug 2, 2018 at 1:50 PM Daniel Zanutti 
wrote:

> Hi
>
> I'm trying to configure RTPPROXY to bridge ipv4 and ipv6 networks, but
> didn't find the proper way.
> Supposing IPs "200.200.200.200" and  "2607:3f00:2 " both on ETH0
> interface.
>
> Tried:
> /bin/rtpproxy -F -l 200.200.200.200/2607:3f00:2
>
> Got this error: Restarting rtpproxy: rtpproxy: host2bindaddr: Address
> family for hostname not supported
>
> Then used -6 option and got same error:
> /bin/rtpproxy -F -6 200.200.200.200/2607:3f00:2
>
> What is the right way?
>
> Thanks
> ___
> 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] [RELEASE] OpenSIPS 2.2.7, 2.3.4 and 2.4.1 minor releases

[Maxim Sobolev]

Good job, OpenSIPS team!

-Max

On Thu, May 24, 2018 at 6:56 PM, Pasan Meemaduma via Users <
users@lists.opensips.org> wrote:

> Congratz :)
>
>
> On Thursday, 24 May 2018, 10:48:24 PM GMT+5:30, Bogdan-Andrei Iancu <
> bog...@opensips.org> wrote:
>
>
> Greetings again!
>
> I am glad to announce that our plan was successfully completed : the
> OpenSIPS minor releases 2.4.1, 2.3.4 and 2.2.7 are now out!
>
> After more time of spinning OpenSIPS in production environments we managed
> to track down and fix various bugs. You can find a full list of changes
> here:
>
> * OpenSIPS 2.4.1 ChangeLog: http://opensips.org/pub/
> opensips/2.4.1/ChangeLog
> 
> * OpenSIPS 2.3.4 ChangeLog: http://opensips.org/pub/
> opensips/2.3.4/ChangeLog
> 
> * OpenSIPS 2.2.7 ChangeLog: http://opensips.org/pub/
> opensips/2.2.7/ChangeLog
> 
>
> All of these were made possible by with the OpenSIPS community's help, for
> which we would like to thank you very much!
>
> Enjoy riding OpenSIPS!
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Summit 2018
>   http://www.opensips.org/events/Summit-2018Amsterdam
>
> On 05/17/2018 01:39 PM, Bogdan-Andrei Iancu wrote:
>
> Greetings!
>
> A new cycle is about to be complete: OpenSIPS is tortured all over the
> worlds; this produces feedback and reports; and this translates into more
> fix, in a better stability of the released OpenSIPS versions.
>
> Shortly, it's time for a new set of minor releases, to officially
> incorporate all the fixes in the last months/weeks: OpenSIPS 2.2.7, 2.3.4
> and 2.4.1
>
> The new releases are due next week, on Wednesday, May 24th 2018.
>
> If you have any pending GitHub issues/mailing list bug threads concerning
> the mentioned branches, this would be a good time to bump them!
>
> Thank you for your contributions to this project!
>
> Best regards,
>
>
> ___
> 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
>
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [Release] OpenSIPS 2.4.0 major release, beta version

[Maxim Sobolev]

Hice! I'll add new branch to my voiptests build. We have some patches to
fix memory leak in the python module, I will post them soon. Hopefully they
can make it into the release.

-Max

On Wed, Mar 28, 2018, 4:19 PM  wrote:

> Great work !!!
>
> volga629
>
> On Wed, Mar 28, 2018 at 3:12 PM, Bogdan-Andrei Iancu
>  wrote:
> > Hi All !!
> >
> > I guess everybody knows the drill by now - it is March, so it's time
> > for a new major OpenSIPS release. Almost 4 months ago we were
> > announcing our ambitious roadmap for OpenSIPS 2.4 .
> >
> > Well, this has just come reality !!
> >
> > I’m happy to announce the beta release of the OpenSIPS 2.4.0 major
> > version. Curios to find out more about this release? See the
> > philosophy behind this release by reading the overview of OpenSIPS
> > 2.4.o, code name The Cluster Maker.
> >
> > And keep in mind that 2.4 is still a beta release, targeting 30th of
> > April to become fully stable. So, we have one month of testing ahead
> > of us :).
> >
> > Many thanks to our awesome community for contributing with ideas,
> > code, patches, tests and reports!
> >
> > With the occasion of the OpenSIPS Summit 2018, the stable OpenSIPS
> > 2.4 will be our star, as we will present and demo all its
> > capabilities!
> >
> > Looking for downloading it? See the tarball or the GIT repo. Packages
> > will be available soon.
> >
> > Enjoy it !!
> >
> > --
> > Bogdan-Andrei Iancu
> >
> > OpenSIPS Founder and Developer
> >   http://www.opensips-solutions.com
> > OpenSIPS Summit 2018
> >   http://www.opensips.org/events/Summit-2018Amsterdam
>
>
> ___
> 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] Introducing OpenSIPS 2.4

[Maxim Sobolev]

Bogdan, with regards to the media relays clustering what's the advantage of
sharing that load info between each signalling node versus having each node
tracking this independently? In my view the latter could be more reliable
and much less complicated construct. The only disadvantage is that you'd
get more command load on relays, however at least with the RTPproxy pulling
load stats is very lightweight operation so even with tens of signalling
nodes pulling single media relay every 1-10 seconds it won't cause any
noticeable performance degradation on the relay. On the flip side, each
signalling node would get accurate view from its vantage PoV, so in the
case of geographically distributed system when signalling node can only see
subset of all media nodes it would still be able to make proper decisions.
This is the approach we use in the rtp_cluster and it works pretty well
with cluster size of up to 5 signalling and 10 RTP handling nodes, 40-50K
media sessions in total. It can also give you accurate RTT information, so
your signalling node can not only factor in the load but also proximity or
each and every media relay.

As far as the load tracking is concerned, I think the approach to implement
"b2b-driven routing" using API that is specific to each particular b2b is
somewhat wasteful and is not very future-proof. What we would like to see
instead, is for opensips to publish some kind of API (preferably SIP-based,
using OPTIONS or SUBSCRIBE/NOTIFY mechanism) to pull this information out
and let each b2b vendor to implement proper hooks. Then it can go as far as
making this info some king of RFC.

Anyhow, just my $0.02c. Not volunteering to do opensips side (ENOTIME), but
if opensips project comes up with the reasonable b2bua-agnostic load query
API to use we might look at implementing it in the sippy [py/go]-B2BUAs.

-Max

On Wed, Nov 8, 2017 at 9:31 AM, Bogdan-Andrei Iancu 
wrote:

> Hi Nuno,
>
> On the Asterisk part, the plan is to do exactly what we already have for
> FreeSWITCH (see https://blog.opensips.org/2017/03/01/freeswitch-driven-
> routing-in-opensips-2-3/)
>
> In terms of clustering media relays, is about the ability to share the
> state (enabled/disabled) between all the cluster nodes using the media
> relays. Optionally, we are looking in adding the ability to balance the
> traffic between the relays, in a cluster-level aware (all the nodes in the
> cluster will share the information on the load of the media relays )
>
> Regards,
>
> Bogdan-Andrei Iancu
>   OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] python module - bug and questions

[Maxim Sobolev]

Robert, what Bogdan says is essentially correct. The OpenSIPS itself is not
using any threads AFAIK, therefore python module code is kept as simple as
possible. Now back to the original question: we use quite a lot of python
code in our routing and some of the python modules that are running are
actually creating threads on their own and it appears to be pretty stable.
What OS / python version are you using? What could be different in our case
is that we link our OpenSIPS binary with pthreads always (which may or may
not be the case on your build), so there might be some vital threads
runtime infrastructure that is not getting initialized in your case.

-Max


On Fri, Apr 21, 2017 at 1:25 AM, Bogdan-Andrei Iancu 
wrote:

> Hi Robert,
>
> The only question I can answer is 1) - OpenSIPS it is a multi-process
> application (and not using threads).
>
> How the python module is design (from threading perspective), I do not
> know - maybe Maxim, the author of this module can help with this.
>
> Regards,
>
> Bogdan-Andrei Iancu
>   OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
>
> OpenSIPS Summit May 2017 Amsterdam
>   http://www.opensips.org/events/Summit-2017Amsterdam.html
>
> On 04/19/2017 08:43 PM, Mundkowsky, Robert wrote:
>
>
>
> Hi,
>
>
>
> This email should likely go to your other dev forum, but I don’t have
> access yet.
>
>
>
> I am using openSIPS 2.2.3 on Ubuntu 16.04.2 LTS.
>
>
>
> I am using the python module.  The python script called works fine when
> called from outside openSIPS and it works fine when called inside openSIPS,
> if it is triggered once at a time.
>
>
>
> But if the python script is triggered twice by two phone calls or more or
> even one call after another in short order, then there are weird errors
> which show up in different places in the code like:
>
>
>
> ERROR:python:python_handle_exception: #011TypeError: an integer is
> required
>
>
>
> I am guessing the openSIP python module has some problem/s related to
> threading.
>
>
>
>
>
> Questions:
>
> 1)  I am guessing that OpenSIPS uses a multi-threaded architecture?
>
> 2)  Is the python module meant to be a single thread? Or
> multi-threaded?
>
> a.   If it is meant to be single threaded then why use python library
> thread functions? Just use python library without multi-threaded stuff.
>
> b.  If it is meant to be multi-threaded then why is there only one
> call to PyThreadState_New and myThreadState is a global used everywhere?
>
>i.  I
> would think a thread per call to python_exec would make more sense and make
> the code easier to understand?
>
> 3)  Also why is there no clean up code (PyThreadState_Clear,
> PyThreadState_Delete, Py_Finalize)?
>
> a.   I am guessing the idea is you do not need clean up, because it
> only happens when openSIPS is turned off.
>
>
>
> Robert
>
>
>
>
>
> For reference:
>
> 
> https://www.codeproject.com/articles/11805/embedding-python-in-c-c-part-i
>
> 
> http://www.awasu.com/weblog/embedding-python/threads/
>
>
> 
> http://stackoverflow.com/questions/26061298/python-multi-thread-multi-
> interpreter-c-api
>
>
>
> --
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> --
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transactional REGISTER processing with 2.1

[Maxim Sobolev]

Hi Razvan, this is the code from SER 2.0. There is no equivalent for
"s:digest_challenge" or "s:contact" AVPs as far as I can tell looking to
the code in question in OpenSIPS.

-Max

On Mon, Feb 20, 2017 at 12:25 AM Răzvan Crainea <raz...@opensips.org> wrote:

> Hi, Maxim!
>
> The code you are using now should do what you request. t_newtran() returns
> 0 for retransmissions, therefore for the second message (retransmission)
> that will run the script, t_newtran() will immediately absorb the message
> and return without executing any further instructions.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 02/17/2017 09:15 PM, Maxim Sobolev wrote:
>
> P.S. python_exec("www_authenticate") does not do any magic here, it's
> just figures out the right domain to use based on some business rules and
> then calls www_authenticate() with that parameter.
>
> On Fri, Feb 17, 2017 at 11:12 AM, Maxim Sobolev <sobo...@sippysoft.com>
> wrote:
>
> Hi guys,
>
> We are underway to migrate from ancient SER-2.0.0 to more modern OpenSIPS
> and one of the question that is still in my TODO list is implementing
> transactional processing of the REGISTER requests. In the old SER we had
> something along those lines:
>
> route[3] {
> # Ensure that all incoming messages contain auth info
> xlog("L_INFO", "processing %rm received from %si:%sp");
> if (!t_newtran()) {
> sl_send_reply("500", "could not create transaction");
> break;
> };
> if (!python_exec("www_authenticate")) {
> xlog("L_INFO", "challenging %ct");
> if (is_avp_set("s:digest_challenge")) {
> append_to_reply("%$digest_challenge");
> };
> t_reply("401", "Unauthorized");
> break;
> };
>[some more unrelated processing and checks...]
> xlog("L_INFO", "saving contact %ct into the database");
> save_noreply("location");
> if (is_avp_set("s:contact")) {
> append_to_reply("%$contact");
> };
> t_reply("$code", "$reason");
> }
>
> The idea here is to avoid possibly costly DB lookup and other checks on
> each possible re-transmit. What would be the proper way of doing this with
> the OpenSIPS 2.1? Or if it's not possible to replicate such scheme, what
> would be the best way to implement this which to get the change accepted
> into the OpenSIPS mainline?
>
> Any ideas, pointers, hints are greatly appreciated. Thanks in advance!
>
> -Maxim
>
>
>
>
> --
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sa...@sippysoft.com
> Skype: SippySoft
>
>
> --
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Transactional REGISTER processing with 2.1

[Maxim Sobolev]

Hi guys,

We are underway to migrate from ancient SER-2.0.0 to more modern OpenSIPS
and one of the question that is still in my TODO list is implementing
transactional processing of the REGISTER requests. In the old SER we had
something along those lines:

route[3] {
# Ensure that all incoming messages contain auth info
xlog("L_INFO", "processing %rm received from %si:%sp");
if (!t_newtran()) {
sl_send_reply("500", "could not create transaction");
break;
};
if (!python_exec("www_authenticate")) {
xlog("L_INFO", "challenging %ct");
if (is_avp_set("s:digest_challenge")) {
append_to_reply("%$digest_challenge");
};
t_reply("401", "Unauthorized");
break;
};
   [some more unrelated processing and checks...]
xlog("L_INFO", "saving contact %ct into the database");
save_noreply("location");
if (is_avp_set("s:contact")) {
append_to_reply("%$contact");
};
t_reply("$code", "$reason");
}

The idea here is to avoid possibly costly DB lookup and other checks on
each possible re-transmit. What would be the proper way of doing this with
the OpenSIPS 2.1? Or if it's not possible to replicate such scheme, what
would be the best way to implement this which to get the change accepted
into the OpenSIPS mainline?

Any ideas, pointers, hints are greatly appreciated. Thanks in advance!

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

Re: [OpenSIPS-Users] Transactional REGISTER processing with 2.1

[Maxim Sobolev]

P.S. python_exec("www_authenticate") does not do any magic here, it's just
figures out the right domain to use based on some business rules and then
calls www_authenticate() with that parameter.

On Fri, Feb 17, 2017 at 11:12 AM, Maxim Sobolev <sobo...@sippysoft.com>
wrote:

> Hi guys,
>
> We are underway to migrate from ancient SER-2.0.0 to more modern OpenSIPS
> and one of the question that is still in my TODO list is implementing
> transactional processing of the REGISTER requests. In the old SER we had
> something along those lines:
>
> route[3] {
> # Ensure that all incoming messages contain auth info
> xlog("L_INFO", "processing %rm received from %si:%sp");
> if (!t_newtran()) {
> sl_send_reply("500", "could not create transaction");
> break;
> };
> if (!python_exec("www_authenticate")) {
> xlog("L_INFO", "challenging %ct");
> if (is_avp_set("s:digest_challenge")) {
> append_to_reply("%$digest_challenge");
> };
> t_reply("401", "Unauthorized");
> break;
> };
>[some more unrelated processing and checks...]
> xlog("L_INFO", "saving contact %ct into the database");
> save_noreply("location");
> if (is_avp_set("s:contact")) {
> append_to_reply("%$contact");
> };
> t_reply("$code", "$reason");
> }
>
> The idea here is to avoid possibly costly DB lookup and other checks on
> each possible re-transmit. What would be the proper way of doing this with
> the OpenSIPS 2.1? Or if it's not possible to replicate such scheme, what
> would be the best way to implement this which to get the change accepted
> into the OpenSIPS mainline?
>
> Any ideas, pointers, hints are greatly appreciated. Thanks in advance!
>
> -Maxim
>



-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available

[Maxim Sobolev]

Another issue with 2.1.x, the -C option (check config) seems to have
rotten. It was expected to check basic things about config that does not
require setting up full run-time environment, but it is not even checking
inter-module dependencies. I.e.:

[sobomax@van01 ~/projects/voiptests]$ ./dist/opensips/opensips -f
opensips.cfg -C
Listening on
 udp: 127.0.0.1 [127.0.0.1]:5060
Aliases:
 udp: localhost.my.domain:5060
 udp: localhost:5060

Aug 24 13:51:54 [31495] NOTICE:core:main: config file ok, exiting...
[sobomax@van01 ~/projects/voiptests]$ ./dist/opensips/opensips -f
opensips.cfg -D -E
Listening on
 udp: 127.0.0.1 [127.0.0.1]:5060
Aliases:
 udp: localhost.my.domain:5060
 udp: localhost:5060

Aug 24 13:52:02 [31820] WARNING:core:main: no fork mode
Aug 24 13:52:02 [31820] NOTICE:core:main: version: opensips 2.1.1
(x86_64/freebsd)
Aug 24 13:52:02 [31820] WARNING:core:solve_module_dependencies: module
rtpproxy depends on module dialog, but it was not loaded!
Aug 24 13:52:02 [31820] ERROR:core:init_modules: failed to solve module
dependencies
Aug 24 13:52:02 [31820] ERROR:core:main: error while initializing modules

I've opened a ticket on that (#616).

On Mon, Aug 24, 2015 at 12:02 PM, Maxim Sobolev sobo...@sippysoft.com
wrote:

 No, we have not loaded it yet. Is it now always required? As I said my
 point here is not so much how to fix it, but the fact that Liviu Chircu
 said that loading such module is just a workaround and the proper fix would
 be applied before the 2.1 x release goes out. If it was decided that
 loading module is now the official way to go, then it should be reflected
 in the relnotes IMHO.

 -Maxim

 On Sat, Aug 22, 2015 at 11:18 AM, Bogdan-Andrei Iancu bog...@opensips.org
  wrote:

 Hi Maxim,

 Do you load the proto_udp module ?

 Regards,
 Bogdan


 Sent from Samsung Mobile


  Original message 
 From: Maxim Sobolev
 Date:22/08/2015 18:48 (GMT+02:00)
 To: OpenSIPS devel mailling list
 Cc: n...@lists.opensips.org,users@lists.opensips.org,
 busin...@lists.opensips.org
 Subject: Re: [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available

 Hi Bogdan,

 For some reason 2.1.x is still failing our voiptests travis run with the
 following error when trying to run in the UDP-only mode:

 Aug 22 15:32:00 [10854] ERROR:core:fix_all_socket_lists: listeners found for 
 protocol udp, but no module can handle it

 Aug 22 15:32:00 [10854] ERROR:core:main: failed to initialize list addresses

 It was told on the mailing list before that it would be fixed before the
 release:


 http://opensips-open-sip-server.1449251.n2.nabble.com/Unable-to-start-opensips-2-1-1dev-in-UDP-only-mode-td7595563.html

 So I guess that never happened. Could you guys look into it or at least
 add some kind of errata or relnotes entry?

 Thanks!

 -Maxim


 On Wed, Aug 19, 2015 at 11:03 AM, Bogdan-Andrei Iancu 
 bog...@opensips.org wrote:

 Hello everyone,

 Minor version 2.1.1 is now available on branch 2.1. This is a release
 bringing multiple and valuable fixes, a result of the continues work of
 testing and fixing the revolutionary 2.1 version.

 Please update as soon as possible as it worth it ! Download the tarball
 with sources from :
 http://opensips.org/pub/opensips/2.1.1/

 RPM and DEB packages will be shortly available on the official
 repositories, after the nightly builts.

 There are hundreds of reports, tens of fixes and maybe several hundreds
 of commits - all these are the result of the entire OpenSIPS community -
 people testing, reporting and fixes. And I want to thanks to all these
 people, to these OpenSIPS'ers !

 Enjoy 2.1.1 !!

 --
 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developer
 http://www.opensips-solutions.com


 ___
 Devel mailing list
 de...@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




 --
 Maksym Sobolyev
 Sippy Software, Inc.
 Internet Telephony (VoIP) Experts
 Tel (Canada): +1-778-783-0474
 Tel (Toll-Free): +1-855-747-7779
 Fax: +1-866-857-6942
 Web: http://www.sippysoft.com
 MSN: sa...@sippysoft.com
 Skype: SippySoft




 --
 Maksym Sobolyev
 Sippy Software, Inc.
 Internet Telephony (VoIP) Experts
 Tel (Canada): +1-778-783-0474
 Tel (Toll-Free): +1-855-747-7779
 Fax: +1-866-857-6942
 Web: http://www.sippysoft.com
 MSN: sa...@sippysoft.com
 Skype: SippySoft




-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available

[Maxim Sobolev]

No, we have not loaded it yet. Is it now always required? As I said my
point here is not so much how to fix it, but the fact that Liviu Chircu
said that loading such module is just a workaround and the proper fix would
be applied before the 2.1 x release goes out. If it was decided that
loading module is now the official way to go, then it should be reflected
in the relnotes IMHO.

-Maxim

On Sat, Aug 22, 2015 at 11:18 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:

 Hi Maxim,

 Do you load the proto_udp module ?

 Regards,
 Bogdan


 Sent from Samsung Mobile


  Original message 
 From: Maxim Sobolev
 Date:22/08/2015 18:48 (GMT+02:00)
 To: OpenSIPS devel mailling list
 Cc: n...@lists.opensips.org,users@lists.opensips.org,
 busin...@lists.opensips.org
 Subject: Re: [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available

 Hi Bogdan,

 For some reason 2.1.x is still failing our voiptests travis run with the
 following error when trying to run in the UDP-only mode:

 Aug 22 15:32:00 [10854] ERROR:core:fix_all_socket_lists: listeners found for 
 protocol udp, but no module can handle it

 Aug 22 15:32:00 [10854] ERROR:core:main: failed to initialize list addresses

 It was told on the mailing list before that it would be fixed before the
 release:


 http://opensips-open-sip-server.1449251.n2.nabble.com/Unable-to-start-opensips-2-1-1dev-in-UDP-only-mode-td7595563.html

 So I guess that never happened. Could you guys look into it or at least
 add some kind of errata or relnotes entry?

 Thanks!

 -Maxim


 On Wed, Aug 19, 2015 at 11:03 AM, Bogdan-Andrei Iancu bog...@opensips.org
  wrote:

 Hello everyone,

 Minor version 2.1.1 is now available on branch 2.1. This is a release
 bringing multiple and valuable fixes, a result of the continues work of
 testing and fixing the revolutionary 2.1 version.

 Please update as soon as possible as it worth it ! Download the tarball
 with sources from :
 http://opensips.org/pub/opensips/2.1.1/

 RPM and DEB packages will be shortly available on the official
 repositories, after the nightly builts.

 There are hundreds of reports, tens of fixes and maybe several hundreds
 of commits - all these are the result of the entire OpenSIPS community -
 people testing, reporting and fixes. And I want to thanks to all these
 people, to these OpenSIPS'ers !

 Enjoy 2.1.1 !!

 --
 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developer
 http://www.opensips-solutions.com


 ___
 Devel mailing list
 de...@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




 --
 Maksym Sobolyev
 Sippy Software, Inc.
 Internet Telephony (VoIP) Experts
 Tel (Canada): +1-778-783-0474
 Tel (Toll-Free): +1-855-747-7779
 Fax: +1-866-857-6942
 Web: http://www.sippysoft.com
 MSN: sa...@sippysoft.com
 Skype: SippySoft




-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available

[Maxim Sobolev]

Hi Bogdan,

For some reason 2.1.x is still failing our voiptests travis run with the
following error when trying to run in the UDP-only mode:

Aug 22 15:32:00 [10854] ERROR:core:fix_all_socket_lists: listeners
found for protocol udp, but no module can handle it

Aug 22 15:32:00 [10854] ERROR:core:main: failed to initialize list addresses

It was told on the mailing list before that it would be fixed before the
release:

http://opensips-open-sip-server.1449251.n2.nabble.com/Unable-to-start-opensips-2-1-1dev-in-UDP-only-mode-td7595563.html

So I guess that never happened. Could you guys look into it or at least add
some kind of errata or relnotes entry?

Thanks!

-Maxim


On Wed, Aug 19, 2015 at 11:03 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:

 Hello everyone,

 Minor version 2.1.1 is now available on branch 2.1. This is a release
 bringing multiple and valuable fixes, a result of the continues work of
 testing and fixing the revolutionary 2.1 version.

 Please update as soon as possible as it worth it ! Download the tarball
 with sources from :
 http://opensips.org/pub/opensips/2.1.1/

 RPM and DEB packages will be shortly available on the official
 repositories, after the nightly builts.

 There are hundreds of reports, tens of fixes and maybe several hundreds of
 commits - all these are the result of the entire OpenSIPS community -
 people testing, reporting and fixes. And I want to thanks to all these
 people, to these OpenSIPS'ers !

 Enjoy 2.1.1 !!

 --
 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developer
 http://www.opensips-solutions.com


 ___
 Devel mailing list
 de...@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [OpenSIPS-Devel] May's Public Meeting

[Maxim Sobolev]

Hi Razvan, my only suggestion is to move those meetings either early in the
morning or later in the afternoon, so that those of us who are behind UTC
by many hours have a chance to take part. 13 UTC is like 5am here.  Maybe
not this one if it's too much trouble to reschedule, but something to
consider for the future ones. Thanks!

-Max
On May 22, 2015 9:44 AM, Răzvan Crainea raz...@opensips.org wrote:

 Hello all!

 This month's public meeting is scheduled for the next Wednesday,
 27.05.2015, at 13:00 UTC[1].

 The topic for this session is a discussion on how to create a distributed
 user location mechanism. More information on the topic will be sent by the
 begining of the next week.

 As usual, we are very interested in your opinion, so make sure you don't
 miss this meeting!

 [1]
 http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenSIPS+Public+Meetingiso=20150527T18p1=49ah=1
 [2] http://www.opensips.org/Community/IRCmeeting20150527

 Best regards,

 --
 Răzvan Crainea
 OpenSIPS Solutions
 www.opensips-solutions.com


 ___
 Devel mailing list
 de...@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

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

Re: [OpenSIPS-Users] [RTPproxy] Re: Announcing rtpproxy v2.0.0

[Maxim Sobolev]

Pull requests are welcome, guys. We are hitting 30k rtp sessions on one of
our largest clusters. Lot of changes are coming into git repo soon to make
rtp_cluster component run smoothly under such conditions.
On Mar 16, 2015 8:56 PM, John Mathew john.mat...@divoxmedia.com wrote:

 Yes

 On Tuesday, 17 March 2015, Zheng Frank zhengyumingap...@gmail.com wrote:

 Do you mean ROHC ?

 2015-03-14 12:39 GMT+08:00 Maxim Sobolev sobo...@sippysoft.com:

 Do you have any particular RFC in mind?
 On Mar 12, 2015 10:28 AM, John Mathew john.mat...@divoxmedia.com
 wrote:

 Hi,

 Maxim,
 Is there any plans for rtp header compression in future. I can't see
 anything in the change log for 2.0.0


 On Tuesday, 10 March 2015, Maxim Sobolev sobo...@sippysoft.com wrote:

 Hi All,

 I'm happy to announce that we have released rtpproxy v2.0.0.

 You can review the release notes here:
 https://github.com/sippy/rtpproxy/releases/tag/v2.0.0

 -sobomax



 --
 Sent from iPhone 6

 --
 You received this message because you are subscribed to the Google
 Groups rtpproxy group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to rtpproxy+unsubscr...@googlegroups.com.
 To post to this group, send email to rtppr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpUhu9fpwmqpRFiaXsQo9_%2B6M8MFtJ2sKi4kd5sr%3Ds%2BR5Q%40mail.gmail.com
 https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpUhu9fpwmqpRFiaXsQo9_%2B6M8MFtJ2sKi4kd5sr%3Ds%2BR5Q%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.


 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-us...@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




 --
 Sent from iPhone 6

 --
 You received this message because you are subscribed to the Google Groups
 rtpproxy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to rtpproxy+unsubscr...@googlegroups.com.
 To post to this group, send email to rtppr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpWvmaQnE8qM8ibb10d%3DNj9M8cAvzhvgvqh5QqOu3L0D-w%40mail.gmail.com
 https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpWvmaQnE8qM8ibb10d%3DNj9M8cAvzhvgvqh5QqOu3L0D-w%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.

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

[OpenSIPS-Users] Announcing rtpproxy v2.0.0

[Maxim Sobolev]

Hi All,

I'm happy to announce that we have released rtpproxy v2.0.0.

You can review the release notes here:
https://github.com/sippy/rtpproxy/releases/tag/v2.0.0

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

Re: [OpenSIPS-Users] RTPproxy project

[Maxim Sobolev]

If you can adapt it to rtpp_2_0 that would be great. This is our latest
production code and it's pretty much superset of the 1.x feature and
performance wise. I've just pushed some fixes to get it compile cleanly on
Ubuntu using just GNU make.

Are you guys registered on github? I've been trying to add you to the
repository ACL list but could not find anyone. Jev is off for few days, but
he should be back tomorrow to finish migration of the website etc.

Thanks!

-Maxim


On Fri, Jun 27, 2014 at 7:51 AM, Răzvan Crainea raz...@opensips.org wrote:

 Hi, Maxim!

 Good news, I am glad you are interested in these features. I will fork the
 project in our organization and push the requests there so you can revise
 them before merging them.
 We currently have them implemented for 1.2 - shall we adapt the changes
 for the master branch?

 Best regards,

 Razvan Crainea
 OpenSIPS Core Developer
 http://www.opensips-solutions.com


 On 06/20/2014 11:45 PM, Maxim Sobolev wrote:

 Hey Bogdan, thanks for sharing your ideas for us. In fact all of those
 items that you have listed are already on drawing board for the next 2-3
 months development here:

- Send timeout notifications to different OpenSIPS servers (more than
 one)
- Different timeout values for early media and established calls
 (longer for early, shorter for established)
- Play music on hold in early media state
- Detect on-hold and disable timeouts (search different solution here)
- Do not send media timeout if other sessions are active (video and
 audio)
- In bridge mode asymmetric should not be always assumed
- Cache played files instead of reading them from the disk all the time

 I am particularly interested in the timeout notifications and cache for
 playing files, so maybe you can start with forking out main branch in
 the github and pushing your patches there? For playing cache, I have
 been planning to use mmap() and refcounting, so I am particularly
 curious which path did you take. We need this in order so that we can
 use rtpproxy to generate test streams for other rtpproxy, or maybe even
 to itself. I have started some automated regression testing suite here
 we will be pushing it our pretty soon.




 On Fri, Jun 20, 2014 at 2:22 AM, Bogdan-Andrei Iancu
 bog...@opensips.org mailto:bog...@opensips.org wrote:

 Hello Maxim, Hello Jev,

 Sorry for taking so long to answer to these emails.

 I'm really glad to find out that the rtpproxy project is actually
 moving along and even more, evolving - it is a critical component in
 our platforms (and for most OpenSIPS deployments) and we got a bit
 concerned about what is going on with rtpp. To be honest, we had on
 the table the possibility to fork it and continue by ourselves - but
 I do not want to re-invent the wheel or to pollute the environment
 with yet another relay relaying tool (anyhow, there is this
 rtpengine stuff popping around lately )

 We will be more than happy to get involved - as ideas, experience
 and work - in the rtpproxy evolution ; of course, if you guys are
 willing to accept it :).  One again , rtpproxy is too important to
 us to stay neutral and lately there are more and more features
 touching both SIP and RTP so there is a strong need for a better
 integration between OpenSIPS and RTPProxy, IMHO.

 Now, technically speaking, the kind of problems we mainly faced are
 (a) scaling with HW (especially with the old single threaded model),
 (b) redundancy and (c) controlling streams (multiple streams
 audio/video in the same SIP session, on-hold, etc).

 What we did (and have as patches):
- Send timeout notifications to different OpenSIPS servers (more
 than one)
- Different timeout values for early media and established calls
 (longer for early, shorter for established)
- Play music on hold in early media state
- Detect on-hold and disable timeouts (search different solution
 here)
- Do not send media timeout if other sessions are active (video
 and audio)
- In bridge mode asymmetric should not be always assumed
- Cache played files instead of reading them from the disk all
 the time


 Also we are looking into new features (things that we can work
 together) :
- better structuring between sessions and streams
- Send timeout notifications over UDP
- Force specific ports in reply, if possible
- Failover support
- Provide statistics per session (even ended) back to OpenSIPS
- Restart persistent
- Change learning period (possibly linked with on-hold media
 disable)
- ICE support
- SRTP to RTP conversion

 Definitly we can look into transcoding part too - what we did is for
 Sangoma cards (so HW transcoding, not SW).



 So, we will look into the new work you guys did on rtpproxy - to
 have

Re: [OpenSIPS-Users] RTPproxy project

[Maxim Sobolev]

Hey Bogdan, thanks for sharing your ideas for us. In fact all of those
items that you have listed are already on drawing board for the next 2-3
months development here:

  - Send timeout notifications to different OpenSIPS servers (more than one)
  - Different timeout values for early media and established calls (longer
for early, shorter for established)
  - Play music on hold in early media state
  - Detect on-hold and disable timeouts (search different solution here)
  - Do not send media timeout if other sessions are active (video and
audio)
  - In bridge mode asymmetric should not be always assumed
  - Cache played files instead of reading them from the disk all the time

I am particularly interested in the timeout notifications and cache for
playing files, so maybe you can start with forking out main branch in the
github and pushing your patches there? For playing cache, I have been
planning to use mmap() and refcounting, so I am particularly curious which
path did you take. We need this in order so that we can use rtpproxy to
generate test streams for other rtpproxy, or maybe even to itself. I have
started some automated regression testing suite here we will be pushing it
our pretty soon.




On Fri, Jun 20, 2014 at 2:22 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:

  Hello Maxim, Hello Jev,

 Sorry for taking so long to answer to these emails.

 I'm really glad to find out that the rtpproxy project is actually moving
 along and even more, evolving - it is a critical component in our platforms
 (and for most OpenSIPS deployments) and we got a bit concerned about what
 is going on with rtpp. To be honest, we had on the table the possibility to
 fork it and continue by ourselves - but I do not want to re-invent the
 wheel or to pollute the environment with yet another relay relaying tool
 (anyhow, there is this rtpengine stuff popping around lately )

 We will be more than happy to get involved - as ideas, experience and work
 - in the rtpproxy evolution ; of course, if you guys are willing to accept
 it :).  One again , rtpproxy is too important to us to stay neutral and
 lately there are more and more features touching both SIP and RTP so
 there is a strong need for a better integration between OpenSIPS and
 RTPProxy, IMHO.

 Now, technically speaking, the kind of problems we mainly faced are (a)
 scaling with HW (especially with the old single threaded model), (b)
 redundancy and (c) controlling streams (multiple streams audio/video in the
 same SIP session, on-hold, etc).

 What we did (and have as patches):
   - Send timeout notifications to different OpenSIPS servers (more than
 one)
   - Different timeout values for early media and established calls (longer
 for early, shorter for established)
   - Play music on hold in early media state
   - Detect on-hold and disable timeouts (search different solution here)
   - Do not send media timeout if other sessions are active (video and
 audio)
   - In bridge mode asymmetric should not be always assumed
   - Cache played files instead of reading them from the disk all the time


 Also we are looking into new features (things that we can work together) :
   - better structuring between sessions and streams
   - Send timeout notifications over UDP
   - Force specific ports in reply, if possible
   - Failover support
   - Provide statistics per session (even ended) back to OpenSIPS
   - Restart persistent
   - Change learning period (possibly linked with on-hold media disable)
   - ICE support
   - SRTP to RTP conversion

 Definitly we can look into transcoding part too - what we did is for
 Sangoma cards (so HW transcoding, not SW).



 So, we will look into the new work you guys did on rtpproxy - to have a
 starting point for the future planning. After that, if you agree on having
 us contributing to the rtpproxy, we can get involved in planning and actual
 development.

 Best regards,

 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developerhttp://www.opensips-solutions.com

 On 20.06.2014 02:16, Jev Björsell wrote:

 Hi Guys,

  Some updates on the rtpproxy project;

  We have now moved the rtpproxy project from sourceforge to github
 http://github.com/sippy/rtpproxy

  This change should make the project more visibility  and transparency.
 Please feel free to create Issues for feature requests and bugs, and of
 course Pull Requests are appreciated! :)

  We have also moved the mailing list over to Google Groups:
 https://groups.google.com/forum/#!forum/rtpproxy

  We will do a maintenance release - version 1.3, and  Max is busy working
 on a 2.0 release, which has some significant improvements to jitter
 characteristics,  and performance.

  Best Regards,
 -Jev



 On Mon, Jun 9, 2014 at 8:25 AM, Maxim Sobolev sobo...@sippysoft.com
 wrote:

   Hey Bogdan, sorry for missing your message. The mail traffic these
 days is insane, so it's hard to keep atop of all issues.

  We are working behind the scene on what would become rtpproxy 2.0

Re: [OpenSIPS-Users] [OpenSIPS-Devel] One way audio problem

[Maxim Sobolev]

Hi, please also submit relevant call setup logs from the rtpp. They are
essential to diagnose the issue. You can grep logs by respective call-id.
Thanks!
On Jun 18, 2014 7:14 AM, kaushik parmar androidj...@gmail.com wrote:

 Hello All,

 I have configured opensips.cfg file and able call extensions of asterisk
 via opensips+rtpproxy. Now problem is that the solution is not stable.
 Sometimes it sends two way audio and sometimes single side audio problem. I
 can not identify what is problem with the solution. It working for a call
 and after sometimes it has single side audio problem.


 *Single side audio log*

  rtpproxy[3082]: INFO:handle_delete: forcefully deleting session 1 on ports 
 35006/35008
  rtpproxy[3082]: INFO:remove_session: RTP stats: 0 in from callee, 8466 in 
 from caller, 8466 relayed, 0 dropped
  rtpproxy[3082]: INFO:remove_session: RTCP stats: 32 in from callee, 36 in 
 from caller, 68 relayed, 0 dropped
  rtpproxy[3082]: INFO:remove_session: session on ports 35006/35008 is cleaned 
 up
  rtpproxy[3082]: INFO:remove_session: RTCP stats: 32 in from callee, 36 in 
 from caller, 68 relayed, 0 dropped
  rtpproxy[3082]: INFO:remove_session: session on ports 35006/35008 is cleaned 
 up
  opensips[11877]: ACC: transaction answered: 
 timestamp=1403099904;method=BYE;from_tag=-UCwMHAsR;to_tag=gpclohfolgwgooy2.i;call_id=aJU-wli5bR;code=200;reason=OK


 *Two Way Audio log*


  rtpproxy[3082]: INFO:handle_delete: forcefully deleting session 1 on ports 
 35016/35010
  rtpproxy[3082]: INFO:remove_session: RTP stats: 2251 in from callee, 2364 in 
 from caller, 4615 relayed, 0 dropped
  rtpproxy[3082]: INFO:remove_session: RTCP stats: 9 in from callee, 12 in 
 from caller, 21 relayed, 0 dropped
  rtpproxy[3082]: INFO:remove_session: session on ports 35016/35010 is cleaned 
 up
  rtpproxy[3082]: INFO:remove_session: RTP stats: 2251 in from callee, 2364 in 
 from caller, 4615 relayed, 0 dropped
  rtpproxy[3082]: INFO:remove_session: RTCP stats: 9 in from callee, 12 in 
 from caller, 21 relayed, 0 dropped
  rtpproxy[3082]: INFO:remove_session: session on ports 35016/35010 is cleaned 
 up
  rtpproxy[3082]: INFO:handle_command: delete request failed: session 
 PwN15Vi6mz, tags LFUZbv7xG/fozygygpzem75cyd.i not found



 What is wrong with this? It sends audio two way and suddenly on second
 call one way audio problem occurs.

 Please help to resolve the issue. I am using *rtpproxy_offer(corsw); *in
 onreply_route[] function.


 --
 Kind regards,

 Kaushik Parmar

 ___
 Devel mailing list
 de...@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


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

Re: [OpenSIPS-Users] [OpenSIPS-Devel] Fwd: RTPproxy project

[Maxim Sobolev]

Brett, on the HA/carrier-grade side there is little-advertized middle-layer
component called rtp_cluster, which in essence is load-balancing,
transparent dispatcher that can be inserted in between some
call-controlling component like OpenSIPS or Sippy B2BUA and bunch of RTPP
instances running on the same or multiple nodes. From the point of view of
that OpenSIPS it's just another RTPP instance.

And it handles all logic necessary to load-balance incoming requests
between online instances plus it can handle dynamic re-confiduration of the
cluster and track individual nodes going up and down. The code is pretty
usable, we have it deployed for several customers and it's being actively
developed as well. We have it working reliably controlling up to 30-40 RTPP
instances scattered over at least 5 nodes.

http://sourceforge.net/p/sippy/sippy/ci/master/tree/rtp_cluster/

We have at least one pretty well known service provider whose name starts
with capital V using it in combination with OpenSIPS to load balance RTP
traffic via bunch of Amazon EC2 instances.


On Tue, May 27, 2014 at 6:52 AM, Brett Nemeroff br...@nemeroff.com wrote:

 Just wanted to add my 0.02 here..

 I totally agree with Bogdan. For the applications where opensips + a RTP
 relay make sense, HA and persistence are much more important.

 WebRTC and ICE are kinda applications in of themselves. And although these
 applications are going to grow in popularity, the legacy needs for an RTP
 relay are still massively prevalent in the space. A general push towards
 Carrier Grade, resiliency and redundancy I think is much better for the
 project as a whole.

 Not only that, consider that applications requiring ICE or WebRTC will
 greatly benefit from HA / persistence, but not so much the other way around
 :)

 YMMV

 -Brett



 On Sun, May 25, 2014 at 6:30 AM, Bogdan-Andrei Iancu bog...@opensips.org
 wrote:

  Hello,

 As always, the truth is in the middle.

 I agree RTPP is behind on certain things (and this is why we want to do
 them), but on the other hand it is a good platform with other good features
 (missing on the other relays). RTPP has better ability in individually
 controlling the stream (audio /video), ability to set timeouts and onhold
 with no conflicts, ability to generates events on timeout, more flexibility
 in handling symmetric / asymmetric NATs, ability to do media injection
 (playback), ability to do call recording

 What neither  mediaproxy, nor rtpengine have is a mechanism for
 implementing RTP failover (for ongoing calls) or restart persistence . This
 is something we want to look into. I would love to have ICE and WebRTC on
 my media relay, for the HA and persistence are more important I would say.

 Regards,

 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developerhttp://www.opensips-solutions.com

 On 24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

 To be honest, i have stopped using rtpproxy for over 2 years now. It is
 not evolving as fast as it should be, specially in the context of ICE and
 WebRTC technologies.

 I would like to suggest that opensips team should consider adding support
 for rtpengine from SIPWise,

 https://github.com/sipwise/rtpengine

 For now mediaproxy from AG Projects is the only good choice for handling
 media in opensips with ICE support (though it still lacks WebRTC features).

 Thank you.



 On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

 Going for a public exposure on this question to Maxim, maybe we will get
 an answer here.


  Original Message   Subject: RTPproxy project  Date: Mon,
 14 Apr 2014 15:03:31 +0300  From: Bogdan-Andrei Iancu  To: Maxim Sobolev
 CC: Razvan Crainea

 Hello Maxim,

 Long time, no talks, but I hope everything is fine on your side.

 I'm reaching you in order to ask about your future plans in regards to
 the rtpproxy project? We see no much activity around it and other media
 relays are popping around.

 RTPP is an essential component for us, we invested a lot of work, we
 have many patches (extensions) for it (which we want to push to the
 public tree, but there is no answer on this) and we are also looking for
 investing a lot into big future plans (as adding more functionalities).

 Now, my question is - what is your commitment and disponibility for the
 RTPP project ? depending on that we what to re-position ourselves, as we
 do not want to waste time and work on things which are out of control.

 Best regards,

 --
 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developerhttp://www.opensips-solutions.com

   --
 Mit freundlichen Grüßen
 Muhammad Shahzad
 ---
 CISCO Rich Media Communication Specialist (CRMCS)
 CISCO Certified Network Associate (CCNA)
 Cell: +49 176 99 83 10 85
 MSN: shari_78...@hotmail.com
 Email: shaherya...@googlemail.com



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

Re: [OpenSIPS-Users] RtpRroxy sturtup (init.d) script for redhat

[Maxim Sobolev]

Bogdan-Andrei Iancu wrote:
 Hi Vladimir,
 
 really nice, indeed - I did this manually all the time :)
 
 Maybe Maxim can integrate this directly in the RTPproxy project

Yes, I will do it.

In fact we plan moving towards multi-threading design in the next 
release, which should make utilizing multi-core chips much easier.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft

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

Re: [OpenSIPS-Users] RtpRroxy sturtup (init.d) script for redhat

[Maxim Sobolev]

Romanov Vladimir wrote:
 Hi!
 Could you please add command line option to change syslog FACILITY? Now I 
 simply modify this in source and recompile.

Vladimir,

Can you please send a patch?

Thanks!

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft

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