[OpenSIPS-Users] Mid-registrar with AOR throttling - clearing registration
We have a mid-registrar (OpenSIPS 3.1) in front of an Asterisk node. Mid-registrar saves with the 'memory only' flag. We are using AOR throttling We've had a few occasions where something has gone wrong with the registration on Asterisk so that Asterisk thinks an extension is no longer registered, but OpenSIPS thinks it still is. We've resolved these occurrences but they have raised a question for the future. In a situation where mid-registrar is holding onto a registration but Asterisk thinks the registration no longer exists, is there a way to tell the mid-registrar to expire the registration, either forcing a re-register on Asterisk, or at least so that the next re-register from a client is forwarded on to Asterisk? Obviously, we have the option of restarting OpenSIPS, but that would affect all registered clients rather than a single problematic one. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS and Speech-to-Text
Thanks for that Johan - I hadn't thought about that aspect. All theoretic at the moment, but IBM Voice Gateway, at least, does claim to be able to handle it using SIPREC - so maybe they are confident about their ability to differentiate between caller and callee in a single stream?... "The voice gateway provides the ability to transcribe caller and callee > (e.g. contact-center agent) audio from an active phone call in real time > using the SIPREC protocol." - > https://www.ibm.com/docs/en/voice-gateway?topic=gateway-about-voice > On Fri, 17 Sept 2021 at 10:33, johan wrote: > The issue with siprec (based on rtpproxy) is that you have only 1 stream > containing the voice from caller to callee and callee to caller. So that > will give a hard time on the ASR :-). I do know that rtpengine has > something similar to siprec but I don't know the details. > > > Bottom line, in my opinion, you need to have 2 separate streams before you > can start STT. > > > wkr, > > > On 17/09/2021 11:04, Mark Allen wrote: > > I'm just starting to look at Speech-to-Text (STT) processing for calls - > initially recordings but moving on to real-time. I would see this working > along the lines of either: > > - a call is recorded, and when the call ends an event is triggered to > initiate transcription of the recording > - a call starts, the RTP is forked to the STT engine which sends real-time > transcription > > I can see that with OpenSIPS, the SIPREC and Media Exchange modules allow > for forking of the RTP, providing a means of sending the data for > processing, but is anybody actually doing this? If so, what has been > your experience? Is there a toolset that works well with this (e.g. IBM > Voice Gateway, Google, Amazon etc)? > > ___ > 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
[OpenSIPS-Users] OpenSIPS and Speech-to-Text
I'm just starting to look at Speech-to-Text (STT) processing for calls - initially recordings but moving on to real-time. I would see this working along the lines of either: - a call is recorded, and when the call ends an event is triggered to initiate transcription of the recording - a call starts, the RTP is forked to the STT engine which sends real-time transcription I can see that with OpenSIPS, the SIPREC and Media Exchange modules allow for forking of the RTP, providing a means of sending the data for processing, but is anybody actually doing this? If so, what has been your experience? Is there a toolset that works well with this (e.g. IBM Voice Gateway, Google, Amazon etc)? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] RTPEngine - changing codec format parameters from default values when transcoding - OpenSIPS 3.1
Just posting this to document the end result. The following line to pass the transcoding parameters I wanted directly to the RTPEngine daemon worked for me: transcode-opus/48000/2/32000//stereo--0;useinbandfec--1;maxplaybackrate--16000;sprop-maxcapturerate--16000 NB - The '--' part means '=' and is there to avoid parsing errors in RTPEngine On Wed, 15 Sept 2021 at 10:58, Johan De Clercq wrote: > No worries > > On Wed, Sep 15, 2021, 11:43 Mark Allen wrote: > >> Ah! Thanks Răzvan and Johan. I was thinking that the options described in >> the OpenSIPS RTPEngine module documentation were the only ones >> available, but I missed the key phrase... >> >> *When passing an option that OpenSIPS is not aware of, it will be >> blindly sent to the rtpengine daemon to be processed.* >> >> ...I should be fine from here I think. Thanks for your help. >> >> >> On Tue, 14 Sept 2021 at 14:29, Răzvan Crainea >> wrote: >> >>> I think the proper way to do it is >>> >>> `transcode-opus/48000/2/32000//maxplaybackrate--48000;stereo--0;useinbandfec--1;maxaveragebitrate--32000` >>> Anyway, as Johan suggests, follow the rtpengine documentation, you will >>> find more info there. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 9/14/21 15:51, Mark Allen wrote: >>> > Hi Răzvan >>> > >>> > OpenSIPS passes the commands to RTPengine as you supply them, so in >>> > theory this should be supported. Did you try to set this up? Can >>> you >>> > provide any logs about this? >>> > >>> > >>> > No. I'm not sure how I would specify this in the opensips.cfg >>> > rtpengine_offer parameters. From the documentation for the >>> > rptengine OpenSIPS module, it doesn't seem as if something like the >>> > following is an option... >>> > >>> > >>> > >>> transcode-opus='opus/48000/2/32000//maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000' >>> >>> > >>> > >>> > ...however, if I have tried this in the code (with or without quotes) >>> it >>> > doesn't produce an error, either from OpenSIPS or rtpengine, but >>> neither >>> > does it do anything - Opus fmtp in the SDP is not changed. I guess I'm >>> > looking for the correct OpenSIPS syntax to pass these parameters >>> > successfully to rtpengine >>> > >>> > >>> > >>> > ___ >>> > 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 >> > ___ > 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] RTPEngine - changing codec format parameters from default values when transcoding - OpenSIPS 3.1
Ah! Thanks Răzvan and Johan. I was thinking that the options described in the OpenSIPS RTPEngine module documentation were the only ones available, but I missed the key phrase... *When passing an option that OpenSIPS is not aware of, it will be blindly sent to the rtpengine daemon to be processed.* ...I should be fine from here I think. Thanks for your help. On Tue, 14 Sept 2021 at 14:29, Răzvan Crainea wrote: > I think the proper way to do it is > > `transcode-opus/48000/2/32000//maxplaybackrate--48000;stereo--0;useinbandfec--1;maxaveragebitrate--32000` > Anyway, as Johan suggests, follow the rtpengine documentation, you will > find more info there. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 9/14/21 15:51, Mark Allen wrote: > > Hi Răzvan > > > > OpenSIPS passes the commands to RTPengine as you supply them, so in > > theory this should be supported. Did you try to set this up? Can you > > provide any logs about this? > > > > > > No. I'm not sure how I would specify this in the opensips.cfg > > rtpengine_offer parameters. From the documentation for the > > rptengine OpenSIPS module, it doesn't seem as if something like the > > following is an option... > > > > > > > transcode-opus='opus/48000/2/32000//maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000' > > > > > > > ...however, if I have tried this in the code (with or without quotes) it > > doesn't produce an error, either from OpenSIPS or rtpengine, but neither > > does it do anything - Opus fmtp in the SDP is not changed. I guess I'm > > looking for the correct OpenSIPS syntax to pass these parameters > > successfully to rtpengine > > > > > > > > ___ > > 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] RTPEngine - changing codec format parameters from default values when transcoding - OpenSIPS 3.1
Hi Răzvan OpenSIPS passes the commands to RTPengine as you supply them, so in > theory this should be supported. Did you try to set this up? Can you > provide any logs about this? > > No. I'm not sure how I would specify this in the opensips.cfg rtpengine_offer parameters. From the documentation for the rptengine OpenSIPS module, it doesn't seem as if something like the following is an option... transcode-opus='opus/48000/2/32000//maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000 ' ...however, if I have tried this in the code (with or without quotes) it doesn't produce an error, either from OpenSIPS or rtpengine, but neither does it do anything - Opus fmtp in the SDP is not changed. I guess I'm looking for the correct OpenSIPS syntax to pass these parameters successfully to rtpengine ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] RTPEngine - changing codec format parameters from default values when transcoding - OpenSIPS 3.1
Hi all, I'm using RTPEngine for transcoding between Opus and PCMU. According to the RTPEngine documentation (https://github.com/sipwise/rtpengine), it can accept formatting parameters for CODECs that support them. For instance, Opus allows you to change the maxaveragebitrate. However, in the OpenSIPS documentation for the RTPEngine module, it only seems to show support for the default options when transcoding - e.g."transcode-opus". Is there a way in OpenSIPS to tell RTPEngine to use values other than the defaults? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 Debian Buster package
Ah! Scratch that. I've got it working now. What I was missing was that the version for apt was 3.1.5-1, so... apt install opensips=3.1.5-1 ...worked for me On Tue, 24 Aug 2021 at 08:03, Mark Allen wrote: > Hi all, > > We're using a Debian Buster system. I've tried installing 3.2 but hit > problems with the database migration. I've tried to revert to 3.1 but can't > seem to access that versions package - 3.2 is the only one I can see. > > As per https://apt.opensips.org/packages.php?v=3.1 I've entered... > > apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 049AD65B > echo "deb https://apt.opensips.org buster 3.1-releases" > >/etc/apt/sources.list.d/opensips.list > echo "deb https://apt.opensips.org buster cli-nightly" > >/etc/apt/sources.list.d/opensips-cli.list > > ...but the only version I can see with 'apt search opensips' is 3.2 > > If I try... > > apt install opensips=3.1 > > ...or... > > apt install opensips=3.1.5 > > ...nothing is found. How do I access the 3.1 package? > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] OpenSIPS 3.1 Debian Buster package
Hi all, We're using a Debian Buster system. I've tried installing 3.2 but hit problems with the database migration. I've tried to revert to 3.1 but can't seem to access that versions package - 3.2 is the only one I can see. As per https://apt.opensips.org/packages.php?v=3.1 I've entered... apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 049AD65B echo "deb https://apt.opensips.org buster 3.1-releases" >/etc/apt/sources.list.d/opensips.list echo "deb https://apt.opensips.org buster cli-nightly" >/etc/apt/sources.list.d/opensips-cli.list ...but the only version I can see with 'apt search opensips' is 3.2 If I try... apt install opensips=3.1 ...or... apt install opensips=3.1.5 ...nothing is found. How do I access the 3.1 package? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rtpengine sets - load balancing proxy weighting
Thanks John. That's really helpful On Fri, 20 Aug 2021, 14:40 John Burke via Users, wrote: > Hey Mark, > > The load balancing weights are set on a per node basis via their socket > URL. If no weight is explicitly set, then the default is 1. > > schema: > ::(=) > > ex: > udp:192.168.1.200:2=25 > > There currently is no way to dynamically change the weight of a node, > although there's an open PR [1] which would allow for weights to be changed > via the "rtpengine_enable" MI command. > > [1] https://github.com/OpenSIPS/opensips/pull/2600 > > Thanks, > John Burke > > > On 8/20/21 5:00 AM, Mark Allen wrote: > > I've not been able to find the answer to this. Can anyone help? > > On Thu, 22 Jul 2021 at 11:02, Mark Allen wrote: > >> In the rtpengine documentation [1] in the section "1.2 - Multiple RTP >> proxy usage" it says... >> >> "The balancing inside a set is done automatically by the module based >> on the weight of each RTP proxy from the set." >> >> >> ...how is the weighting determined? Is there a parameter to allocate a >> weighting value, is weighting allocated by the software dynamically (and if >> so, based on what criteria?), or are all proxies weighted the same? >> >> >> >> [1] >> https://opensips.org/html/docs/modules/3.1.x/rtpengine.html#idp4123616 >> >> >> > ___ > 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
[OpenSIPS-Users] Errors migrating mysql db from OpenSIPS 3.1 to 3.2
I've followed the instructions at:
https://www.opensips.org/Documentation/Migration-3-1-0-to-3-2-0 but
OpenSIPS is now erroring because of DB problems. I see errors along the
lines of:
ERROR:core:db_check_table_version: invalid version 0 for table xcap
found, expected 4
If I go into the database and manually add the version information for each
entry that triggers the error (xcap, presentity, active_watchers, watchers)
using command like...
INSERT INTO version (table_name, table_version) VALUE ('xcap', 4);
...as per https://github.com/OpenSIPS/opensips-cli/issues/54 - it gets me
past theses tests but unsurprisingly then errors with:
CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1146):
Table 'opensips_32.active_watchers' doesn't exist
On OpenSIPS 3.1 DB was loading/working without problem.
I have tried reinstalling opensips-cli using instructions at
https://github.com/OpenSIPS/opensips-cli/blob/master/docs/INSTALLATION.md
(using Debian package as this system runs Debian 10 (Buster) but I still
get the same problem.
Any ideas
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rtpengine sets - load balancing proxy weighting
I've not been able to find the answer to this. Can anyone help? On Thu, 22 Jul 2021 at 11:02, Mark Allen wrote: > In the rtpengine documentation [1] in the section "1.2 - Multiple RTP > proxy usage" it says... > > "The balancing inside a set is done automatically by the module based > on the weight of each RTP proxy from the set." > > > ...how is the weighting determined? Is there a parameter to allocate a > weighting value, is weighting allocated by the software dynamically (and if > so, based on what criteria?), or are all proxies weighted the same? > > > > [1] https://opensips.org/html/docs/modules/3.1.x/rtpengine.html#idp4123616 > > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] rtpengine sets - load balancing proxy weighting
In the rtpengine documentation [1] in the section "1.2 - Multiple RTP proxy usage" it says... "The balancing inside a set is done automatically by the module based on the weight of each RTP proxy from the set." ...how is the weighting determined? Is there a parameter to allocate a weighting value, is weighting allocated by the software dynamically (and if so, based on what criteria?), or are all proxies weighted the same? [1] https://opensips.org/html/docs/modules/3.1.x/rtpengine.html#idp4123616 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] add_path_received and TLS - received address problem
Hi Liviu
On Wed, 21 Jul 2021 at 16:45, Liviu Chircu wrote:
>
> > ERROR:core:unescape_user: invalid hex digit <37>
> > ERROR:path:path_rr_callback: failed to unescape
> > received=sip:35.x.x.x:60026%%3btransport%%3dtls
>
> ...Which scenario of the two below would you
> say we are in, and with what degree of certainty?
>
> A. OpenSIPS generates those erroneous '%%' strings right from the
> beginning, when building the Path headers and passing through the
> SUBSCRIBE or REGISTER requests.
> B. The Path headers are okay when generated by OpenSIPS (containing
> just '%3b' and '%3d'), but the issue is on the backend side, which
> originates ping messages with doubled '%%' strings in Route headers,
> which OpenSIPS is obviously having a hard time parsing/routing?
>
>
As far as I can see, it's option A:
At the start of the route{} block in opensips.cfg, I write the SIP message
OpenSIPS is receiving with...
*xlog("$mb"); *
...here's what I see (entries reformatted to convert #015#012 to a
newline). When the NATed TLS UAC first registers, OpenSIPS receives...
REGISTER sip:me.our-domain.com;transport=tls SIP/2.0
Via: SIP/2.0/TLS
192.x.x.9:49462;rport;branch=z9hG4bKPjb2bbf33dd6ad483bb7a6f169b4e01930;alias
Max-Forwards: 70
From: "1001" ;tag=41310a1aa6504e6d8d03fa8f9d74cd52
To: "1001"
Call-ID: cadaee22e6484dcab11ffc8f94b17aa2
CSeq: 43881 REGISTER
User-Agent: MicroSIP/3.20.6
Supported: outbound, path
Contact: "1001" ;+sip.ice;reg-id=1;+sip.instance=""
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length: 0
...we're using mid_registrar with AOR throttling. Because of the lumps
system, to get the information to save in the mid_registrar we use...
fix_nated_register();
fix_nated_contact();
add_path_received("$tU");
...and then t_relay the message back to the OpenSIPS server (192.x.x.123)
to continue and store the registration using mid_registrar_save(). When it
arrives - this is what OpenSIPS is receiving...
REGISTER sip:me.our-domain.com;transport=tls SIP/2.0
Via: SIP/2.0/TCP 192.x.x.123:5060;branch=z9hG4bK3c27.80ba0c03.0;i=1b075e53
Via: SIP/2.0/TLS
192.x.x.9:49462;received=31.x.x.x;rport=49462;branch=z9hG4bKPjb2bbf33dd6ad483bb7a6f169b4e01930;alias
Max-Forwards: 70
From: "1001" ;tag=41310a1aa6504e6d8d03fa8f9d74cd52
To: "1001"
Call-ID: cadaee22e6484dcab11ffc8f94b17aa2
CSeq: 43881 REGISTER
User-Agent: MicroSIP/3.20.6
Supported: outbound, path
Contact: "1001" ;+sip.ice;reg-id=1;+sip.instance=""
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length: 0
Path:
Path:
...so it seems to be the add_path_received() that's the source of the
problem
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OPUS transcoding query
Thanks very much for your reply. There's a lot to consider but it's really helpful On Wed, 21 Jul 2021, 18:27 Gregory Massel, wrote: > A few factors to consider: > > *1. Quality* > > 1.1. If you transcode to PCMU using RTPengine, you will lose the wideband > audio quality benefits of Opus. By contrast, if Asterisk accepts the calls > using Opus, it will transcode internally to sln16 for purposes of media > processing (playing IVRs, music-on-hold, etc.), allowing for superior audio > quality on that media (IVR, MOH, etc.). If Asterisk is going to be > generating media, it would be preferable to let it receive the call in Opus. > > 1.2. If Asterisk is merely bridging endpoints and not generating any media > nor recording calls and its only media-processing role in your scenario is > transcoding, then the call quality will, in any case, never be better than > PCMU quality and there would be no difference in call quality whether > transcoding within Asterisk or RTPengine. > > 1.3. If the other side supports some other wideband codec that Asterisk > doesn't support, RTPengine may be better. E.g For a GSM Mobile network, > they may support AMR-WB and RTPengine should be able to transcode Opus to > AMR-WB. This would give a quality advantage to RTPengine over Asterisk > (although Opus to AMR-WB may be computationally expensive). > > 1.4. If you're recording some (or all) of the calls within Asterisk, > consider the format in which you're recording them and the call quality. > Again, if Asterisk receives the call as Opus and records in a > high-definition format (e.g. Sln16 or MP3), then the recordings will be > superior versus if it receives the calls already transcoded to PCMU. > > *2. Processing* > > 2.1. RTPengine is much more efficient at RTP proxying *when using > in-kernel packet forwarding* versus non-kernel packet forwarding. The > difference in terms of CPU usage and system load is significant. > > 2.1. Per https://github.com/sipwise/rtpengine "Transcoding happens in > userspace only, so in-kernel packet forwarding will *not be available for > transcoded codecs*." > > 2.2. I've not seen any measured benchmarks of Asterisk versus RTPengine's > *non-kernel* packet forwarding, however, in my experience, both result in > similar load on the same hardware. RTPengine does, however, materially > outperform Asterisk in scenarios where in-kernel packet forwarding is > possible (i.e. no transcoding required). > > 2.3. My scenarios never involved transcoding Opus. It's possible that > either Asterisk or RTPengine may have a superior approach towards the > transcoding, however, this is extremely unlikely (and even more unlikely to > have a material impact on performance) as the codecs are the same and > should follow the same algorithms. > > *3. Scale* > > 3.1. Even on generous hardware, Asterisk is unlikely to comfortably > transcode more than 1,000 simultaneous Opus-to-PCMU calls. > > 3.2. I'm not sure about RTPengine, however, it's probably safe to say that > the transcoding itself is sufficiently computationally expensive that > you'll encounter a similar limit. > > 3.3. Depending on your configuration, you may find it easier to have > OpenSIPS direct calls through a pool of multiple RTPengine servers. By > comparison, if you're directing calls through to a pool of Asterisk > servers, you *MAY* have additional complexity (e.g. consider conference > calls where the Asterisk server needs all the calls on one server in order > to conference them). > > 3.4. If you're pushing the limits of Asterisk (e.g. using it to > conferencing hundreds or thousands of participants), then it would almost > certainly be wiser to have RTPengine first transcode to PCMU, as a single > Asterisk box won't be able to perform that volume of transcoding and > conferencing. > > *4. Other* > > 4.1. WebRTC supports PCMU. Consider establishing the call PCMU-to-PCMU > from the outset and avoiding transcoding altogether! > > 4.2. WebRTC generally requires that the media be encrypted with DTLS. If > RTPengine is already performing the task of decrypting DTLS-encoded media, > then you may get a performance advantage by transcoding to PCMU at the same > time, particularly if Asterisk can then cut itself out of the media path > and direct the media from the RTPengine to the other bridged endpoint. In > essence, you're then only manipulating the media ONCE, not TWICE, cutting > down on latency, network traffic, etc. If RTPengine first decrypts and then > passes decrypted media to Asterisk and Asterisk then transcodes, this will > likely be less efficient. > > > So obviously it's not as simple as saying one will always outperform the > other, however, there are
Re: [OpenSIPS-Users] add_path_received and TLS - received address problem
Hi Liviu - thanks for getting back to me.
I'm seeing errors for pinger OPTIONS and Asterisk NOTIFY SIP messages going
out to the NATed TLS UAC...
ERROR:core:unescape_user: invalid hex digit <37>
ERROR:path:path_rr_callback: failed to unescape
received=sip:35.x.x.x:60026%%3btransport%%3dtls
ERROR:core:tcp_connect_blocking_timeout: connect timed out, 99204 us
elapsed out of 10 us
ERROR:proto_tls:tls_sync_connect: tcp_blocking_connect failed
ERROR:proto_tls:proto_tls_send: connect failed
ERROR:tm:msg_send: send() to 35.210.77.199:50052 for proto tls/3 failed
ERROR:tm:t_forward_nonack: sending request failed
On Wed, 21 Jul 2021, 10:56 Liviu Chircu, wrote:
> On 20.07.2021 13:26, Mark Allen wrote:
> > On registration add_path_received() works but the received address is
> > not formatted correctly. I am seeing '%%3b' instead of a semicolon,
> > and '%%3d' instead of an equals sign.
> >
> Hi Mark,
>
> How exactly is this peculiar formatting breaking your logic? Because
> the '%'-escaping logic is by design, with a similar un-escaping logic
> being included in the code that parses those Path headers, so the UDP
> <-> TLS translation using Path headers should work just fine.
>
> See this commit for full details on how the escaping logic solves
> multiple problems with the original approach: [1].
>
> PS: with 3 years having passed since I wrote that commit, nowadays I
> would look at a different way of solving the same problem, as I vaguely
> recall that URI param values can be enclosed in double-quotes ("),
> allowing us to put anything in there, without affecting the semantics of
> the original URI. Just an idea that we could research/confirm/infirm
> should we find any non-fixable issues with the current escaping approach.
>
> [1]: https://github.com/OpenSIPS/opensips/commit/b3bf15646affe981d4b26
>
> Best Regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
> OpenSIPS Summit 2021 Distributed | www.opensips.org/events
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] add_path_received and TLS - received address problem
Hmm - not sure what went wrong with my post. It seemed to add some unwanted formatting. Here's the failing example again... Path: Path: On Tue, 20 Jul 2021 at 10:49, Mark Allen wrote: > I'm seeing a strange problem when using add_path_received() for > registration of NATed UAC using TLS with OpenSIPS 3.1 > > On registration add_path_received() works but the received address is not > formatted correctly. I am seeing '%%3b' instead of a semicolon, and '%%3d' > instead of an equals sign. > > e.g. > > Path: > x.x;transport=tcp;r2=on;lr> > Path: :5061;transport=tls;r2=on;lr;received=sip:31.x.x.x:50247%%3btransport%%3dtls> > > When the same UAC registers using UDP instead of TLS it works fine > > e.g. > > Path: > Path: > > > What am I doing wrong??? > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] add_path_received and TLS - received address problem
I'm seeing a strange problem when using add_path_received() for registration of NATed UAC using TLS with OpenSIPS 3.1 On registration add_path_received() works but the received address is not formatted correctly. I am seeing '%%3b' instead of a semicolon, and '%%3d' instead of an equals sign. e.g. Path: x.x;transport=tcp;r2=on;lr> Path: When the same UAC registers using UDP instead of TLS it works fine e.g. Path: Path: What am I doing wrong??? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] OPUS transcoding query
I wonder if anyone can offer any insights... We are using OpenSIPS 3.1 as a mid-registrar and in front of an Asterisk box. We include incoming WebRTC traffic using the OPUS codec. Which do you think would be the better option: 1 - Pass OPUS directly through to Asterisk 2 - Use RTPEngine to transcode OPUS to PCMU before passing it on to Asterisk to reduce the workload on the Asterisk box If option 2 would be the more efficient option, are there any settings we should consider to allow transcoding to be as efficient as possible? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Am I seeing SIP message fragmentation?
So, we now have a fix for this. Here's a summary of the error we were seeing and the solution in case it's useful to anybody else. The problem we were seeing was a SIP message failing to parse and raising errors. This was particularly problematic for us when it was a REGISTER failing. Looking at the error message we could see that there seemed to be a fragment of another message tagged onto the front of the SIP message, which was the source of the parsing error: ERROR:core:parse_msg: message=#015#012User-Agent: MWWRTC 3.4.21042#015#012Accept: application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 OK#015#012Via: SIP/2.0/TCP 192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4#015#012Via: SIP/2.0/WSS 98kaag0xmybq.invalid;received=4.56.78.110;branch=z9hG4bKU6O3fJQGeLvuACMTXTArJgJW73rOD5dU;rport=52570#015#012From: ;tag=Lyk010G476K7xcKrE84M#015#012To: < sip:1...@abc.def.com>;tag=af78-6213d386c3edcd02707b0c0aa8423d3a#015#012Call-ID: 666b5e7c-cef3-f306-4b79-60d3160dc5d0#015#012CSeq: 28825 REGISTER#015#012Contact: ;expires=60;received="sip:4.56.78.110:52570"#015#012Server: OpenSIPS (3.1.1 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012> On investigation, we found that our webphone had a bug when responding to OPTIONS messages. It included a blank line partway through the 200 OK message - e.g. SIP/2.0 200 OK Via: SIP/2.0/WSS 192.168.1.23:2096;branch=z9hG4bKa9ef.4dec8f71.0;i=6a378c51 Via: SIP/2.0/TCP 192.168.1.23:5060 ;rport=37493;received=192.168.1.23;branch=z9hG4bK8da5c944 From: sip:pinger@192.168.1.23;tag=8b54f607 To: sip:4.56.78.110:52570 Call-ID: 0003168-8da5c944-5d2@192.168.1.23 CSeq: 1 OPTIONS Max-Forwards: 68 Content-Length: 0 Contact: User-Agent: MWWRTC 3.4.21042 Accept: application/sdp,application/dtmf-relay,text/plain ...this meant that the lines from "Contact" onwards were being seen as the start of a new message, and hence tagged onto whatever SIP message arrived next. The solution was raising a bug to get the webphone supplier to fix the problem. Now we have a new version, the problem no longer occurs :) ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Am I seeing SIP message fragmentation?
Hi Răzvan - thanks for the reply Looking into it, our working theory is that the problem is as follows... UAC (WebRTC dialer) is sending a corrupted SIP 200OK to an OPTIONS message over WebSocket. Message has a blank line in it and the content length is 0. OpenSIPS sees the blank line as the end of the SIP message but UAC is sending more (garbage text) after the blank line. I assume that what comes after the blank line is buffered and seen as the start of a new SIP message? When the next SIP message comes in it gets appended to the corrupt message segment and when OpenSIPS tries to parse it, it sees it as nonsense (which it is). Just waiting on testing a new version of UAC which will hopefully confirm that this is the problem. cheers, M On Wed, 2 Jun 2021 at 08:57, Răzvan Crainea wrote: > Hi, Mark! > > Most likely the problem appear prior to that Contact header you're > seeing - somehow OpenSIPS thinks the packet starts with the Contact > token, whereas, most likely, the Contact is part of a previous message, > not shown in this report. > There's no such thing as SIP message fragmentation - it's either UDP or > TCP fragmentation. However, fragmentation only appears when the package > is higher than MTU. I don't think this is the case here - What I think > there is, is a broken UA which is not setting a correct Content-Length, > or is sending garbage after sending the packet. But the only way to > figure out is to make a pcap for the entire connection and see where it > starts breaking. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 5/26/21 2:15 PM, Mark Allen wrote: > > I'm seeing a weird, intermittent error. The most common occurrence is > > with a 200OK returned by Mid-Registrar on a re-REGISTER using > > registration throttling, but we see it elsewhere. It appears that the > > 200OK message is getting garbled. > > > > We have a bit of a weird setup to overcome issues we were having with > > Mid-Registrar and WebSocket addressing. Mid-Registrar is looping back > > 200OK to OpenSIPS before it then gets sent down the WebSocket. 90+% of > > the time it's absolutely fine, but occasionally the 200OK seems to be > > corrupted. > > > > Here's an example. What we are seeing in this message is... > > > > Contact: http://sip:1...@abc.def.com:5060>> > > User-Agent: MWWRTC 3.4.21042#015#012Accept: > > application/sdp,application/dtmf-relay,text/plain > > > > ...preceding... > > > > SIP/2.0 200 OK > > Via: SIP/2.0/TCP > > 192.168.1.23:5060 > ;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4 > > ...etc... > > > > ...so OpenSIPS is failing to parse the message. > > > > What I'd like to know is, is this a sign of SIP message fragmentation? > > > > > > > > Log entries (IP addresses, domains, and extensions changed to protect > > the innocent!): > > > > ERROR:core:parse_method: invalid character : > > DBG:core:tcp_read_req: tcp_read_req end > > INFO:core:parse_first_line: failed to parse the method > > INFO:core:parse_first_line: bad message > > DBG:core:parse_msg: invalid message > > ERROR:core:parse_msg: message= > <http://sip:1...@abc.def.com:5060>>#015#012User-Agent: MWWRTC > > 3.4.21042#015#012Accept: > > application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 > > OK#015#012Via: SIP/2.0/TCP > > 192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4#015#012Via: > > > SIP/2.0/WSS > > > 98kaag0xmybq.invalid;received=4.56.78.110;branch=z9hG4bKU6O3fJQGeLvuACMTXTArJgJW73rOD5dU;rport=52570#015#012From: > > > > <mailto:sip%3a1...@abc.def.com>>;tag=Lyk010G476K7xcKrE84M#015#012To: > > > <mailto:sip%3a1...@abc.def.com>>;tag=af78-6213d386c3edcd02707b0c0aa8423d3a#015#012Call-ID: > > > 666b5e7c-cef3-f306-4b79-60d3160dc5d0#015#012CSeq: 28825 > > REGISTER#015#012Contact: > > ;expires=60;received="sip: > 4.56.78.110:52570 > > <http://4.56.78.110:52570>"#015#012Server: OpenSIPS (3.1.1 > > (x86_64/linux))#015#012Content-Length: 0#015#012#015#012> > > ERROR:core:receive_msg: Unable to parse msg received from > > [192.168.1.23:5060 <http://192.168.1.23:5060>] > > ERROR:core:tcp_handle_req: receive_msg failed > > DBG:core:tcp_read_req: tcp_read_req end > > > > ___ > > 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] error_route not triggered for parsing error
Ticket raised - https://github.com/OpenSIPS/opensips/issues/2533
On Fri, 28 May 2021 at 07:32, Mark Allen wrote:
> Thanks Bogdan - will do
>
> On Fri, 28 May 2021 at 06:54, Bogdan-Andrei Iancu
> wrote:
>
>> Hi Mark,
>>
>> Consider opening a ticket on github.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>> https://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2021 online
>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/
>>
>> On 5/27/21 2:57 PM, Mark Allen wrote:
>>
>> This seems to link to a past thread where error_route is not triggering
>> if the first line is malformed. Unfortunately, there is no resolution to
>> this past thread - link here:
>> https://opensips.org/pipermail/users/2019-February/040605.html
>>
>> On Thu, 27 May 2021 at 11:56, Mark Allen wrote:
>>
>>>
>>> In my script, I have an error_route...
>>>
>>> error_route {
>>>xlog("--- error route class=$(err.class) level=$(err.level)
>>> info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason)
>>> ---\n");
>>>xlog("--- error from [$si:$sp]\n+\n$mb\n\n");
>>>sl_send_reply($err.rcode, "$err.rreason");
>>>exit;
>>> }
>>>
>>> ...but when I get a message parsing error, the error_route seems to
>>> ignore it. What am I doing wrong?
>>>
>>> ERROR:core:parse_method: invalid character :
>>> INFO:core:parse_first_line: failed to parse the method
>>> INFO:core:parse_first_line: bad message
>>> ERROR:core:parse_msg: message=>> #015#012User-Agent:
>>> MWWRTC 3.4.21042#015#012Accept:
>>> application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200
>>> OK#015#012Via: SIP/2.0/TCP
>>> 192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From:
>>> ;tag=33e693c3#015#012To:
>>> ;tag=1550918023#015#012Call-ID:
>>> fc585e54-72a5d21-ab2@192.168.1.23#015#012CSeq
>>> <http://fc585e54-72a5d21-ab2@192.168.1.23#015%23012CSeq>: 1
>>> OPTIONS#015#012User-Agent: Yealink SIP-T54W#015#012Content-Length:
>>> 0#015#012#015#012>
>>> ERROR:core:receive_msg: Unable to parse msg received from [
>>> 192.168.1.23:5060]
>>> ERROR:core:tcp_handle_req: receive_msg failed
>>>
>>>
>>> We are running OpenSIPS 3.1
>>>
>>>
>>> (this is a follow-up to my other query
>>> http://lists.opensips.org/pipermail/users/2021-May/044776.html)
>>>
>>>
>> ___
>> 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
Re: [OpenSIPS-Users] error_route not triggered for parsing error
Thanks Bogdan - will do
On Fri, 28 May 2021 at 06:54, Bogdan-Andrei Iancu
wrote:
> Hi Mark,
>
> Consider opening a ticket on github.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
> https://www.opensips-solutions.com
> OpenSIPS Bootcamp 2021 online
> https://opensips.org/training/OpenSIPS_eBootcamp_2021/
>
> On 5/27/21 2:57 PM, Mark Allen wrote:
>
> This seems to link to a past thread where error_route is not triggering if
> the first line is malformed. Unfortunately, there is no resolution to this
> past thread - link here:
> https://opensips.org/pipermail/users/2019-February/040605.html
>
> On Thu, 27 May 2021 at 11:56, Mark Allen wrote:
>
>>
>> In my script, I have an error_route...
>>
>> error_route {
>>xlog("--- error route class=$(err.class) level=$(err.level)
>> info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason)
>> ---\n");
>>xlog("--- error from [$si:$sp]\n+\n$mb\n\n");
>>sl_send_reply($err.rcode, "$err.rreason");
>>exit;
>> }
>>
>> ...but when I get a message parsing error, the error_route seems to
>> ignore it. What am I doing wrong?
>>
>> ERROR:core:parse_method: invalid character :
>> INFO:core:parse_first_line: failed to parse the method
>> INFO:core:parse_first_line: bad message
>> ERROR:core:parse_msg: message=> #015#012User-Agent:
>> MWWRTC 3.4.21042#015#012Accept:
>> application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200
>> OK#015#012Via: SIP/2.0/TCP
>> 192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From:
>> ;tag=33e693c3#015#012To:
>> ;tag=1550918023#015#012Call-ID:
>> fc585e54-72a5d21-ab2@192.168.1.23#015#012CSeq
>> <http://fc585e54-72a5d21-ab2@192.168.1.23#015%23012CSeq>: 1
>> OPTIONS#015#012User-Agent: Yealink SIP-T54W#015#012Content-Length:
>> 0#015#012#015#012>
>> ERROR:core:receive_msg: Unable to parse msg received from [
>> 192.168.1.23:5060]
>> ERROR:core:tcp_handle_req: receive_msg failed
>>
>>
>> We are running OpenSIPS 3.1
>>
>>
>> (this is a follow-up to my other query
>> http://lists.opensips.org/pipermail/users/2021-May/044776.html)
>>
>>
> ___
> 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
Re: [OpenSIPS-Users] error_route not triggered for parsing error
This seems to link to a past thread where error_route is not triggering if
the first line is malformed. Unfortunately, there is no resolution to this
past thread - link here:
https://opensips.org/pipermail/users/2019-February/040605.html
On Thu, 27 May 2021 at 11:56, Mark Allen wrote:
>
> In my script, I have an error_route...
>
> error_route {
>xlog("--- error route class=$(err.class) level=$(err.level)
> info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason)
> ---\n");
>xlog("--- error from [$si:$sp]\n+\n$mb\n\n");
>sl_send_reply($err.rcode, "$err.rreason");
>exit;
> }
>
> ...but when I get a message parsing error, the error_route seems to ignore
> it. What am I doing wrong?
>
> ERROR:core:parse_method: invalid character :
> INFO:core:parse_first_line: failed to parse the method
> INFO:core:parse_first_line: bad message
> ERROR:core:parse_msg: message= #015#012User-Agent:
> MWWRTC 3.4.21042#015#012Accept:
> application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200
> OK#015#012Via: SIP/2.0/TCP
> 192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From:
> ;tag=33e693c3#015#012To:
> ;tag=1550918023#015#012Call-ID:
> fc585e54-72a5d21-ab2@192.168.1.23#015#012CSeq
> <http://fc585e54-72a5d21-ab2@192.168.1.23#015%23012CSeq>: 1
> OPTIONS#015#012User-Agent: Yealink SIP-T54W#015#012Content-Length:
> 0#015#012#015#012>
> ERROR:core:receive_msg: Unable to parse msg received from [
> 192.168.1.23:5060]
> ERROR:core:tcp_handle_req: receive_msg failed
>
>
> We are running OpenSIPS 3.1
>
>
> (this is a follow-up to my other query
> http://lists.opensips.org/pipermail/users/2021-May/044776.html)
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] error_route not triggered for parsing error
In my script, I have an error_route...
error_route {
xlog("--- error route class=$(err.class) level=$(err.level)
info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n");
xlog("--- error from [$si:$sp]\n+\n$mb\n\n");
sl_send_reply($err.rcode, "$err.rreason");
exit;
}
...but when I get a message parsing error, the error_route seems to ignore
it. What am I doing wrong?
ERROR:core:parse_method: invalid character :
INFO:core:parse_first_line: failed to parse the method
INFO:core:parse_first_line: bad message
ERROR:core:parse_msg: message=#015#012User-Agent:
MWWRTC 3.4.21042#015#012Accept:
application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200
OK#015#012Via: SIP/2.0/TCP
192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From:
;tag=33e693c3#015#012To:
;tag=1550918023#015#012Call-ID:
fc585e54-72a5d21-ab2@192.168.1.23#015#012CSeq: 1 OPTIONS#015#012User-Agent:
Yealink SIP-T54W#015#012Content-Length: 0#015#012#015#012>
ERROR:core:receive_msg: Unable to parse msg received from [192.168.1.23:5060
]
ERROR:core:tcp_handle_req: receive_msg failed
We are running OpenSIPS 3.1
(this is a follow-up to my other query
http://lists.opensips.org/pipermail/users/2021-May/044776.html)
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Am I seeing SIP message fragmentation?
I'm seeing a weird, intermittent error. The most common occurrence is with a 200OK returned by Mid-Registrar on a re-REGISTER using registration throttling, but we see it elsewhere. It appears that the 200OK message is getting garbled. We have a bit of a weird setup to overcome issues we were having with Mid-Registrar and WebSocket addressing. Mid-Registrar is looping back 200OK to OpenSIPS before it then gets sent down the WebSocket. 90+% of the time it's absolutely fine, but occasionally the 200OK seems to be corrupted. Here's an example. What we are seeing in this message is... Contact: User-Agent: MWWRTC 3.4.21042#015#012Accept: application/sdp,application/dtmf-relay,text/plain ...preceding... SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.1.23:5060 ;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4 ...etc... ...so OpenSIPS is failing to parse the message. What I'd like to know is, is this a sign of SIP message fragmentation? Log entries (IP addresses, domains, and extensions changed to protect the innocent!): ERROR:core:parse_method: invalid character : DBG:core:tcp_read_req: tcp_read_req end INFO:core:parse_first_line: failed to parse the method INFO:core:parse_first_line: bad message DBG:core:parse_msg: invalid message ERROR:core:parse_msg: message=#015#012User-Agent: MWWRTC 3.4.21042#015#012Accept: application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 OK#015#012Via: SIP/2.0/TCP 192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4#015#012Via: SIP/2.0/WSS 98kaag0xmybq.invalid;received=4.56.78.110;branch=z9hG4bKU6O3fJQGeLvuACMTXTArJgJW73rOD5dU;rport=52570#015#012From: ;tag=Lyk010G476K7xcKrE84M#015#012To: < sip:1...@abc.def.com>;tag=af78-6213d386c3edcd02707b0c0aa8423d3a#015#012Call-ID: 666b5e7c-cef3-f306-4b79-60d3160dc5d0#015#012CSeq: 28825 REGISTER#015#012Contact: ;expires=60;received="sip:4.56.78.110:52570"#015#012Server: OpenSIPS (3.1.1 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012> ERROR:core:receive_msg: Unable to parse msg received from [192.168.1.23:5060 ] ERROR:core:tcp_handle_req: receive_msg failed DBG:core:tcp_read_req: tcp_read_req end ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DID via OpenSIPS causing Asterisk to ask for authorization
Hi Stas, thanks for that. I'll try it out cheers, Mark On Mon, 29 Mar 2021 at 15:51, Stas Kobzar wrote: > Hello Mark, > > IMO, it is Asterisk side. Of course it depends on your setup but probably > you need Asterisk sip peer to opensips. Do not know for pjsip, for older > sip_chan it would be something like: > > [opensips] > type=friend > deny=0.0.0.0/0.0.0.0 > permit=OPENSIPS_IP/255.255.255.255 > host=OPENSIPS_IP > > You definitely can set this up with FreePBX web ui. > > > > On Mon, Mar 29, 2021 at 10:24 AM Mark Allen wrote: > >> We have a DID. If an incoming INVITE goes via OpenSIPS, Asterisk returns >> '401 Unauthorized' requesting authorization credentials. If we map the DID >> direct to Asterisk it doesn't ask for authorization. Our setup is... >> >> DID ---> OpenSIPS 3.1 Mid_registrar ---> Asterisk (FreePBX) >> >> Is there something I need to configure on OpenSIPS or is it purely an >> Asterisk issue? >> ___ >> 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
[OpenSIPS-Users] DID via OpenSIPS causing Asterisk to ask for authorization
We have a DID. If an incoming INVITE goes via OpenSIPS, Asterisk returns '401 Unauthorized' requesting authorization credentials. If we map the DID direct to Asterisk it doesn't ask for authorization. Our setup is... DID ---> OpenSIPS 3.1 Mid_registrar ---> Asterisk (FreePBX) Is there something I need to configure on OpenSIPS or is it purely an Asterisk issue? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 - Mid_Registrar AOR throttling & FreePBX/Asterisk Expiry problem
RFC 3261 says...
'The "expires" parameter of a Contact header field value indicates how long
the URI is valid. The value of the parameter is a number indicating
seconds. If this parameter is not provided, the value of the Expires
header field determines how long the URI is valid.'
...I know that Asterisk is returning a value in both fields, but the
mid_registrar seems to be only updating the *Contact* header's expiry value
in some cases. This means that the simple solution is to just remove the
*Expires* header value to avoid any conflict. The value in the *Contact*
header is now the single version of the truth for all apps to use as per
the RFC. I just use a reply route in opensips.cfg to remove the *Expires*
header from the 200OK when it arrives from Asterisk...
onreply_route[fix_expiry] {
if ($rs == "200" && $rm == "REGISTER") {
remove_hf("Expires");
}
}
On Fri, 19 Mar 2021 at 19:48, Ricardo Martinez
wrote:
> Do you have some tip to solve this issue ??.
> Did you use the .conf file or did you have to modify the sources ??
>
> Thanks
> Ricardo
>
> El vie., 19 de marzo de 2021 4:04 p. m., Mark Allen
> escribió:
>
>> Yes it was still happening the last time I checked. I got the script to
>> re-write the value to get around the problem
>>
>> On Fri, 19 Mar 2021, 18:15 Ricardo Martinez,
>> wrote:
>>
>>> Hi Mark.
>>>
>>> Do you still have the same problem?.
>>>
>>> Did you manage to solve it?.
>>>
>>>
>>>
>>> Ricardo.-
>>>
>>>
>>>
>>> *De:* Users *En nombre de *Mark Allen
>>> *Enviado el:* miércoles, 3 de febrero de 2021 8:42
>>> *Para:* OpenSIPS users mailling list
>>> *Asunto:* [OpenSIPS-Users] OpenSIPS 3.1 - Mid_Registrar AOR throttling
>>> & FreePBX/Asterisk Expiry problem
>>>
>>>
>>>
>>> I'm seeing strange behaviour using mid_registrar with AOR throttling...
>>>
>>>
>>>
>>> On initial registration, I do a mid_registrar_save():
>>>
>>>
>>>
>>> mid_registrar_save("location","mp0v","sip:$tU@midreg",,"vipx");
>>>
>>>
>>>
>>> Return value from save is "1" (success) and then I successfully forward
>>> the REGISTER to the FreePBX/Asterisk main registrar (so far so good!).
>>>
>>>
>>>
>>> Asterisk returns a "200 OK" to OpenSIPS which has the registration
>>> expiry value set in both the "Expires" header and in the "Contact" header...
>>>
>>>
>>>
>>> SIP/2.0 200 OK
>>> Expires: 600
>>> Contact: ;expires=600
>>>
>>> Mid_Registrar forwards this on to the UAC after modifying the expiry
>>> value for AOR throttling, but only the "expires" setting in the "Contact"
>>> header gets modified...
>>>
>>>
>>>
>>> SIP/2.0 200 OK
>>> Expires: 600
>>> Contact: ;expires=300
>>>
>>>
>>>
>>> This leads to the unpredictable behaviour I'm seeing. MicoSIP seems to
>>> prefer to use the "Contact" header expiry value, and so works fine,
>>> however, Blink and a test MizuTech softphone seem to prefer the "Expires"
>>> header value, and so are not using the AOR throttling value.
>>>
>>>
>>>
>>> In the above example, Mid_Registrar is expecting the UAC to REGISTER
>>> again before 300 seconds have elapsed to maintain the registration, but
>>> Blink or the MizuTech softphone believe they should renew their
>>> registration before 600 seconds. When Mid_Registrar does not get the
>>> expected registration at around 300 seconds it assumes the connection is
>>> lost and de-registers on Asterisk. Finally, the UAC renews the registration
>>> at around 600 seconds meaning the UAC is effectively cycling between being
>>> available/unavailable.
>>>
>>>
>>>
>>> I have written a workaround in our config file to remove the invalid
>>> value before the "200 OK" gets forwarded to the UAC, but should
>>> mid_registrar be changing the expiry value in both places?
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 - Mid_Registrar AOR throttling & FreePBX/Asterisk Expiry problem
Yes it was still happening the last time I checked. I got the script to
re-write the value to get around the problem
On Fri, 19 Mar 2021, 18:15 Ricardo Martinez, wrote:
> Hi Mark.
>
> Do you still have the same problem?.
>
> Did you manage to solve it?.
>
>
>
> Ricardo.-
>
>
>
> *De:* Users *En nombre de *Mark Allen
> *Enviado el:* miércoles, 3 de febrero de 2021 8:42
> *Para:* OpenSIPS users mailling list
> *Asunto:* [OpenSIPS-Users] OpenSIPS 3.1 - Mid_Registrar AOR throttling &
> FreePBX/Asterisk Expiry problem
>
>
>
> I'm seeing strange behaviour using mid_registrar with AOR throttling...
>
>
>
> On initial registration, I do a mid_registrar_save():
>
>
>
> mid_registrar_save("location","mp0v","sip:$tU@midreg",,"vipx");
>
>
>
> Return value from save is "1" (success) and then I successfully forward
> the REGISTER to the FreePBX/Asterisk main registrar (so far so good!).
>
>
>
> Asterisk returns a "200 OK" to OpenSIPS which has the registration expiry
> value set in both the "Expires" header and in the "Contact" header...
>
>
>
> SIP/2.0 200 OK
> Expires: 600
> Contact: ;expires=600
>
> Mid_Registrar forwards this on to the UAC after modifying the expiry value
> for AOR throttling, but only the "expires" setting in the "Contact" header
> gets modified...
>
>
>
> SIP/2.0 200 OK
> Expires: 600
> Contact: ;expires=300
>
>
>
> This leads to the unpredictable behaviour I'm seeing. MicoSIP seems to
> prefer to use the "Contact" header expiry value, and so works fine,
> however, Blink and a test MizuTech softphone seem to prefer the "Expires"
> header value, and so are not using the AOR throttling value.
>
>
>
> In the above example, Mid_Registrar is expecting the UAC to REGISTER again
> before 300 seconds have elapsed to maintain the registration, but Blink or
> the MizuTech softphone believe they should renew their registration before
> 600 seconds. When Mid_Registrar does not get the expected registration at
> around 300 seconds it assumes the connection is lost and de-registers on
> Asterisk. Finally, the UAC renews the registration at around 600 seconds
> meaning the UAC is effectively cycling between being available/unavailable.
>
>
>
> I have written a workaround in our config file to remove the invalid value
> before the "200 OK" gets forwarded to the UAC, but should mid_registrar be
> changing the expiry value in both places?
>
>
>
>
> ___
> 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] Handling mobile switch from wifi to data
>
> Anything specific concerning/confusing you at this stage?
>
Hi Callum. Yes, there are a few things...
1 - Conceptually, I'm not quite clear on how the initial PN link works. My
understanding from the blog and video is that OpenSIPS receives an initial
register that causes it to send a request to the PN Provider, and somehow
the PN Provider then knows about the mobile and can communicate with it
directly? Is that correct? How is this coded on a REGISTER - or am I
missing something here?
2 - From the video, I'm unclear whether this works with off-the-shelf UAC
apps on mobiles such as Zoiper, PortSIP, etc or whether we'd have to write
our own UA client. There was also a discussion at the end about whether
this would actually work with Apple devices which I didn't feel was
actually answered.
3 - From the blog, where it gets to the coding I don't understand what it
means where it says...
route [PN_SEND]
{
# send a PN using, for example, exec or rest_client
}
...an example would help here I think.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Handling mobile switch from wifi to data
Thanks Johan - I can see how that would be the case. I've read through the blog posts about setting up PN which are very helpful, though I've still got some questions. Hopefully, the video from the 2020 Summit will fill in the gaps. On Wed, 17 Mar 2021 at 09:35, Johan De Clercq wrote: > sending push before you send the invite solves many many problems. > > Op wo 17 mrt. 2021 om 08:54 schreef Mark Allen : > >> OK - thanks for that. I'll give it a try >> >> On Tue, 16 Mar 2021 at 12:22, Johan De Clercq wrote: >> >>> Implement push. >>> >>> Op di 16 mrt. 2021 om 13:15 schreef Mark Allen : >>> >>>> We are using OpenSIPS 3.1 as a mid_registrar in AOR Throttling mode. >>>> When a mobile moves from data to wifi or vice versa, my understanding is >>>> that the registration on OpenSIPS becomes stale (because the phone has a >>>> new IP address). Does this mean that the mobile phone is not registered >>>> until registration expiry is reached on the mobile app and a new REGISTER >>>> is sent? If so, is there anything that can be done to mitigate 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 >>> >> ___ >> 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] Handling mobile switch from wifi to data
OK - thanks for that. I'll give it a try On Tue, 16 Mar 2021 at 12:22, Johan De Clercq wrote: > Implement push. > > Op di 16 mrt. 2021 om 13:15 schreef Mark Allen : > >> We are using OpenSIPS 3.1 as a mid_registrar in AOR Throttling mode. When >> a mobile moves from data to wifi or vice versa, my understanding is that >> the registration on OpenSIPS becomes stale (because the phone has a new IP >> address). Does this mean that the mobile phone is not registered until >> registration expiry is reached on the mobile app and a new REGISTER is >> sent? If so, is there anything that can be done to mitigate 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 > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Handling mobile switch from wifi to data
We are using OpenSIPS 3.1 as a mid_registrar in AOR Throttling mode. When a mobile moves from data to wifi or vice versa, my understanding is that the registration on OpenSIPS becomes stale (because the phone has a new IP address). Does this mean that the mobile phone is not registered until registration expiry is reached on the mobile app and a new REGISTER is sent? If so, is there anything that can be done to mitigate this? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Changing the expire parameter in the Contact field
You can also use the "subst" function from the textops module to make
changes to the Contact HF using a regexp
On Fri, 12 Mar 2021 at 14:50, Joseph Barrero wrote:
> Ovidiu, thank you for the suggestion. I don't know why I didn't think
> that remove_hf would work, but after I re-read the module documents it
> looks as though it will do what I need. I will give it a try. Thank you
> again!
>
> - Joe
>
> On Fri, Mar 12, 2021 at 7:55 AM Ovidiu Sas wrote:
>
>> You can save the received header into a variable, perform changes to it,
>> remove the old Contact header and append the new one (from the variable).
>>
>> -ovidiu
>>
>> On Fri, Mar 12, 2021 at 8:48 AM Joseph Barrero
>> wrote:
>>
>>> Callum,
>>>
>>> Unfortunately, the contact information and parameters are read-only and
>>> cannot be set using a transformation. I've also tried fix_nated_contact
>>> and it appends an additional expire parameter to the end of the contact
>>> header. As such, I end up with, expires=486;expires=60.
>>>
>>> - Joe
>>>
>>> On Fri, Mar 12, 2021 at 5:41 AM Callum Guy
>>> wrote:
>>>
Hi Joseph,
I haven't fully digested your scenario however you may have some luck
using the nathelper function fix_nated_contact - presuming NAT is not an
issue.
https://opensips.org/html/docs/modules/3.1.x/nathelper.html#func_fix_nated_contact
Otherwise you'll probably be able to achieve this using general
transformations, should be quite straightforward if you only have a single
Contact:
https://www.opensips.org/Documentation/Script-Tran-3-1#toc60
Hope that helps,
Callum
On Fri, 12 Mar 2021 at 03:55, Joseph Barrero
wrote:
> Is there a way to replace the expires parameter in a Contact header
> within a reply route?
>
> The issue I'm trying to solve is the following.
>
> I have two OpenSIPS servers, a primary and a backup. The OpenSIPS
> server is performing mid-registrar duties for Freeswitch. However, when I
> take the primary OpenSIPS server down for maintenance and bring it back
> online, Freeswitch still has the other registration active. When the UA
> tries to register again on the primary OpenSIPS server, the mid-register
> module sends a request over to Freeswitch, and Freeswitch returns two
> contacts; one contact with the modparam("mid_registrar",
> "outgoing_expires", 600) value and the other contact with an expiration of
> whatever value it happens to be on (in this example it is 600 - time
> elapsed) from the registration created by the secondary OpenSIPS server.
>
> The problem is that the expiration parameter in the 200 Ok reply to
> the UA from OpenSIPS on a successful registration has the second
> expiration
> value instead of the shorter expiration value set in
> modparam("mid_registrar", "max_expires", 60).
>
> The result, is that the UA goes from 60-second registrations to
> whatever the second expiration value had at the time (a value between 0
> and
> 599). When the second expiration is higher than 60 seconds, the UA's
> registration is expired on OpenSIPS for up to 599 seconds.
>
> What I'd like to do is simply change the expire parameter in the
> contact header to 60 seconds on the reply route.
>
> Any help will be greatly appreciated.
>
> Thank you,
> Joe Barrero
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
*0333 332 | x-on.co.uk | **
** | Coronavirus
**
| Practice Index Reviews *
THE ITSPA AWARDS 2020 AND Best
ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks
of the Internet Telephony Services Providers' Association, used under
licence.
*From April 1st 2021 our office address will change to: Units 22-24
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 : Avaland House, 110 London Road, Apsley, Hemel
Hempstead, Herts, HP3 9SD. 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.
Re: [OpenSIPS-Users] Handling missing BYEs
Just a follow-up for fix notes. We've got OpenSIPS sitting behind a firewall with a 1:1 port map from an external IP. The Contact HF for the INVITE going out from OpenSIPS to the NATed UAC used the internal IP address for the OpenSIPS box, not the external IP. Set OpenSIPS to fix it and all working fine now. Thanks for the help On Wed, 10 Mar 2021 at 10:39, Mark Allen wrote: > Hi Callum - thanks for that! > > Yes - it's generating the BYE at the Linux end but not sending it to the > remote OpenSIPS IP address but rather to an address on the local LAN - > hence the problem. Thanks for your help. > > Cheers, > > Mark > > > > On Wed, 10 Mar 2021 at 09:26, Callum Guy wrote: > >> Hi Mark, >> >> It sounds like you may be having issues with the proxy not keeping itself >> in path for certain call scenarios. >> >> Are you able to provide a SIP trace and/or opensips config? Also if >> you're running Blink on a Linux system, can you get a SIP trace there to >> see if the BYE is being generated and sent somewhere else? >> >> Callum >> >> On Tue, 9 Mar 2021 at 16:32, Mark Allen wrote: >> >>> I'm seeing some odd behaviour which also leads into a broader question >>> >>> I have a NATed Blink app running on Linux on my home LAN. It connects to >>> an OpenSIPS 3.1 server in on our office LAN which is a mid-registrar for an >>> Asterisk server. I'm running sngrep on the OpenSIPS box to watch the >>> traffic. >>> >>> If I call from the Blink app to another extension it all connects and >>> audio works correctly. If I hangup in Blink, a BYE is sent via OpenSIPS to >>> Asterisk - all good so far. >>> If I call from another extension to the Blink app it all connects and >>> audio works correctly. However, if I hangup in the Blink app, no BYE is >>> sent to OpenSIPS. >>> >>> In most situations, this is merely inconvenient because, with the loss >>> of RTP traffic, Asterisk generates a BYE after about 35 seconds to tidy >>> everything up. However, if I'm doing an attended transfer, the BYE is >>> needed to exit the call so that the transfer completes successfully. At the >>> moment, if I hangup in the Blink app, there's a wait of 35 seconds until >>> Asterisk creates the BYE before the call transfer is completed. >>> >>> While I'm mostly using Blink, I've seen similar failures to send BYEs >>> from other apps. Does OpenSIPS offer anything that could help with this? >>> ___ >>> Users mailing list >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> *0333 332 | x-on.co.uk <https://www.x-on.co.uk> | ** >> <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> >> <https://twitter.com/xonuk> ** | Coronavirus >> <https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>** >> | Practice Index Reviews <https://practiceindex.co.uk/gp/x-on>* >> >> THE ITSPA AWARDS 2020 <http://www.itspa.org.uk/itspa-awards> AND Best >> ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks >> of the Internet Telephony Services Providers' Association, used under >> licence. >> >> *From April 1st 2021 our office address will change to: Units 22-24 >> 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 : Avaland House, 110 London Road, Apsley, Hemel >> Hempstead, Herts, HP3 9SD. 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 >> > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Handling missing BYEs
Hi Callum - thanks for that! Yes - it's generating the BYE at the Linux end but not sending it to the remote OpenSIPS IP address but rather to an address on the local LAN - hence the problem. Thanks for your help. Cheers, Mark On Wed, 10 Mar 2021 at 09:26, Callum Guy wrote: > Hi Mark, > > It sounds like you may be having issues with the proxy not keeping itself > in path for certain call scenarios. > > Are you able to provide a SIP trace and/or opensips config? Also if you're > running Blink on a Linux system, can you get a SIP trace there to see if > the BYE is being generated and sent somewhere else? > > Callum > > On Tue, 9 Mar 2021 at 16:32, Mark Allen wrote: > >> I'm seeing some odd behaviour which also leads into a broader question >> >> I have a NATed Blink app running on Linux on my home LAN. It connects to >> an OpenSIPS 3.1 server in on our office LAN which is a mid-registrar for an >> Asterisk server. I'm running sngrep on the OpenSIPS box to watch the >> traffic. >> >> If I call from the Blink app to another extension it all connects and >> audio works correctly. If I hangup in Blink, a BYE is sent via OpenSIPS to >> Asterisk - all good so far. >> If I call from another extension to the Blink app it all connects and >> audio works correctly. However, if I hangup in the Blink app, no BYE is >> sent to OpenSIPS. >> >> In most situations, this is merely inconvenient because, with the loss of >> RTP traffic, Asterisk generates a BYE after about 35 seconds to tidy >> everything up. However, if I'm doing an attended transfer, the BYE is >> needed to exit the call so that the transfer completes successfully. At the >> moment, if I hangup in the Blink app, there's a wait of 35 seconds until >> Asterisk creates the BYE before the call transfer is completed. >> >> While I'm mostly using Blink, I've seen similar failures to send BYEs >> from other apps. Does OpenSIPS offer anything that could help with this? >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > *0333 332 | x-on.co.uk <https://www.x-on.co.uk> | ** > <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> > <https://twitter.com/xonuk> ** | Coronavirus > <https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>** > | Practice Index Reviews <https://practiceindex.co.uk/gp/x-on>* > > THE ITSPA AWARDS 2020 <http://www.itspa.org.uk/itspa-awards> AND Best > ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks > of the Internet Telephony Services Providers' Association, used under > licence. > > *From April 1st 2021 our office address will change to: Units 22-24 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 : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. 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 > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Handling missing BYEs
I'm seeing some odd behaviour which also leads into a broader question I have a NATed Blink app running on Linux on my home LAN. It connects to an OpenSIPS 3.1 server in on our office LAN which is a mid-registrar for an Asterisk server. I'm running sngrep on the OpenSIPS box to watch the traffic. If I call from the Blink app to another extension it all connects and audio works correctly. If I hangup in Blink, a BYE is sent via OpenSIPS to Asterisk - all good so far. If I call from another extension to the Blink app it all connects and audio works correctly. However, if I hangup in the Blink app, no BYE is sent to OpenSIPS. In most situations, this is merely inconvenient because, with the loss of RTP traffic, Asterisk generates a BYE after about 35 seconds to tidy everything up. However, if I'm doing an attended transfer, the BYE is needed to exit the call so that the transfer completes successfully. At the moment, if I hangup in the Blink app, there's a wait of 35 seconds until Asterisk creates the BYE before the call transfer is completed. While I'm mostly using Blink, I've seen similar failures to send BYEs from other apps. Does OpenSIPS offer anything that could help with this? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] EXEC not working
This works for me - key change is full path the "ls" command...
$var(out)="";
$var(err)="";
$avp(env)="a";
exec("/usr/bin/ls -l", , $var(out), $var(err), $avp(env));
xlog("Out: $var(out)");
xlog("Err: $var(err)");
On Thu, 4 Feb 2021 at 11:29, Dragomir Haralambiev
wrote:
> Hi,
>
> When try to start Opensips with follow settings:
> exec("ls -l", , $var(out), $var(err), $avp(env));
>
> I receive follow error:
> column 12-21: syntax error
>
> bad arguments for command
>
> На чт, 4.02.2021 г. в 13:15 ч. Mark Allen написа:
>
>> Hi Dragomir,
>>
>> exec is working for me in OpenSIPS 3.1 with command...
>>
>> exec("/root/scripts/script.sh $si", , $var(out), $var(err));
>>
>> Is it the quotes around $var(err) that is causing the null output??
>>
>>
>>
>> On Thu, 4 Feb 2021 at 10:37, Dragomir Haralambiev
>> wrote:
>>
>>> Hello,
>>>
>>> I try to run external program like this
>>>
>>> exec("/test/opensips.pl",,,"$var(err)");
>>> xlog("Received the following error $var(err)");
>>>
>>> Here is log record:
>>> Received the following error
>>>
>>> The program is not running.
>>>
>>> Where is the reason?
>>>
>>> Best regards:
>>> Dragomir
>>> ___
>>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] EXEC not working
Hi Dragomir,
exec is working for me in OpenSIPS 3.1 with command...
exec("/root/scripts/script.sh $si", , $var(out), $var(err));
Is it the quotes around $var(err) that is causing the null output??
On Thu, 4 Feb 2021 at 10:37, Dragomir Haralambiev
wrote:
> Hello,
>
> I try to run external program like this
>
> exec("/test/opensips.pl",,,"$var(err)");
> xlog("Received the following error $var(err)");
>
> Here is log record:
> Received the following error
>
> The program is not running.
>
> Where is the reason?
>
> Best regards:
> Dragomir
> ___
> 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 3.1 - Mid_Registrar AOR throttling & FreePBX/Asterisk Expiry problem
I'm seeing strange behaviour using mid_registrar with AOR throttling...
On initial registration, I do a mid_registrar_save():
mid_registrar_save("location","mp0v","sip:$tU@midreg",,"vipx");
Return value from save is "1" (success) and then I successfully forward the
REGISTER to the FreePBX/Asterisk main registrar (so far so good!).
Asterisk returns a "200 OK" to OpenSIPS which has the registration expiry
value set in both the "Expires" header and in the "Contact" header...
SIP/2.0 200 OK
Expires: 600
Contact: ;expires=600
Mid_Registrar forwards this on to the UAC after modifying the expiry value
for AOR throttling, but only the "expires" setting in the "Contact" header
gets modified...
SIP/2.0 200 OK
Expires: 600
Contact: ;expires=300
This leads to the unpredictable behaviour I'm seeing. MicoSIP seems to
prefer to use the "Contact" header expiry value, and so works fine,
however, Blink and a test MizuTech softphone seem to prefer the "Expires"
header value, and so are not using the AOR throttling value.
In the above example, Mid_Registrar is expecting the UAC to REGISTER again
before 300 seconds have elapsed to maintain the registration, but Blink or
the MizuTech softphone believe they should renew their registration before
600 seconds. When Mid_Registrar does not get the expected registration at
around 300 seconds it assumes the connection is lost and de-registers on
Asterisk. Finally, the UAC renews the registration at around 600 seconds
meaning the UAC is effectively cycling between being available/unavailable.
I have written a workaround in our config file to remove the invalid value
before the "200 OK" gets forwarded to the UAC, but should mid_registrar be
changing the expiry value in both places?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Mediaproxy configuration
Further to this - as I said the relay_ip overcame the immediate audio problem, but on testing it timed out after just over 60 seconds. Looking at the traffic in Wireshark and the SDP in SIP messages the cause seems to be that Asterisk is sending RTP direct to the 46.xxx.xxx.xxx address rather than via the relay, while traffic in the other direction is coming via the relay - so after about a minute Mediaproxy thinks one end is dead and aborts the connection. This is obviously the issue you flagged up John where you said "You need the address in the SDP to be the public IP 4x.xxx.xxx.xxx when it is sending packets to the UAC but you need it to use its LAN address when sending to the Asterisk server." Looks like I'll have to use RTPEngine bridging mode instead. Thanks for the help again :) ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Mediaproxy configuration
Hi John and Johan - thanks for your replies. I'll have a look at RTPEngine to see if it makes things simpler for me. I have managed to get audio working both ways with Mediaproxy - the problem I was encountering was with config.ini settings. I had to explicitly set "relay_ip" and restarted Mediaproxy relay, dispatcher, and OpenSIPS after which audio worked both ways. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] OpenSIPS 3.1, mid_registrar and NAT handling
Our setup... External UAC 192.168.x.x | Router5.x.x.x | (internet) | Firewall 46.x.x.x maps ports | directly to OpenSIPS 192.168.x.x Mid-registrar and Mediaproxy | Asterisk 192.168.x.x Current situation: - UAC can call destination registered on Asterisk on local n/w - UAC registration "appears" to work via Mid-Registrar with AOR throttling - Destination extension rings and can pick up call - Audio works both ways (though drops after about 60 seconds) However... OPTIONS coming from Asterisk ends up being directed to the local IP address at the UAC end (i.e. instead of going out over the internet it tries to use the end destination local IP address following mid_registrar_lookup()). Despite the UAC extension appearing to be registered on Asterisk, when I call is placed to it, it immediately goes to voicemail - doesn't even seem to attempt to call out to OpenSIPS - exactly as if no endpoint is registered. I've seen posts relating to this with earlier version of OpenSIPS and setting mid_registrar insertion mode to 1, but that doesn't seem to be an option with 3.1. What's the best way to handle this? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 & NAT issues
Thanks for the responses. They helped me exclude some things. I've managed to make progress and pinned down the lack of audio to a misconfiguration of Mediaproxy. Two-way audio through double-nat / firewall is working but goes silent after about 60 seconds connected and Asterisk kills the connection 31 seconds later due to lack of RTP activity for the last 31 seconds On Thu, 14 Jan 2021 at 12:00, David Villasmil < david.villasmil.w...@gmail.com> wrote: > Check out what IPs are offered in the SDPs in asterisk. Make sure they’re > both public IPs. > If you only have 1 asterisk, forwarding the rtp port range configured in > asterisk from the firewall to asterisk should do it. > > > On Thu, 14 Jan 2021 at 08:23, Mark Allen wrote: > >> Thanks Adrian >> >> The firewall has SIP-ALG disabled and just forwards ports from externally >> to where they need to be internally - so ports 5060 and 1 - 65535 of >> 46.x.x.x are mapped to 192.168.x.x (the OpenSIPS box) >> >> On Wed, 13 Jan 2021 at 17:32, Adrian Georgescu >> wrote: >> >>> Google search for SIP ALG problem to see if this is relevant for your >>> case. >>> >>> Regards, >>> Adrian >>> >>> >>> On 13 Jan 2021, at 13:08, Mark Allen wrote: >>> >>> Hi all - I've been banging my head against this but not succeeding. >>> >>> Our setup... >>> >>> UAC 192.168.x.x >>> | >>> Router5.x.x.x >>> | >>> (internet) >>> | >>> Firewall 46.x.x.x maps >>> | directly to >>> OpenSIPS 192.168.x.x Mid-registrar >>> | >>> Asterisk 192.168.x.x >>> >>> >>> Current situation: >>> - UAC can register on Asterisk via OpenSIPS >>> - UAC can call destination registered on Asterisk on local n/w to >>> Asterisk box >>> - Destination extension rings and can pick up call >>> - There is no audio either way & call drops after about 30 secs >>> (Asterisk kills call with "Requested channel not available" because not >>> RTP traffic is reaching destination) >>> >>> I have tried passing audio through Mediaproxy on OpenSIPS box but with >>> no success. Using Wireshark I can see RTP traffic initiated at both ends, >>> but it doesn't reach the other end either way. >>> >>> Is there some definitive guide to setting this up correctly or are there >>> specific steps that I need to follow? >>> >>> ___ >>> 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
Re: [OpenSIPS-Users] OpenSIPS 3.1 & NAT issues
Thanks Adrian The firewall has SIP-ALG disabled and just forwards ports from externally to where they need to be internally - so ports 5060 and 1 - 65535 of 46.x.x.x are mapped to 192.168.x.x (the OpenSIPS box) On Wed, 13 Jan 2021 at 17:32, Adrian Georgescu wrote: > Google search for SIP ALG problem to see if this is relevant for your case. > > Regards, > Adrian > > > On 13 Jan 2021, at 13:08, Mark Allen wrote: > > Hi all - I've been banging my head against this but not succeeding. > > Our setup... > > UAC 192.168.x.x > | > Router5.x.x.x > | > (internet) > | > Firewall 46.x.x.x maps > | directly to > OpenSIPS 192.168.x.x Mid-registrar > | > Asterisk 192.168.x.x > > > Current situation: > - UAC can register on Asterisk via OpenSIPS > - UAC can call destination registered on Asterisk on local n/w to Asterisk > box > - Destination extension rings and can pick up call > - There is no audio either way & call drops after about 30 secs (Asterisk > kills call with "Requested channel not available" because not RTP traffic > is reaching destination) > > I have tried passing audio through Mediaproxy on OpenSIPS box but with no > success. Using Wireshark I can see RTP traffic initiated at both ends, but > it doesn't reach the other end either way. > > Is there some definitive guide to setting this up correctly or are there > specific steps that I need to follow? > > ___ > 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
[OpenSIPS-Users] OpenSIPS 3.1 & NAT issues
Hi all - I've been banging my head against this but not succeeding. Our setup... UAC 192.168.x.x | Router5.x.x.x | (internet) | Firewall 46.x.x.x maps | directly to OpenSIPS 192.168.x.x Mid-registrar | Asterisk 192.168.x.x Current situation: - UAC can register on Asterisk via OpenSIPS - UAC can call destination registered on Asterisk on local n/w to Asterisk box - Destination extension rings and can pick up call - There is no audio either way & call drops after about 30 secs (Asterisk kills call with "Requested channel not available" because not RTP traffic is reaching destination) I have tried passing audio through Mediaproxy on OpenSIPS box but with no success. Using Wireshark I can see RTP traffic initiated at both ends, but it doesn't reach the other end either way. Is there some definitive guide to setting this up correctly or are there specific steps that I need to follow? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
Your right Johan! :-D
For info - I do see an error in the log...
TIMER_ROUTE: get data
ERROR:core:parse_from_header: bad msg or missing FROM header
ERROR:core:pv_get_from_attr: cannot parse From header
Message info: , , , DUMMY
...where "Message info" comes from: xlog("Message info: $fU, $tU, $td,
$rm");
However, I've had multiple timers kicking off LUA scripts all running for a
while now and I've not seen any problems. YMMV
On Wed, 23 Dec 2020 at 15:17, johan wrote:
> then you are fine :-)
> On 4/12/2020 09:26, Mark Allen wrote:
>
> Interestingly - TIMER already seems to use some form of dummy message to
> avoid problems. If I add the line...
>
> timer_route[checkNodeCache, 5] {
> xlog("TIMER_ROUTE");
> xlog("Message info: $fU, $tU, $td, $rm");
>
> ...what is logged is...
>
> Message info: , , , DUMMY
>
> ...so LUA will be passed a (very simple) message it seems
>
>
>
> On Thu, 3 Dec 2020 at 15:57, Mark Allen wrote:
>
>> LOL! Yes, I did understand, but it is an important distinction.
>>
>> On Thu, 3 Dec 2020 at 15:53, Ben Newlin wrote:
>>
>>> It seems like you read that as I intended, but I want to clarify I meant
>>> to say I *wouldn’t* feel safe assuming that this would work long term.
>>>
>>>
>>>
>>> Ben Newlin
>>>
>>>
>>>
>>> *From: *Users on behalf of Mark
>>> Allen
>>> *Date: *Thursday, December 3, 2020 at 10:40 AM
>>> *To: *OpenSIPS users mailling list
>>> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>>>
>>> > a memory leak or segfault after continued use
>>>
>>>
>>>
>>> Yes - it would be useful to know if this could result in problems down
>>> the road. Not sure how else I can run a timed job if I can't use the TIMER
>>> route though.
>>>
>>>
>>>
>>> On Thu, 3 Dec 2020 at 15:17, Ben Newlin wrote:
>>>
>>> Mark,
>>>
>>>
>>>
>>> My concern was less about you using the message object in LUA as it was
>>> with how robust OpenSIPS’ handling is if a message if expected to be there
>>> and memory is allocated and passed but there is no actual message due to
>>> this “trick”. Without digging into the actual code, I would feel safe
>>> assuming that this wouldn’t result in a memory leak or segfault after
>>> continued use.
>>>
>>>
>>>
>>> Ben Newlin
>>>
>>>
>>>
>>> *From: *Users on behalf of Mark
>>> Allen
>>> *Date: *Thursday, December 3, 2020 at 10:04 AM
>>> *To: *OpenSIPS users mailling list
>>> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>>>
>>> Thanks, Johan and Ben.
>>>
>>>
>>>
>>> Johan:
>>>
>>> I tried your suggested approach and (much to my surprise) it worked both
>>> for lua_exec and cache_remove_chunk. Thanks for that.
>>>
>>>
>>>
>>> Ben:
>>>
>>> I understand what you are saying for LUA. However, I think that if it's
>>> made clear that you do not have access to (or should not use) the message,
>>> the results should be predictable. It seems to work for me.
>>>
>>>
>>>
>>> My LUA function is reading in external data and doesn't make use of the
>>> message at all. Perhaps there might be a way to provide an empty message to
>>> LUA if it's invoked in TIMER routes to avoid possible problems? LUA and
>>> Python offer powerful extendablity to OpenSIPS, so it seems to me to be a
>>> bit of a shame to limit their use at startup or in timers if all that's
>>> needed is a tweak - or even just a warning in the documentation.
>>>
>>>
>>>
>>> As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run
>>> this in a straightforward way as it's not dependent on the current message
>>> as far as I understand it.
>>>
>>>
>>>
>>>
>>>
>>> If anybody wants to try doing this - here's an example that worked for
>>> me in OpenSIPS 3.1...
>>>
>>>
>>>
>>> timer_route[refreshNodes, 30] {
>>> route(remove_chunk);
>>> route(cache_reload);
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> route[remove_chunk] {
>>> cache_remo
Re: [OpenSIPS-Users] Mediaproxy configuration
Sorry... should have added that OpenSIPS box is acting as mid-registrar
On Thu, 7 Jan 2021, 12:12 Mark Allen, wrote:
> I wonder if anyone can help me with this? I am trying to configure
> Mediaproxy to handle RTP traffic coming from outside our local network.
> Here's the setup:
>
> UAC ---> IPA ---> IPB ---> Mediaproxy / OpenSIPS ---> Asterisk
>
> IPA (a public IP address 4x.xxx.xxx.xxx) maps ports ports 5060 and 1
> to 65535 to IPB (local IP address 192.168.xxx.xxx). IPB is actually a
> Virtual IP managed by keepalived.
> UAC is MizuDroid app running on my Android phone connected to my home
> network (NATed) with a public IP of 5.xxx.xxx.xxx. Everything else relates
> to our office network.
> Mediaproxy Dispatcher and Relay are both running on the same (OpenSIPS)
> system
>
> SIP conversation between UAC and Asterisk via OpenSIPS looks to be working
> fine. Endpoints connect, exchange data, and hangup. The problem is with SDP
> addressing (NAT problem) causing no audio either way, which is what I want
> Mediaproxy to handle.
>
> In opensips.cfg I'm passing control for calls arriving at IPA to
> Mediaproxy...
>
> if (is_method("INVITE")) {
> if (!has_totag()) {
> if ($fd == "4x.xxx.xxx.xxx") {
> xlog("Passing control to Mediaproxy...");
> engage_media_proxy();
> }
> }
> }
>
> In /etc/mediaproxy/config.ini all settings are defaults except for setting
> dispatcher as IPB...
>
> dispatchers = 192.168.xxx.xxx
>
> ...and I've tried it with and without advertised_ip set to IPA...
>
> advertised_ip = 4x.xxx.xxx.xxx
>
>
> I can see that Mediaproxy is taking control of calls as instructed and
> making changes to SDP but it's not solving my audio problems. What am I
> doing wrong
>
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Mediaproxy configuration
I wonder if anyone can help me with this? I am trying to configure
Mediaproxy to handle RTP traffic coming from outside our local network.
Here's the setup:
UAC ---> IPA ---> IPB ---> Mediaproxy / OpenSIPS ---> Asterisk
IPA (a public IP address 4x.xxx.xxx.xxx) maps ports ports 5060 and 1 to
65535 to IPB (local IP address 192.168.xxx.xxx). IPB is actually a Virtual
IP managed by keepalived.
UAC is MizuDroid app running on my Android phone connected to my home
network (NATed) with a public IP of 5.xxx.xxx.xxx. Everything else relates
to our office network.
Mediaproxy Dispatcher and Relay are both running on the same (OpenSIPS)
system
SIP conversation between UAC and Asterisk via OpenSIPS looks to be working
fine. Endpoints connect, exchange data, and hangup. The problem is with SDP
addressing (NAT problem) causing no audio either way, which is what I want
Mediaproxy to handle.
In opensips.cfg I'm passing control for calls arriving at IPA to
Mediaproxy...
if (is_method("INVITE")) {
if (!has_totag()) {
if ($fd == "4x.xxx.xxx.xxx") {
xlog("Passing control to Mediaproxy...");
engage_media_proxy();
}
}
}
In /etc/mediaproxy/config.ini all settings are defaults except for setting
dispatcher as IPB...
dispatchers = 192.168.xxx.xxx
...and I've tried it with and without advertised_ip set to IPA...
advertised_ip = 4x.xxx.xxx.xxx
I can see that Mediaproxy is taking control of calls as instructed and
making changes to SDP but it's not solving my audio problems. What am I
doing wrong
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Mediaproxy Relay start error - 'MediaRelayBase' is not defined
Yep - the software loaded successfully, integrated with OpenSIPS and I can see in the log file that it is trying to handle RTP traffic. Just need to work out the correct configuration now! :) Thanks for the help Adrian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Mediaproxy Relay start error - 'MediaRelayBase' is not defined
Hi Adrian - thanks for getting back to me
I'm getting an unexpected error on apt-get update using the following in
sources.list...
# AG Projects software
deb http://ag-projects.com/debian unstable main
deb-src http://ag-projects.com/debian unstable main
...I get...
Err:10 https://ag-projects.com/debian unstable Release
404 Not Found [IP: 85.17.186.10 443]
E: The repository 'http://ag-projects.com/debian unstable Release' no
longer has a Release file.
...I've checked with nmap and I can see port 443 on 85.17.186.10
I've set it to use 'buster' instead of 'unstable' ('buster' was previously
giving me a similar error)...
# AG Projects software
deb http://ag-projects.com/debian buster main
deb-src http://ag-projects.com/debian buster main
...and that seems to now be working as I get...
Hit:5 https://ag-projects.com/debian buster InRelease
...and when I install packages I'm seeing...
Get:1 https://ag-projects.com/debian buster/main amd64
mediaproxy-common amd64 4.0.5buster [63.1 kB]
Get:2 https://ag-projects.com/debian buster/main amd64
mediaproxy-dispatcher all 4.0.5buster [18.1 kB]
Get:3 https://ag-projects.com/debian buster/main amd64 mediaproxy-relay
all 4.0.5buster [18.6 kB]
Fetched 99.8 kB in 0s (535 kB/s)
...so hopefully I'm good to go now.
Thanks for your help. I'll post a follow-up once I've got it up and running
On Wed, 6 Jan 2021 at 21:59, Adrian Georgescu wrote:
> This was a bug.
>
> You must update to the latest mediaproxy version:
>
> sudo apt update
> sudo apt install mediaproxy-relay mediaproxy-common mediaproxy-dispatcher
>
> Regards,
> Adrian
>
> On 6 Jan 2021, at 12:59, Mark Allen wrote:
>
> Hi all - not sure what I'm missing here...
>
> I'm installing Mediaproxy onto our Debian Buster box which is also running
> OpenSIPS 3.1 but when I start the relay I'm getting an error in syslog...
>
> 15:40:07 opensipsx media-relay[4983]: INFO Starting MediaProxy Relay
> 4.0.4
> 15:40:07 opensipsx media-relay[4983]: INFO Set resource limit for
> maximum open file descriptors to 11000
> 15:40:07 opensipsx media-relay[4983]: CRITICAL Failed to create MediaProxy
> Relay: name 'MediaRelayBase' is not defined
> 15:40:07 opensipsx media-relay[4983]: ERRORTraceback (most recent call
> last):#012ERROR File "/usr/bin/media-relay", line 100, in
> #012ERRORfrom mediaproxy.relay import MediaRelay#012ERROR
>File "/usr/lib/python3/dist-packages/mediaproxy/relay.py", line 290, in
> #012ERRORclass MediaRelay(MediaRelayBase):#012ERROR
> NameError: name 'MediaRelayBase' is not defined
> 15:40:07 opensipsx systemd[1]: mediaproxy-relay.service: Main process
> exited, code=exited, status=1/FAILURE
> 15:40:07 opensipsx systemd[1]: mediaproxy-relay.service: Failed with
> result 'exit-code'.
>
> I'm starting the relay with the command...
>
> systemctl start mediaproxy-relay
>
> ...I installed Mediaproxy using the Debian package using the instructions
> at http://mediaproxy.ag-projects.com/installation-guide/ and
> https://github.com/AGProjects/mediaproxy. mediaproxy-dispatcher is
> starting successfully.
>
> In the /etc/mediaproxy/config.ini file - everything is left at the default
> setting except for...
>
> dispatchers = xxx.xxx.xxx.xxx
> advertised_ip = xxx.xxx.xxx.xxx
>
> Certificates are in place in /etc/mediaproxy/tls
>
>
> Anybody got any ideas about where I've gone wrong
>
>
>
> ___
> 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
[OpenSIPS-Users] Mediaproxy Relay start error - 'MediaRelayBase' is not defined
Hi all - not sure what I'm missing here... I'm installing Mediaproxy onto our Debian Buster box which is also running OpenSIPS 3.1 but when I start the relay I'm getting an error in syslog... 15:40:07 opensipsx media-relay[4983]: INFO Starting MediaProxy Relay 4.0.4 15:40:07 opensipsx media-relay[4983]: INFO Set resource limit for maximum open file descriptors to 11000 15:40:07 opensipsx media-relay[4983]: CRITICAL Failed to create MediaProxy Relay: name 'MediaRelayBase' is not defined 15:40:07 opensipsx media-relay[4983]: ERRORTraceback (most recent call last):#012ERROR File "/usr/bin/media-relay", line 100, in #012ERRORfrom mediaproxy.relay import MediaRelay#012ERROR File "/usr/lib/python3/dist-packages/mediaproxy/relay.py", line 290, in #012ERRORclass MediaRelay(MediaRelayBase):#012ERROR NameError: name 'MediaRelayBase' is not defined 15:40:07 opensipsx systemd[1]: mediaproxy-relay.service: Main process exited, code=exited, status=1/FAILURE 15:40:07 opensipsx systemd[1]: mediaproxy-relay.service: Failed with result 'exit-code'. I'm starting the relay with the command... systemctl start mediaproxy-relay ...I installed Mediaproxy using the Debian package using the instructions at http://mediaproxy.ag-projects.com/installation-guide/ and https://github.com/AGProjects/mediaproxy. mediaproxy-dispatcher is starting successfully. In the /etc/mediaproxy/config.ini file - everything is left at the default setting except for... dispatchers = xxx.xxx.xxx.xxx advertised_ip = xxx.xxx.xxx.xxx Certificates are in place in /etc/mediaproxy/tls Anybody got any ideas about where I've gone wrong ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri
Hi Juan Carlos - I feel your pain!
I've finished for the year so I don't have access to the code at the
moment. I'll have a look at this in the new year to see if I can post
something sensible! :-)
Short version is that it turned out to be a horrible challenge to get it
working as desired. My memory is that the difficulty in finding a suitable
workaround arose because of how OpenSIPS works (LUMPS system) when you make
changes in that they are only committed at the end. This means that if you
change $du to something new but if you then immediately xlog("$du") you'll
still see the original value - the change is only committed when you've
finished working on that SIP message.
In the WSS and mid-registrar case, it means that to workaround the wss
problem by using the path setting I had to loopback the SIP message to
OpenSIPS to then be able to see the Path value. I had to fudge some things
with code but it's working for us now. Maybe somebody else knows a more
straightforward way?
On Wed, 23 Dec 2020 at 15:16, juancarlosg6 wrote:
> Hi, iam having the same situation, can you copy the opensips.cfg as
> reference, iam having issue with incoming calls to webrtc extensions, my
> opensips version is 3.1 and is working with mid_registar, i can do calls to
> SIP extensions, SIP Trunk, but not working when incoming calls to extension
> Webrtc is loged throung Opensips using mid_registar, thank you.
>
>
>
> --
> Sent from:
> http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html
>
> ___
> 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] lua_exec in timer route - OpenSIPS 3.1
Interestingly - TIMER already seems to use some form of dummy message to
avoid problems. If I add the line...
timer_route[checkNodeCache, 5] {
xlog("TIMER_ROUTE");
xlog("Message info: $fU, $tU, $td, $rm");
...what is logged is...
Message info: , , , DUMMY
...so LUA will be passed a (very simple) message it seems
On Thu, 3 Dec 2020 at 15:57, Mark Allen wrote:
> LOL! Yes, I did understand, but it is an important distinction.
>
> On Thu, 3 Dec 2020 at 15:53, Ben Newlin wrote:
>
>> It seems like you read that as I intended, but I want to clarify I meant
>> to say I *wouldn’t* feel safe assuming that this would work long term.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users on behalf of Mark Allen
>>
>> *Date: *Thursday, December 3, 2020 at 10:40 AM
>> *To: *OpenSIPS users mailling list
>> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>>
>> > a memory leak or segfault after continued use
>>
>>
>>
>> Yes - it would be useful to know if this could result in problems down
>> the road. Not sure how else I can run a timed job if I can't use the TIMER
>> route though.
>>
>>
>>
>> On Thu, 3 Dec 2020 at 15:17, Ben Newlin wrote:
>>
>> Mark,
>>
>>
>>
>> My concern was less about you using the message object in LUA as it was
>> with how robust OpenSIPS’ handling is if a message if expected to be there
>> and memory is allocated and passed but there is no actual message due to
>> this “trick”. Without digging into the actual code, I would feel safe
>> assuming that this wouldn’t result in a memory leak or segfault after
>> continued use.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users on behalf of Mark Allen
>>
>> *Date: *Thursday, December 3, 2020 at 10:04 AM
>> *To: *OpenSIPS users mailling list
>> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>>
>> Thanks, Johan and Ben.
>>
>>
>>
>> Johan:
>>
>> I tried your suggested approach and (much to my surprise) it worked both
>> for lua_exec and cache_remove_chunk. Thanks for that.
>>
>>
>>
>> Ben:
>>
>> I understand what you are saying for LUA. However, I think that if it's
>> made clear that you do not have access to (or should not use) the message,
>> the results should be predictable. It seems to work for me.
>>
>>
>>
>> My LUA function is reading in external data and doesn't make use of the
>> message at all. Perhaps there might be a way to provide an empty message to
>> LUA if it's invoked in TIMER routes to avoid possible problems? LUA and
>> Python offer powerful extendablity to OpenSIPS, so it seems to me to be a
>> bit of a shame to limit their use at startup or in timers if all that's
>> needed is a tweak - or even just a warning in the documentation.
>>
>>
>>
>> As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run
>> this in a straightforward way as it's not dependent on the current message
>> as far as I understand it.
>>
>>
>>
>>
>>
>> If anybody wants to try doing this - here's an example that worked for me
>> in OpenSIPS 3.1...
>>
>>
>>
>> timer_route[refreshNodes, 30] {
>> route(remove_chunk);
>> route(cache_reload);
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>> route[remove_chunk] {
>> cache_remove_chunk("validNodes", "*");
>> }
>>
>> route[cache_reload] {
>> lua_exec("getValidNodes");
>> for ($var(node) in $(avp(validNodes)[*])) {
>> cache_store("local:validNodes", "$var(node)", "true");
>> }
>> }
>>
>>
>>
>>
>>
>>
>>
>> On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote:
>>
>> I wouldn’t recommend trying to bypass the restriction in this way. Both
>> the lua and python exec modules were designed to operate on a SIP message,
>> which is why they can only be called from routes that process messages.
>> Calling it from time_route where there is no message, even if you could get
>> it to work, could have unexpected and unpleasant results.
>>
>>
>>
>> From LUA module doc for lua_exec: “Calls a Lua function with passing it
>> the current SIP message” [1].
>>
>>
>>
>> [1] h
Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
LOL! Yes, I did understand, but it is an important distinction.
On Thu, 3 Dec 2020 at 15:53, Ben Newlin wrote:
> It seems like you read that as I intended, but I want to clarify I meant
> to say I *wouldn’t* feel safe assuming that this would work long term.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users on behalf of Mark Allen <
> m...@allenclan.co.uk>
> *Date: *Thursday, December 3, 2020 at 10:40 AM
> *To: *OpenSIPS users mailling list
> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>
> > a memory leak or segfault after continued use
>
>
>
> Yes - it would be useful to know if this could result in problems down the
> road. Not sure how else I can run a timed job if I can't use the TIMER
> route though.
>
>
>
> On Thu, 3 Dec 2020 at 15:17, Ben Newlin wrote:
>
> Mark,
>
>
>
> My concern was less about you using the message object in LUA as it was
> with how robust OpenSIPS’ handling is if a message if expected to be there
> and memory is allocated and passed but there is no actual message due to
> this “trick”. Without digging into the actual code, I would feel safe
> assuming that this wouldn’t result in a memory leak or segfault after
> continued use.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users on behalf of Mark Allen <
> m...@allenclan.co.uk>
> *Date: *Thursday, December 3, 2020 at 10:04 AM
> *To: *OpenSIPS users mailling list
> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>
> Thanks, Johan and Ben.
>
>
>
> Johan:
>
> I tried your suggested approach and (much to my surprise) it worked both
> for lua_exec and cache_remove_chunk. Thanks for that.
>
>
>
> Ben:
>
> I understand what you are saying for LUA. However, I think that if it's
> made clear that you do not have access to (or should not use) the message,
> the results should be predictable. It seems to work for me.
>
>
>
> My LUA function is reading in external data and doesn't make use of the
> message at all. Perhaps there might be a way to provide an empty message to
> LUA if it's invoked in TIMER routes to avoid possible problems? LUA and
> Python offer powerful extendablity to OpenSIPS, so it seems to me to be a
> bit of a shame to limit their use at startup or in timers if all that's
> needed is a tweak - or even just a warning in the documentation.
>
>
>
> As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run
> this in a straightforward way as it's not dependent on the current message
> as far as I understand it.
>
>
>
>
>
> If anybody wants to try doing this - here's an example that worked for me
> in OpenSIPS 3.1...
>
>
>
> timer_route[refreshNodes, 30] {
> route(remove_chunk);
> route(cache_reload);
>
> }
>
>
>
>
>
>
>
> route[remove_chunk] {
> cache_remove_chunk("validNodes", "*");
> }
>
> route[cache_reload] {
> lua_exec("getValidNodes");
> for ($var(node) in $(avp(validNodes)[*])) {
> cache_store("local:validNodes", "$var(node)", "true");
> }
> }
>
>
>
>
>
>
>
> On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote:
>
> I wouldn’t recommend trying to bypass the restriction in this way. Both
> the lua and python exec modules were designed to operate on a SIP message,
> which is why they can only be called from routes that process messages.
> Calling it from time_route where there is no message, even if you could get
> it to work, could have unexpected and unpleasant results.
>
>
>
> From LUA module doc for lua_exec: “Calls a Lua function with passing it
> the current SIP message” [1].
>
>
>
> [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680
>
>
>
> Ben Newlin
>
>
>
> *From: *Users on behalf of Johan De
> Clercq
> *Date: *Thursday, December 3, 2020 at 6:55 AM
> *To: *OpenSIPS users mailling list
> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>
> what you can try, is to call another route in the time route.
>
> And then in that route, you execute the lua script.
>
> maybe (just a myabe) that will work.
>
>
>
> wkr,
>
>
>
> Op do 3 dec. 2020 om 12:23 schreef Mark Allen :
>
> Hi Johan
>
>
>
> In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the
> routes available to lua_exec. If I include it in a TIMER route, OpenSIPS
> fails to start with syntax error and the log error is:
>
>
>
> CRITICAL:core:yyerror: parse error in
> /etc/op
Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
> a memory leak or segfault after continued use
Yes - it would be useful to know if this could result in problems down the
road. Not sure how else I can run a timed job if I can't use the TIMER
route though.
On Thu, 3 Dec 2020 at 15:17, Ben Newlin wrote:
> Mark,
>
>
>
> My concern was less about you using the message object in LUA as it was
> with how robust OpenSIPS’ handling is if a message if expected to be there
> and memory is allocated and passed but there is no actual message due to
> this “trick”. Without digging into the actual code, I would feel safe
> assuming that this wouldn’t result in a memory leak or segfault after
> continued use.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users on behalf of Mark Allen <
> m...@allenclan.co.uk>
> *Date: *Thursday, December 3, 2020 at 10:04 AM
> *To: *OpenSIPS users mailling list
> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>
> Thanks, Johan and Ben.
>
>
>
> Johan:
>
> I tried your suggested approach and (much to my surprise) it worked both
> for lua_exec and cache_remove_chunk. Thanks for that.
>
>
>
> Ben:
>
> I understand what you are saying for LUA. However, I think that if it's
> made clear that you do not have access to (or should not use) the message,
> the results should be predictable. It seems to work for me.
>
>
>
> My LUA function is reading in external data and doesn't make use of the
> message at all. Perhaps there might be a way to provide an empty message to
> LUA if it's invoked in TIMER routes to avoid possible problems? LUA and
> Python offer powerful extendablity to OpenSIPS, so it seems to me to be a
> bit of a shame to limit their use at startup or in timers if all that's
> needed is a tweak - or even just a warning in the documentation.
>
>
>
> As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run
> this in a straightforward way as it's not dependent on the current message
> as far as I understand it.
>
>
>
>
>
> If anybody wants to try doing this - here's an example that worked for me
> in OpenSIPS 3.1...
>
>
>
> timer_route[refreshNodes, 30] {
> route(remove_chunk);
> route(cache_reload);
>
> }
>
>
>
>
>
>
>
> route[remove_chunk] {
> cache_remove_chunk("validNodes", "*");
> }
>
> route[cache_reload] {
> lua_exec("getValidNodes");
> for ($var(node) in $(avp(validNodes)[*])) {
> cache_store("local:validNodes", "$var(node)", "true");
> }
> }
>
>
>
>
>
>
>
> On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote:
>
> I wouldn’t recommend trying to bypass the restriction in this way. Both
> the lua and python exec modules were designed to operate on a SIP message,
> which is why they can only be called from routes that process messages.
> Calling it from time_route where there is no message, even if you could get
> it to work, could have unexpected and unpleasant results.
>
>
>
> From LUA module doc for lua_exec: “Calls a Lua function with passing it
> the current SIP message” [1].
>
>
>
> [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680
>
>
>
> Ben Newlin
>
>
>
> *From: *Users on behalf of Johan De
> Clercq
> *Date: *Thursday, December 3, 2020 at 6:55 AM
> *To: *OpenSIPS users mailling list
> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>
> what you can try, is to call another route in the time route.
>
> And then in that route, you execute the lua script.
>
> maybe (just a myabe) that will work.
>
>
>
> wkr,
>
>
>
> Op do 3 dec. 2020 om 12:23 schreef Mark Allen :
>
> Hi Johan
>
>
>
> In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the
> routes available to lua_exec. If I include it in a TIMER route, OpenSIPS
> fails to start with syntax error and the log error is:
>
>
>
> CRITICAL:core:yyerror: parse error in
> /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in
> the block#012
>
>
>
> If I move the lua_exec command into main route{ it works fine
>
>
>
> I also encounter the problem running a cache_remove_chunk in a TIMER route
> although the documentation doesn't say that it's not valid for TIMER route.
> It fails on startup with the error:
>
>
>
> CRITICAL:core:yyerror: parse error in
> /etc/opensips/opensips.cfg:266:33-34: Command cannot
> be used in the block#012
>
>
>
> Again - if I run the command in main route{ the command works fine
>
>
Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
Thanks, Johan and Ben.
Johan:
I tried your suggested approach and (much to my surprise) it worked both
for lua_exec and cache_remove_chunk. Thanks for that.
Ben:
I understand what you are saying for LUA. However, I think that if it's
made clear that you do not have access to (or should not use) the message,
the results should be predictable. It seems to work for me.
My LUA function is reading in external data and doesn't make use of the
message at all. Perhaps there might be a way to provide an empty message to
LUA if it's invoked in TIMER routes to avoid possible problems? LUA and
Python offer powerful extendablity to OpenSIPS, so it seems to me to be a
bit of a shame to limit their use at startup or in timers if all that's
needed is a tweak - or even just a warning in the documentation.
As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run
this in a straightforward way as it's not dependent on the current message
as far as I understand it.
If anybody wants to try doing this - here's an example that worked for me
in OpenSIPS 3.1...
timer_route[refreshNodes, 30] {
route(remove_chunk);
route(cache_reload);
}
route[remove_chunk] {
cache_remove_chunk("validNodes", "*");
}
route[cache_reload] {
lua_exec("getValidNodes");
for ($var(node) in $(avp(validNodes)[*])) {
cache_store("local:validNodes", "$var(node)", "true");
}
}
On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote:
> I wouldn’t recommend trying to bypass the restriction in this way. Both
> the lua and python exec modules were designed to operate on a SIP message,
> which is why they can only be called from routes that process messages.
> Calling it from time_route where there is no message, even if you could get
> it to work, could have unexpected and unpleasant results.
>
>
>
> From LUA module doc for lua_exec: “Calls a Lua function with passing it
> the current SIP message” [1].
>
>
>
> [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680
>
>
>
> Ben Newlin
>
>
>
> *From: *Users on behalf of Johan De
> Clercq
> *Date: *Thursday, December 3, 2020 at 6:55 AM
> *To: *OpenSIPS users mailling list
> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
>
> what you can try, is to call another route in the time route.
>
> And then in that route, you execute the lua script.
>
> maybe (just a myabe) that will work.
>
>
>
> wkr,
>
>
>
> Op do 3 dec. 2020 om 12:23 schreef Mark Allen :
>
> Hi Johan
>
>
>
> In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the
> routes available to lua_exec. If I include it in a TIMER route, OpenSIPS
> fails to start with syntax error and the log error is:
>
>
>
> CRITICAL:core:yyerror: parse error in
> /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in
> the block#012
>
>
>
> If I move the lua_exec command into main route{ it works fine
>
>
>
> I also encounter the problem running a cache_remove_chunk in a TIMER route
> although the documentation doesn't say that it's not valid for TIMER route.
> It fails on startup with the error:
>
>
>
> CRITICAL:core:yyerror: parse error in
> /etc/opensips/opensips.cfg:266:33-34: Command cannot
> be used in the block#012
>
>
>
> Again - if I run the command in main route{ the command works fine
>
>
>
>
>
> cheers,
>
>
>
> Mark
>
>
>
> On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote:
>
> It for sure does not run in async mode.
>
> Did you try executing a script in timer route ?
>
> What's the output in the log ?
>
>
>
> Op do 3 dec. 2020 om 11:56 schreef Mark Allen :
>
> Is there a way to run a lua_exec from a timer route?
>
> ___
> 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
>
> ___
> 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] lua_exec in timer route - OpenSIPS 3.1
Hi Johan
In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the
routes available to lua_exec. If I include it in a TIMER route, OpenSIPS
fails to start with syntax error and the log error is:
CRITICAL:core:yyerror: parse error in
/etc/opensips/opensips.cfg:265:19-20: Command cannot be used in
the block#012
If I move the lua_exec command into main route{ it works fine
I also encounter the problem running a cache_remove_chunk in a TIMER route
although the documentation doesn't say that it's not valid for TIMER route.
It fails on startup with the error:
CRITICAL:core:yyerror: parse error in
/etc/opensips/opensips.cfg:266:33-34: Command cannot
be used in the block#012
Again - if I run the command in main route{ the command works fine
cheers,
Mark
On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote:
> It for sure does not run in async mode.
> Did you try executing a script in timer route ?
> What's the output in the log ?
>
> Op do 3 dec. 2020 om 11:56 schreef Mark Allen :
>
>> Is there a way to run a lua_exec from a timer route?
>> ___
>> 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
[OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1
Is there a way to run a lua_exec from a timer route? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 - Test if cache is empty?
Good point - I'll do that
On Wed, 2 Dec 2020 at 16:33, Liviu Chircu wrote:
> On 02.12.2020 18:16, Mark Allen wrote:
>
> Thanks so much for your help Liviu. In the end, I used the $shv() approach
> you suggested. It worked like a dream! :-)
>
> In opensips.cfg:
>
> loadmodule "cfgutils.so"
> modparam("cfgutils", "shvset", "cacheValid=i:0")
>
> route{
> if ($shv(cacheValid) == 0) {
>
> Glad it worked! Depending on the volume of traffic flowing through your
> instance, maybe it would be better to perform the "is cache valid" check
> within a timer route [1] at a frequency of your choosing, rather than on
> each SIP request.
>
> [1]: https://www.opensips.org/Documentation/Script-Routes-3-2#toc8
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 - Test if cache is empty?
Thanks so much for your help Liviu. In the end, I used the $shv() approach
you suggested. It worked like a dream! :-)
In opensips.cfg:
loadmodule "cfgutils.so"
modparam("cfgutils", "shvset", "cacheValid=i:0")
route{
if ($shv(cacheValid) == 0) {
xlog("Reloading cache");
...code to reload cached data goes here...
$shv(cacheValid) = 1;
}
Trigger reload using opensips-cli:
opensips-cli -x mi shv_set cacheValid int 0
On Wed, 25 Nov 2020 at 14:26, Liviu Chircu wrote:
> On 25.11.2020 16:18, Mark Allen wrote:
> > If the DB table is updated I can flush the cache of the old data with
> > "opensips-cli -x mi cache_remove_chunk". I would then want to have a
> > test in OpenSIPS that says that if the cache is empty, re-populate it
> > from the DB. Is this possible?
>
> Hi, Mark!
>
> From my knowledge, the "cachedb is empty" test is not available right now.
>
> However, why not use either the recently added "raise_event" [1]
> function, or even a shared $shv(cache_reset) variable [2] as a pure
> "on/off" binary marker in order to hook into the opensips.cfg
> environment via MI interface and then instruct OpenSIPS to do a
> cache_remove_chunk() [3], followed by re-populating the cache?
>
> [1]: https://www.opensips.org/Documentation/Interface-CoreMI-3-2#toc20
> [2]: https://opensips.org/docs/modules/3.2.x/cfgutils.html#idp337920
> [3]:
>
> https://opensips.org/docs/modules/3.2.x/cachedb_local.html#func_cache_remove_chunk
>
> Best regards,
>
> --
> 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
[OpenSIPS-Users] OpenSIPS 3.1 - Test if cache is empty?
Is there a simple way to test if a cache has any values stored? I have a cache collection holding a number of IP addresses that are read on startup from a local DB. If the DB table is updated I can flush the cache of the old data with "opensips-cli -x mi cache_remove_chunk". I would then want to have a test in OpenSIPS that says that if the cache is empty, re-populate it from the DB. Is this possible? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Clear local cache collection without OpenSIPS 3.1 restart
Bingo! That did the job!
Thanks very much for that Vlad - you've saved me hours of head-scratching!
On Fri, 20 Nov 2020 at 13:42, Vlad Patrascu wrote:
> I did forget to escape the "*" character in the example I gave, so this
> should work:
>
> opensips-cli -x mi cache_remove_chunk "*" other
>
> Regards,
>
> --
> Vlad Patrascu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 20.11.2020 15:25, Mark Allen wrote:
>
> thanks Vlad - I've tried it but I get
>
> ERROR: command 'cache_remove_chunk' returned: -32602: Invalid params
>
> On Fri, 20 Nov 2020 at 13:21, Vlad Patrascu wrote:
>
>> Hi Mark,
>>
>> The command you should run is:
>>
>> opensips-cli -x mi cache_remove_chunk * other
>>
>> I will also update the docs as the example is outdated so thanks for
>> pointing it out!
>>
>> Regards,
>>
>> --
>> Vlad Patrascu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 20.11.2020 13:47, Mark Allen wrote:
>>
>> I have local cache collections setup in my script:
>>
>> loadmodule "cachedb_local.so"
>> modparam("cachedb_local", "cache_collections", "general; other;")
>> modparam("cachedb_local", "cachedb_url", "local:general:///general")
>> modparam("cachedb_local", "cachedb_url", "local:other:///other")
>>
>> I want to be able to use opensips-cli to clear the contents of the
>> "other" collection from the command line or a script without needing to
>> restart OpenSIPS or losing the contents of the "general" cache collection.
>> I've looked at the cachedb_local documentation for exported MI functions
>> but I don't understand how this translates into a valid opensips-cli
>> command.
>>
>> Any help gratefully received! :D
>>
>>
>> ___
>> 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
> 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] Clear local cache collection without OpenSIPS 3.1 restart
thanks Vlad - I've tried it but I get
ERROR: command 'cache_remove_chunk' returned: -32602: Invalid params
On Fri, 20 Nov 2020 at 13:21, Vlad Patrascu wrote:
> Hi Mark,
>
> The command you should run is:
>
> opensips-cli -x mi cache_remove_chunk * other
>
> I will also update the docs as the example is outdated so thanks for
> pointing it out!
>
> Regards,
>
> --
> Vlad Patrascu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 20.11.2020 13:47, Mark Allen wrote:
>
> I have local cache collections setup in my script:
>
> loadmodule "cachedb_local.so"
> modparam("cachedb_local", "cache_collections", "general; other;")
> modparam("cachedb_local", "cachedb_url", "local:general:///general")
> modparam("cachedb_local", "cachedb_url", "local:other:///other")
>
> I want to be able to use opensips-cli to clear the contents of the "other"
> collection from the command line or a script without needing to restart
> OpenSIPS or losing the contents of the "general" cache collection. I've
> looked at the cachedb_local documentation for exported MI functions but I
> don't understand how this translates into a valid opensips-cli command.
>
> Any help gratefully received! :D
>
>
> ___
> 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
[OpenSIPS-Users] Fwd: Clear local cache collection without OpenSIPS 3.1 restart
Sorry - accidentally tagged this on to another thread, so please excuse the
repost...
I have local cache collections setup in my script:
loadmodule "cachedb_local.so"
modparam("cachedb_local", "cache_collections", "general; other;")
modparam("cachedb_local", "cachedb_url", "local:general:///general")
modparam("cachedb_local", "cachedb_url", "local:other:///other")
I want to be able to use opensips-cli to clear the contents of the "other"
collection from the command line or a script without needing to restart
OpenSIPS or losing the contents of the "general" cache collection. I've
looked at the cachedb_local documentation for exported MI functions but I
don't understand how this translates into a valid opensips-cli command.
Any help gratefully received! :D
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Clear local cache collection without OpenSIPS 3.1 restart
I have local cache collections setup in my script:
loadmodule "cachedb_local.so"
modparam("cachedb_local", "cache_collections", "general; other;")
modparam("cachedb_local", "cachedb_url", "local:general:///general")
modparam("cachedb_local", "cachedb_url", "local:other:///other")
I want to be able to use opensips-cli to clear the contents of the "other"
collection from the command line or a script without needing to restart
OpenSIPS or losing the contents of the "general" cache collection. I've
looked at the cachedb_local documentation for exported MI functions but I
don't understand how this translates into a valid opensips-cli command.
Any help gratefully received! :D
___
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
thanks - that's really helpful
On Mon, 16 Nov 2020 at 18:13, Ovidiu Sas wrote:
> Use the sql_cacher module to cache the content of the file.
> First, declare the cache that you want to use, then configure the
> sql_cacher to use the file:
> loadmodule "cachedb_local.so"
> modparam("cachedb_local", "cache_collections", "my_cache")
> modparam("cachedb_local", "cachedb_url", "local:///my_cache")
> loadmodule "sql_cacher.so"
> modparam("sql_cacher", "cache_table",
> "id=my_cache_id
> db_url=text:///tmp/opensipsdb
> cachedb_url=local:///my_cache
> table=my_table
> key=my_key
> columns=my_value
> on_demand=0")
>
> Or you can simply use the avpops module directly on the db_text file.
>
> -ovidiu
>
> https://opensips.org/docs/modules/3.1.x/cachedb_local.html
> https://opensips.org/docs/modules/3.1.x/sql_cacher.html
> https://opensips.org/docs/modules/3.1.x/avpops.html
>
> On Sun, Nov 15, 2020 at 9:49 AM Mark Allen wrote:
> >
> > Being a bit dense here - the documentation says to set modparams like...
> >
> > modparam("usrloc|auth_db", "db_url", "text:///tmp/opensipsdb")
> >
> > ...if I'm using a separate table with our specific info rather than,
> say, usrloc - what am I putting in as the module name?
> >
> > On Fri, 13 Nov 2020 at 16:39, Maxim Sobolev
> wrote:
> >>
> >> 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 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
> >
> > ___
> > 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 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
Being a bit dense here - the documentation says to set modparams like...
modparam("usrloc|auth_db", "db_url", "text:///tmp/opensipsdb")
...if I'm using a separate table with our specific info rather than, say,
usrloc - what am I putting in as the module name?
On Fri, 13 Nov 2020 at 16:39, Maxim Sobolev wrote:
> 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
>
___
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
Thanks Max. I've not tried using python, though I have used LUA before
which offers similar functionality. However, I would like a solution which
can be applied across most routes including startup and timer if possible.
On Fri, 13 Nov 2020 at 14:56, Maxim Sobolev wrote:
> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Reading contents of a file - OpenSIPS 3.1
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
Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing
Hi Stas - thanks for getting back to me. That helped me move forward a lot - particularly where you included what you see in the Path field - it helped to exclude a range of possible causes for the issues I was seeing. > If you do not have "path" set in your case the problem is probably there. Yes, because of how the "lumps" system works, and because WebRTC phone is connecting directly to OpenSIPS server, the incoming REGISTER didn't have a path, so to get the path saved in "location" I had to loop back to OpenSIPS again (thanks very much Johan De Clercq for filling in that part of the jigsaw). That then introduced some other problems that I had to resolve (particularly with RTPEngine going crazy looping back on itself and sending CPU temperature over 100degC - but that's another story!), but I've now got AOR throttling working with the mid-registrar successfully. Still a few bits to tweak with my script but it looks like I'm on the home straight. Thanks once again for all your help cheers, Mark On Fri, 21 Aug 2020 at 14:59, Stas Kobzar wrote: > Hello Mark, > > In my case I do have a path in the location record. Here is my example > from "ul show" (I changed my real domain and IPs): > AOR:: 9...@example.com > Contact:: sip:suvp4v56@1p6pc0g6m3ml.invalid;transport=ws > Q= > Expires:: 494 > Callid:: i1tmiaipa3l2nvvhmairvu > Cseq:: 28 > User-agent:: JsSIP 3.5.3 > Path:: ;r2=on;lr>, 10.0.0.213:47326> > State:: CS_SYNC > Flags:: 0 > Cflags:: > Socket:: udp:10.0.0.185:5060 > Methods:: 5503 > SIP_instance:: > > > And here is my mysql location record: > > mysql> select contact, path from locations where username =9170; > > ++--+ > | contact| path > > | > > ++--+ > | sip:suvp4v56@1p6pc0g6m3ml.invalid;transport=ws | > , ;transport=wss;r2=on;lr;received=sip:107.179.246.213:47364> | > > ++--+ > > If you do not have "path" set in your case the problem is probably there. > My lookup is not mid_register but it is close to what you have. I only use > parameter "m" to lookup in memory. > > On Fri, Aug 21, 2020 at 9:19 AM Mark Allen wrote: > >> What am I looking for? >> >> INVITE from Asterisk to Opensips looks fine. Contact info from "location" >> matches that seen in console for web phone. >> >> Problem seems to be that the address is not recognised as a web socket >> rather than a host name. It's not NATed but tried fix_nated_register() and >> fix_nated_contact() but it made no difference. >> >> On Fri, 21 Aug 2020, 13:23 Slava Bendersky via Users, < >> users@lists.opensips.org> wrote: >> >>> Please check contact header. >>> >>> volga629 >>> >>> -- >>> *From: *"Mark Allen" >>> *To: *"OpenSIPS users mailling list" >>> *Sent: *Friday, August 21, 2020 8:08:18 AM >>> *Subject: *Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling >>> withWebRTC failing >>> >>> I've not received any feedback on this regarding whether or not what I'm >>> doing should be working. Trying to find a workaround has just led to a >>> number of dead-ends. Can anyone please help me with this? >>> We are using mid-registrar with AOR Throttling talking to >>> Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP >>> phones, physical and softphones, connected on our LAN, all works fine. >>> Where we hit problems is with WebRTC phones. >>> >>> WebRTC phone registers via mid-registrar without a problem. However, a >>> call coming from Asterisk (e.g. extension --> extension) fails with an >>> error like: >>> >>> 476 Unresolvable destination >>> >>> ...and a syslog entry... >>> >>> ERROR:core:sip_re
Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing
What am I looking for?
INVITE from Asterisk to Opensips looks fine. Contact info from "location"
matches that seen in console for web phone.
Problem seems to be that the address is not recognised as a web socket
rather than a host name. It's not NATed but tried fix_nated_register() and
fix_nated_contact() but it made no difference.
On Fri, 21 Aug 2020, 13:23 Slava Bendersky via Users, <
users@lists.opensips.org> wrote:
> Please check contact header.
>
> volga629
>
> ------
> *From: *"Mark Allen"
> *To: *"OpenSIPS users mailling list"
> *Sent: *Friday, August 21, 2020 8:08:18 AM
> *Subject: *Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling
> withWebRTC failing
>
> I've not received any feedback on this regarding whether or not what I'm
> doing should be working. Trying to find a workaround has just led to a
> number of dead-ends. Can anyone please help me with this?
> We are using mid-registrar with AOR Throttling talking to
> Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP
> phones, physical and softphones, connected on our LAN, all works fine.
> Where we hit problems is with WebRTC phones.
>
> WebRTC phone registers via mid-registrar without a problem. However, a
> call coming from Asterisk (e.g. extension --> extension) fails with an
> error like:
>
> 476 Unresolvable destination
>
> ...and a syslog entry...
>
> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri
> CRITICAL:core:mk_proxy: could not resolve hostname:
> "cfdtugr3cntl.invalid"
> ERROR:tm:uri2proxy: bad host name in URI ;rtcweb-breaker=yes;transport=wss>
> ERROR:tm:t_forward_nonack: failure to add branches
>
> We can get calls to WebRTC from Asterisk working via OpenSIPS if we are
> only using registration throttling. As this establishes a 1:1 relationship,
> by using add_path_received() we get Asterisk to include a Route which
> bypasses the resolvehost problem. However, with multiple endpoints
> registered to a single OpenSIPS AOR with AOR throttling, this workaround
> obviously won't work. How can I set up OpenSIPS so that we can have
> multiple endpoints, including WebRTC ones, registered to a single OpenSIPS
> AOR and have calls successfully reach the WebRTC phones?
>
>
>
>
>
>
>
>
> On Mon, 3 Aug 2020 at 08:44, Mark Allen wrote:
>
>> I don't know if anyone has had a chance to look at my problem but I
>> wonder if at least I could get an opinion on the following:
>> 1 - Should I be seeing the path saved in the appropriate column in the
>> "location" table?
>> 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with path
>> support correctly in my script?
>> 3 - have I correctly understood how to combine WebRTC with mid-registrar
>> module, path, and AOR throttling so that it should work for calls
>> originating from the main registrar?
>>
>> I'm stuck on how to move forward with this
>>
>> Cheers,
>>
>> Mark
>>
>> Relevant code snippets...
>>
>> loadmodule "mid_registrar.so"
>> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */
>> modparam("mid_registrar", "outgoing_expires", 3600)
>>
>> add_path_received();
>> $avp(returncode) = mid_registrar_save("location","p0v");
>> switch ($avp(returncode)) {
>> case 1:
>> route(resolve_registrar);
>> $ru = "sip:" + $avp(main_registrar) + ":5060";
>> t_on_failure("1");
>> t_relay();
>> break;
>> case 2:
>> break;
>> default:
>> }
>>
>> if (!mid_registrar_lookup("location")) {
>> t_reply(404, "Not Found");
>> exit;
>> }
>>
>>
>> NB - route(resolve_registrar) sets the variable $avp(main_registrar) to
>> the IP address of the Asterisk server
>>
>> On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote:
>>
>>> We are working on a test setup, hoping to move to a production system in
>>> mid-August. We want to use mid-registrar AOR throttling. Users will connect
>>> through OpenSIPS using a combination of SIP and WebRTC endpoints,
>>> registering to an extension on an Asterisk main-registrar...
>>>
>>> +--+
>>> ---> | | +--+
>>> ---> | OpenSIPS | ---> | Asterisk |
>>> ---> | | +--+
>>> +--+
>>>
>>
Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing
I've not received any feedback on this regarding whether or not what I'm
doing should be working. Trying to find a workaround has just led to a
number of dead-ends. Can anyone please help me with this?
We are using mid-registrar with AOR Throttling talking to Asterisk/FreePBX.
We have OpenSIPS 3.1 running on Debian Buster. For SIP phones, physical and
softphones, connected on our LAN, all works fine. Where we hit problems is
with WebRTC phones.
WebRTC phone registers via mid-registrar without a problem. However, a call
coming from Asterisk (e.g. extension --> extension) fails with an error
like:
476 Unresolvable destination
...and a syslog entry...
ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri
CRITICAL:core:mk_proxy: could not resolve hostname: "cfdtugr3cntl.invalid"
ERROR:tm:uri2proxy: bad host name in URI
ERROR:tm:t_forward_nonack: failure to add branches
We can get calls to WebRTC from Asterisk working via OpenSIPS if we are
only using registration throttling. As this establishes a 1:1 relationship,
by using add_path_received() we get Asterisk to include a Route which
bypasses the resolvehost problem. However, with multiple endpoints
registered to a single OpenSIPS AOR with AOR throttling, this workaround
obviously won't work. How can I set up OpenSIPS so that we can have
multiple endpoints, including WebRTC ones, registered to a single OpenSIPS
AOR and have calls successfully reach the WebRTC phones?
On Mon, 3 Aug 2020 at 08:44, Mark Allen wrote:
> I don't know if anyone has had a chance to look at my problem but I wonder
> if at least I could get an opinion on the following:
>
> 1 - Should I be seeing the path saved in the appropriate column in the
> "location" table?
> 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with path
> support correctly in my script?
> 3 - have I correctly understood how to combine WebRTC with mid-registrar
> module, path, and AOR throttling so that it should work for calls
> originating from the main registrar?
>
> I'm stuck on how to move forward with this
>
> Cheers,
>
> Mark
>
> Relevant code snippets...
>
> loadmodule "mid_registrar.so"
> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */
> modparam("mid_registrar", "outgoing_expires", 3600)
>
> add_path_received();
> $avp(returncode) = mid_registrar_save("location","p0v");
> switch ($avp(returncode)) {
> case 1:
> route(resolve_registrar);
> $ru = "sip:" + $avp(main_registrar) + ":5060";
> t_on_failure("1");
> t_relay();
> break;
> case 2:
> break;
> default:
> }
>
> if (!mid_registrar_lookup("location")) {
> t_reply(404, "Not Found");
> exit;
> }
>
>
> NB - route(resolve_registrar) sets the variable $avp(main_registrar) to
> the IP address of the Asterisk server
>
> On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote:
>
>> We are working on a test setup, hoping to move to a production system in
>> mid-August. We want to use mid-registrar AOR throttling. Users will connect
>> through OpenSIPS using a combination of SIP and WebRTC endpoints,
>> registering to an extension on an Asterisk main-registrar...
>>
>> +--+
>> ---> | | +--+
>> ---> | OpenSIPS | ---> | Asterisk |
>> ---> | | +--+
>> +--+
>>
>> Multiple SIP phones (hardware or softphones) registering via an OpenSIPS
>> 3.1 mid_registration AOR is working fine. A call to the extension number on
>> Asterisk results in all mid-registered SIP extensions ringing and when one
>> answers, the other devices register a missed call. So far, so good.
>>
>> With 3.0 - we had a problem with WebRTC "phones" (even when just using
>> mid_registrar in "mirroring" mode). Webphone could register and call other
>> phones without a problem. However, calls to the WebPhone failed - there was
>> a problem with the WebSocket addressing giving "476 Unresolvable
>> destination" when the call originates from the main registrar - e.g. one
>> extension calling another. The /var/log/syslog entry said...
>>
>> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri
>> CRITICAL:core:mk_proxy: could not resolve hostname:
>> "4xp44jxl0qq0.invalid"
>> ERROR:tm:uri2proxy: bad host name in URI > 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss>
>> ERROR:tm:t_forward_nonack: failure to add branches
>>
>> Stas Kobar gave me
Re: [OpenSIPS-Users] 3.1 - access Path and Via values from REGISTER
Thanks Johan - I'll try this out
On Mon, 3 Aug 2020 at 11:25, Johan De Clercq wrote:
> t_relay to the socket on which you are listening.
>
> Op ma 3 aug. 2020 om 12:21 schreef Mark Allen :
>
>> > If you want to see it, loopback the message.
>>
>> Thanks. How do I do that?
>>
>> On Mon, 3 Aug 2020 at 11:02, Johan De Clercq wrote:
>>
>>> I think that you are right.
>>> If you want to see it, loopback the message.
>>>
>>> Op ma 3 aug. 2020 om 11:16 schreef Mark Allen :
>>>
>>>> Would I be right in thinking that the reason I cannot immediately see
>>>> the "path" value added by the add_path_received() call is because of how
>>>> the lumps system works - i.e.
>>>>
>>>> "lumps are stored in a list, and are only applied
>>>>after the OpenSIPS script is fully executed and
>>>>before the SIP message is relayed. Because of
>>>>this, changes done on a SIP message are not
>>>>immediately reflected on the SIP message upon
>>>>further inspection ( eg. Adding a new header from
>>>>the script and then checking for the header's
>>>>existence )."
>>>>
>>>> From: https://www.opensips.org/Documentation/Development-Manual
>>>>
>>>> On Thu, 30 Jul 2020 at 16:24, Mark Allen wrote:
>>>>
>>>>> Seeking to find a workaround for the problem I'm having with WebRTC
>>>>> and AOR throttling (
>>>>> http://lists.opensips.org/pipermail/users/2020-July/043542.html) I
>>>>> want to access the values of the "Via" and "Path" headers that are being
>>>>> passed to the registrar.
>>>>>
>>>>> Using sngrep on the OpenSIPS server I can see the REGISTER includes
>>>>> Path and Via headers. If I try to access them with $(hdr(Path)[0]) or
>>>>> $(hdr(Via)[0]) I get nothing, but I can access the values of all the
>>>>> other headers without any problem - e.g. $(hdr(Authorization)[0]). What
>>>>> am
>>>>> I missing or is there another way to get the info used in the Via
>>>>> and particularly in creating the Path header values???
>>>>>
>>>>> add_path_received();
>>>>> xlog(" $(hdr(Path)[0]) !!");
>>>>> $avp(attr) = $(hdr(Path)[0]);
>>>>> mid_registrar_save("location","p0v");
>>>>>
>>>>> The code gives an "attr" value in the "location" table of "NULL"
>>>>>
>>>>> /var/log/syslog shows:
>>>>>
>>>>> Jul 30 16:13:17 /usr/sbin/opensips[27423]:
>>>>> !!
>>>>>
>>>> ___
>>>> 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
>>
> ___
> 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] 3.1 - access Path and Via values from REGISTER
> If you want to see it, loopback the message.
Thanks. How do I do that?
On Mon, 3 Aug 2020 at 11:02, Johan De Clercq wrote:
> I think that you are right.
> If you want to see it, loopback the message.
>
> Op ma 3 aug. 2020 om 11:16 schreef Mark Allen :
>
>> Would I be right in thinking that the reason I cannot immediately see the
>> "path" value added by the add_path_received() call is because of how the
>> lumps system works - i.e.
>>
>> "lumps are stored in a list, and are only applied
>>after the OpenSIPS script is fully executed and
>>before the SIP message is relayed. Because of
>>this, changes done on a SIP message are not
>>immediately reflected on the SIP message upon
>>further inspection ( eg. Adding a new header from
>>the script and then checking for the header's
>>existence )."
>>
>> From: https://www.opensips.org/Documentation/Development-Manual
>>
>> On Thu, 30 Jul 2020 at 16:24, Mark Allen wrote:
>>
>>> Seeking to find a workaround for the problem I'm having with WebRTC and
>>> AOR throttling (
>>> http://lists.opensips.org/pipermail/users/2020-July/043542.html) I want
>>> to access the values of the "Via" and "Path" headers that are being passed
>>> to the registrar.
>>>
>>> Using sngrep on the OpenSIPS server I can see the REGISTER includes Path
>>> and Via headers. If I try to access them with $(hdr(Path)[0]) or
>>> $(hdr(Via)[0]) I get nothing, but I can access the values of all the
>>> other headers without any problem - e.g. $(hdr(Authorization)[0]). What am
>>> I missing or is there another way to get the info used in the Via
>>> and particularly in creating the Path header values???
>>>
>>> add_path_received();
>>> xlog(" $(hdr(Path)[0]) !!");
>>> $avp(attr) = $(hdr(Path)[0]);
>>> mid_registrar_save("location","p0v");
>>>
>>> The code gives an "attr" value in the "location" table of "NULL"
>>>
>>> /var/log/syslog shows:
>>>
>>> Jul 30 16:13:17 /usr/sbin/opensips[27423]:
>>> !!
>>>
>> ___
>> 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] 3.1 - access Path and Via values from REGISTER
Would I be right in thinking that the reason I cannot immediately see the
"path" value added by the add_path_received() call is because of how the
lumps system works - i.e.
"lumps are stored in a list, and are only applied
after the OpenSIPS script is fully executed and
before the SIP message is relayed. Because of
this, changes done on a SIP message are not
immediately reflected on the SIP message upon
further inspection ( eg. Adding a new header from
the script and then checking for the header's
existence )."
From: https://www.opensips.org/Documentation/Development-Manual
On Thu, 30 Jul 2020 at 16:24, Mark Allen wrote:
> Seeking to find a workaround for the problem I'm having with WebRTC and
> AOR throttling (
> http://lists.opensips.org/pipermail/users/2020-July/043542.html) I want
> to access the values of the "Via" and "Path" headers that are being passed
> to the registrar.
>
> Using sngrep on the OpenSIPS server I can see the REGISTER includes Path
> and Via headers. If I try to access them with $(hdr(Path)[0]) or
> $(hdr(Via)[0]) I get nothing, but I can access the values of all the
> other headers without any problem - e.g. $(hdr(Authorization)[0]). What am
> I missing or is there another way to get the info used in the Via
> and particularly in creating the Path header values???
>
> add_path_received();
> xlog(" $(hdr(Path)[0]) !!");
> $avp(attr) = $(hdr(Path)[0]);
> mid_registrar_save("location","p0v");
>
> The code gives an "attr" value in the "location" table of "NULL"
>
> /var/log/syslog shows:
>
> Jul 30 16:13:17 /usr/sbin/opensips[27423]:
> !!
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing
I don't know if anyone has had a chance to look at my problem but I wonder
if at least I could get an opinion on the following:
1 - Should I be seeing the path saved in the appropriate column in the
"location" table?
2 - Am I using mid_registrar_save() and mid_registrar_lookup() with path
support correctly in my script?
3 - have I correctly understood how to combine WebRTC with mid-registrar
module, path, and AOR throttling so that it should work for calls
originating from the main registrar?
I'm stuck on how to move forward with this
Cheers,
Mark
Relevant code snippets...
loadmodule "mid_registrar.so"
modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */
modparam("mid_registrar", "outgoing_expires", 3600)
add_path_received();
$avp(returncode) = mid_registrar_save("location","p0v");
switch ($avp(returncode)) {
case 1:
route(resolve_registrar);
$ru = "sip:" + $avp(main_registrar) + ":5060";
t_on_failure("1");
t_relay();
break;
case 2:
break;
default:
}
if (!mid_registrar_lookup("location")) {
t_reply(404, "Not Found");
exit;
}
NB - route(resolve_registrar) sets the variable $avp(main_registrar) to the
IP address of the Asterisk server
On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote:
> We are working on a test setup, hoping to move to a production system in
> mid-August. We want to use mid-registrar AOR throttling. Users will connect
> through OpenSIPS using a combination of SIP and WebRTC endpoints,
> registering to an extension on an Asterisk main-registrar...
>
> +--+
> ---> | | +--+
> ---> | OpenSIPS | ---> | Asterisk |
> ---> | | +--+
> +--+
>
> Multiple SIP phones (hardware or softphones) registering via an OpenSIPS
> 3.1 mid_registration AOR is working fine. A call to the extension number on
> Asterisk results in all mid-registered SIP extensions ringing and when one
> answers, the other devices register a missed call. So far, so good.
>
> With 3.0 - we had a problem with WebRTC "phones" (even when just using
> mid_registrar in "mirroring" mode). Webphone could register and call other
> phones without a problem. However, calls to the WebPhone failed - there was
> a problem with the WebSocket addressing giving "476 Unresolvable
> destination" when the call originates from the main registrar - e.g. one
> extension calling another. The /var/log/syslog entry said...
>
> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri
> CRITICAL:core:mk_proxy: could not resolve hostname:
> "4xp44jxl0qq0.invalid"
> ERROR:tm:uri2proxy: bad host name in URI 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss>
> ERROR:tm:t_forward_nonack: failure to add branches
>
> Stas Kobar gave me a way to resolve this -
> http://lists.opensips.org/pipermail/users/2020-July/043443.html As we
> were using 3.0, I used the "path" module and "add_path_received()" to
> handle this for WebRTC. This worked for a single device registered to an
> address. However, as far as I could see, using "path" effectively bypassed
> the "contact" address held in the OpenSIPS "location" table so it didn't
> work for AOR throttling.
>
> I was hoping that, with mid_registrar on 3.1 baking in path support, I
> could just use "mid_registrar_save('location','p0v')" to store the WebRTC
> destination path in the "location" table. Then, with a call to the WebRTC
> endpoint from the main registrar, "mid_registrar_lookup('location')" would
> use the stored path from the "location" table to send traffic on to the
> WebRTC phone and it would work fine with AOR throttling. However, that's
> not happening, and looking at the "location" table, no path seems to
> be being stored.
>
> If I register a WebRTC "phone" first, the path is included on the
> registration SIP message sent from OpenSIPS to Asterisk. If I then register
> additional SIP phones on OpenSIPS, AOR throttling works, because, when the
> call originates from Asterisk it includes the "route" HF that points to the
> WebRTC destination. However, if a SIP phone registers first, Asterisk
> doesn't get the WebRTC path, so calls fail to reach the WebRTC destination
> because it tries to use the first registered SIP phone's path.
>
> So - 2 questions really...
>
> 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the
> WebRTC endpoint will be the first to register or that there will only be
> one WebR
[OpenSIPS-Users] 3.1 - access Path and Via values from REGISTER
Seeking to find a workaround for the problem I'm having with WebRTC and AOR
throttling (http://lists.opensips.org/pipermail/users/2020-July/043542.html)
I want to access the values of the "Via" and "Path" headers that are being
passed to the registrar.
Using sngrep on the OpenSIPS server I can see the REGISTER includes Path
and Via headers. If I try to access them with $(hdr(Path)[0]) or
$(hdr(Via)[0]) I get nothing, but I can access the values of all the
other headers without any problem - e.g. $(hdr(Authorization)[0]). What am
I missing or is there another way to get the info used in the Via
and particularly in creating the Path header values???
add_path_received();
xlog(" $(hdr(Path)[0]) !!");
$avp(attr) = $(hdr(Path)[0]);
mid_registrar_save("location","p0v");
The code gives an "attr" value in the "location" table of "NULL"
/var/log/syslog shows:
Jul 30 16:13:17 /usr/sbin/opensips[27423]: !!
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing
We are working on a test setup, hoping to move to a production system in
mid-August. We want to use mid-registrar AOR throttling. Users will connect
through OpenSIPS using a combination of SIP and WebRTC endpoints,
registering to an extension on an Asterisk main-registrar...
+--+
---> | | +--+
---> | OpenSIPS | ---> | Asterisk |
---> | | +--+
+--+
Multiple SIP phones (hardware or softphones) registering via an OpenSIPS
3.1 mid_registration AOR is working fine. A call to the extension number on
Asterisk results in all mid-registered SIP extensions ringing and when one
answers, the other devices register a missed call. So far, so good.
With 3.0 - we had a problem with WebRTC "phones" (even when just using
mid_registrar in "mirroring" mode). Webphone could register and call other
phones without a problem. However, calls to the WebPhone failed - there was
a problem with the WebSocket addressing giving "476 Unresolvable
destination" when the call originates from the main registrar - e.g. one
extension calling another. The /var/log/syslog entry said...
ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri
CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid"
ERROR:tm:uri2proxy: bad host name in URI
ERROR:tm:t_forward_nonack: failure to add branches
Stas Kobar gave me a way to resolve this -
http://lists.opensips.org/pipermail/users/2020-July/043443.html As we were
using 3.0, I used the "path" module and "add_path_received()" to handle
this for WebRTC. This worked for a single device registered to an address.
However, as far as I could see, using "path" effectively bypassed the
"contact" address held in the OpenSIPS "location" table so it didn't work
for AOR throttling.
I was hoping that, with mid_registrar on 3.1 baking in path support, I
could just use "mid_registrar_save('location','p0v')" to store the WebRTC
destination path in the "location" table. Then, with a call to the WebRTC
endpoint from the main registrar, "mid_registrar_lookup('location')" would
use the stored path from the "location" table to send traffic on to the
WebRTC phone and it would work fine with AOR throttling. However, that's
not happening, and looking at the "location" table, no path seems to
be being stored.
If I register a WebRTC "phone" first, the path is included on the
registration SIP message sent from OpenSIPS to Asterisk. If I then register
additional SIP phones on OpenSIPS, AOR throttling works, because, when the
call originates from Asterisk it includes the "route" HF that points to the
WebRTC destination. However, if a SIP phone registers first, Asterisk
doesn't get the WebRTC path, so calls fail to reach the WebRTC destination
because it tries to use the first registered SIP phone's path.
So - 2 questions really...
1 - Can I use AOR throttling with WebRTC (I can't guarantee that the WebRTC
endpoint will be the first to register or that there will only be one
WebRTC endpoint)
2 - If the answer to 1 is yes, what am I doing wrong?
Relevant code snippets...
loadmodule "mid_registrar.so"
modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */
modparam("mid_registrar", "outgoing_expires", 3600)
add_path_received();
$avp(returncode) = mid_registrar_save("location","p0v");
switch ($avp(returncode)) {
case 1:
route(resolve_registrar);
$ru = "sip:" + $avp(main_registrar) + ":5060";
t_on_failure("1");
t_relay();
break;
case 2:
break;
default:
}
if (!mid_registrar_lookup("location")) {
t_reply(404, "Not Found");
exit;
}
NB - route(resolve_registrar) sets the variable $avp(main_registrar) to the
IP address of the Asterisk server
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault
Hi Vlad - thanks for that, it's very helpful
All the best
Mark
On Tue, 28 Jul 2020 at 21:40, Vlad Patrascu wrote:
> Hi Mark,
>
> thanks for the report! I have pushed a fix for the crash.
>
> I've also updated the documentation to be more clear about how
> raise_event() should be used and the changes from 3.0. Basically, you don't
> have to necessarily pass both AVP parameters in 3.1, but if you want to
> pass only the attribute values for the event you should do:
>
> raise_event("E_WFC_REGISTERED", , $avp(values));
>
> That is because the event attribute values can now only be passed through
> the corresponding parameter(which is the last one). The way you did it
> initially was equivalent to passing only the event attribute names which in
> 3.1 results in an event with no attributes at all. This in turn was
> unfortunately causing a crash.
>
> Regards,
>
> --
> Vlad Patrascu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 28.07.2020 17:42, Mark Allen wrote:
>
> [SOLVED]
>
> Hi Stas - good call! It's a change in behaviour from 3.0.
>
> In 3.0 documentation says...
>
> The next two parameters should be AVPs and they are optional. If only
> one is present, it should contain the values attached to the event.
>
> In 3.1 it removes mention of the behaviour if only one AVP is present, but
> it's not obvious and perhaps it could be documented in the
> https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide?
> Also, perhaps 3.1 should handle it better if parameter is missing rather
> than giving a segfault (something for 3.2?)
>
> Once again I'm indebted to you for your help
>
> thanks very much & all the best
>
> Mark
>
>
>
>
>
> On Tue, 28 Jul 2020 at 15:22, Stas Kobzar wrote:
>
>> Hi Allen,
>>
>> Did you try with two parameters: name, value?
>>
>>*$avp(keys) = "registered";*
>>$avp(values) = "true";
>> xlog("Raised E_WFC_REGISTERED $avp(values)");
>> raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values));
>>
>> I know they are said to be optional in the documentation but probably it
>> is optional for two. Either no params or if you pass parameters, you have
>> to pass both.
>>
>>
>> On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote:
>>
>>> We're upgrading from 3.0 to 3.1. Everything seems ok except we get a
>>> weird error. We subscribe a dynamic event...
>>>
>>> startup_route {
>>> subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:");
>>> }
>>>
>>> which we can see works from /var/log/syslog...
>>>
>>> event_datagram:mod_init: initializing module ...
>>> core:evi_publish_event: Registered event >>
>>> and in the script we invoke it with...
>>>
>>> if(is_method("REGISTER")) {
>>> $avp(values) = "true";
>>> xlog("Raised E_WFC_REGISTERED $avp(values)");
>>> raise_event("E_WFC_REGISTERED",$avp(values));
>>>
>>> When a phone registers, raise_event() is triggered and OpenSIPS crashes
>>> with a segmentation fault - shown in /var/log/syslog...
>>>
>>> Raised E_WFC_REGISTERED true
>>> CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8
>>> segfault at 8 ip 55cef821313f sp 7ffcdf4d3410 error 4 in
>>> opensips[55cef801a000+264000]
>>> kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63 74
>>> 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef e8
>>> fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00
>>> e8 34
>>> INFO:core:handle_sigs: child process 10525 exited by a signal 11
>>> INFO:core:handle_sigs: core was generated
>>> INFO:core:handle_sigs: terminating due to SIGCHLD
>>>
>>> If I comment out the raise_event() line - OpenSIPS seems fine and
>>> doesn't crash when passing through this code.
>>>
>>>
>>>
>>> Running gdb to get core file backtrace we see...
>>>
>>> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid
>>> -f /etc/opensips/opensips.cfg'.
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id@entry=0,
>>> extra_param_k=extra_param_k@entry=0x0,
>>> extra_param_v=extra_param_v@entry=0x0) at evi/ev
Re: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault
:)
On Tue, 28 Jul 2020 at 15:50, Stas Kobzar wrote:
> I mean, you are welcome, Mark :) sorry
>
> On Tue, Jul 28, 2020 at 10:45 AM Mark Allen wrote:
>
>> [SOLVED]
>>
>> Hi Stas - good call! It's a change in behaviour from 3.0.
>>
>> In 3.0 documentation says...
>>
>> The next two parameters should be AVPs and they are optional. If only
>> one is present, it should contain the values attached to the event.
>>
>> In 3.1 it removes mention of the behaviour if only one AVP is present,
>> but it's not obvious and perhaps it could be documented in the
>> https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide?
>> Also, perhaps 3.1 should handle it better if parameter is missing rather
>> than giving a segfault (something for 3.2?)
>>
>> Once again I'm indebted to you for your help
>>
>> thanks very much & all the best
>>
>> Mark
>>
>>
>>
>>
>>
>> On Tue, 28 Jul 2020 at 15:22, Stas Kobzar wrote:
>>
>>> Hi Allen,
>>>
>>> Did you try with two parameters: name, value?
>>>
>>>*$avp(keys) = "registered";*
>>>$avp(values) = "true";
>>> xlog("Raised E_WFC_REGISTERED $avp(values)");
>>> raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values));
>>>
>>> I know they are said to be optional in the documentation but probably it
>>> is optional for two. Either no params or if you pass parameters, you have
>>> to pass both.
>>>
>>>
>>> On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote:
>>>
>>>> We're upgrading from 3.0 to 3.1. Everything seems ok except we get a
>>>> weird error. We subscribe a dynamic event...
>>>>
>>>> startup_route {
>>>> subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:");
>>>> }
>>>>
>>>> which we can see works from /var/log/syslog...
>>>>
>>>> event_datagram:mod_init: initializing module ...
>>>> core:evi_publish_event: Registered event >>>
>>>> and in the script we invoke it with...
>>>>
>>>> if(is_method("REGISTER")) {
>>>> $avp(values) = "true";
>>>> xlog("Raised E_WFC_REGISTERED $avp(values)");
>>>> raise_event("E_WFC_REGISTERED",$avp(values));
>>>>
>>>> When a phone registers, raise_event() is triggered and OpenSIPS crashes
>>>> with a segmentation fault - shown in /var/log/syslog...
>>>>
>>>> Raised E_WFC_REGISTERED true
>>>> CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8
>>>> segfault at 8 ip 55cef821313f sp 7ffcdf4d3410 error 4 in
>>>> opensips[55cef801a000+264000]
>>>> kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63
>>>> 74 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef
>>>> e8 fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00
>>>> 00 e8 34
>>>> INFO:core:handle_sigs: child process 10525 exited by a signal 11
>>>> INFO:core:handle_sigs: core was generated
>>>> INFO:core:handle_sigs: terminating due to SIGCHLD
>>>>
>>>> If I comment out the raise_event() line - OpenSIPS seems fine and
>>>> doesn't crash when passing through this code.
>>>>
>>>>
>>>>
>>>> Running gdb to get core file backtrace we see...
>>>>
>>>> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid
>>>> -f /etc/opensips/opensips.cfg'.
>>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id@entry=0,
>>>> extra_param_k=extra_param_k@entry=0x0,
>>>> extra_param_v=extra_param_v@entry=0x0) at evi/evi_transport.c:159
>>>> 159 if (params->first && !params->first->name.s) {
>>>> (gdb) bt full
>>>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id@entry=0,
>>>> extra_param_k=extra_param_k@entry=0x0,
>>>> extra_param_v=extra_param_v@entry=0x0) at evi/evi_transport.c:159
>>>> param =
>>>> param_obj = 0x0
>>>> tmp =
>>>> ret_obj = 0x7f9323135fe0
Re: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault
[SOLVED]
Hi Stas - good call! It's a change in behaviour from 3.0.
In 3.0 documentation says...
The next two parameters should be AVPs and they are optional. If only
one is present, it should contain the values attached to the event.
In 3.1 it removes mention of the behaviour if only one AVP is present, but
it's not obvious and perhaps it could be documented in the
https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide?
Also, perhaps 3.1 should handle it better if parameter is missing rather
than giving a segfault (something for 3.2?)
Once again I'm indebted to you for your help
thanks very much & all the best
Mark
On Tue, 28 Jul 2020 at 15:22, Stas Kobzar wrote:
> Hi Allen,
>
> Did you try with two parameters: name, value?
>
>*$avp(keys) = "registered";*
>$avp(values) = "true";
> xlog("Raised E_WFC_REGISTERED $avp(values)");
> raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values));
>
> I know they are said to be optional in the documentation but probably it
> is optional for two. Either no params or if you pass parameters, you have
> to pass both.
>
>
> On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote:
>
>> We're upgrading from 3.0 to 3.1. Everything seems ok except we get a
>> weird error. We subscribe a dynamic event...
>>
>> startup_route {
>> subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:");
>> }
>>
>> which we can see works from /var/log/syslog...
>>
>> event_datagram:mod_init: initializing module ...
>> core:evi_publish_event: Registered event >
>> and in the script we invoke it with...
>>
>> if(is_method("REGISTER")) {
>> $avp(values) = "true";
>> xlog("Raised E_WFC_REGISTERED $avp(values)");
>> raise_event("E_WFC_REGISTERED",$avp(values));
>>
>> When a phone registers, raise_event() is triggered and OpenSIPS crashes
>> with a segmentation fault - shown in /var/log/syslog...
>>
>> Raised E_WFC_REGISTERED true
>> CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8
>> segfault at 8 ip 55cef821313f sp 7ffcdf4d3410 error 4 in
>> opensips[55cef801a000+264000]
>> kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63 74
>> 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef e8
>> fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00
>> e8 34
>> INFO:core:handle_sigs: child process 10525 exited by a signal 11
>> INFO:core:handle_sigs: core was generated
>> INFO:core:handle_sigs: terminating due to SIGCHLD
>>
>> If I comment out the raise_event() line - OpenSIPS seems fine and
>> doesn't crash when passing through this code.
>>
>>
>>
>> Running gdb to get core file backtrace we see...
>>
>> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid
>> -f /etc/opensips/opensips.cfg'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id@entry=0,
>> extra_param_k=extra_param_k@entry=0x0,
>> extra_param_v=extra_param_v@entry=0x0) at evi/evi_transport.c:159
>> 159 if (params->first && !params->first->name.s) {
>> (gdb) bt full
>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id@entry=0,
>> extra_param_k=extra_param_k@entry=0x0,
>> extra_param_v=extra_param_v@entry=0x0) at evi/evi_transport.c:159
>> param =
>> param_obj = 0x0
>> tmp =
>> ret_obj = 0x7f9323135fe0
>> payload = 0x0
>> __FUNCTION__ = "evi_build_payload"
>> #1 0x7f931b7d934f in datagram_raise (msg=,
>> ev_name=, sock=0x7f931f5c54c8, params=)
>> at event_datagram.c:315
>> ret =
>> buf =
>> __FUNCTION__ = "datagram_raise"
>> #2 0x55cef82148fb in evi_raise_event_msg (msg=msg@entry=0x7f9323134890,
>> id=id@entry=20, params=params@entry=0x0)
>> at evi/event_interface.c:208
>> subs = 0x7f931f5c55a8
>> prev =
>> now = 1595943308
>> flags = 1073741838
>> pflags = 0
>> ret = 0
>> __FUNCTION__ = "evi_raise_event_msg"
>> #3 0x55cef8216afb in evi_raise_script_event (msg=0x7f9323134890,
>> id=20, _a=, _v=)
>> at evi/event_interface.c:430
>> vals =
>> attrs =
>>
[OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault
We're upgrading from 3.0 to 3.1. Everything seems ok except we get a weird
error. We subscribe a dynamic event...
startup_route {
subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:");
}
which we can see works from /var/log/syslog...
event_datagram:mod_init: initializing module ...
core:evi_publish_event: Registered event 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00 e8 34
INFO:core:handle_sigs: child process 10525 exited by a signal 11
INFO:core:handle_sigs: core was generated
INFO:core:handle_sigs: terminating due to SIGCHLD
If I comment out the raise_event() line - OpenSIPS seems fine and doesn't
crash when passing through this code.
Running gdb to get core file backtrace we see...
Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f
/etc/opensips/opensips.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id@entry=0,
extra_param_k=extra_param_k@entry=0x0,
extra_param_v=extra_param_v@entry=0x0) at evi/evi_transport.c:159
159 if (params->first && !params->first->name.s) {
(gdb) bt full
#0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id@entry=0,
extra_param_k=extra_param_k@entry=0x0,
extra_param_v=extra_param_v@entry=0x0) at evi/evi_transport.c:159
param =
param_obj = 0x0
tmp =
ret_obj = 0x7f9323135fe0
payload = 0x0
__FUNCTION__ = "evi_build_payload"
#1 0x7f931b7d934f in datagram_raise (msg=,
ev_name=, sock=0x7f931f5c54c8, params=)
at event_datagram.c:315
ret =
buf =
__FUNCTION__ = "datagram_raise"
#2 0x55cef82148fb in evi_raise_event_msg (msg=msg@entry=0x7f9323134890,
id=id@entry=20, params=params@entry=0x0)
at evi/event_interface.c:208
subs = 0x7f931f5c55a8
prev =
now = 1595943308
flags = 1073741838
pflags = 0
ret = 0
__FUNCTION__ = "evi_raise_event_msg"
#3 0x55cef8216afb in evi_raise_script_event (msg=0x7f9323134890,
id=20, _a=, _v=)
at evi/event_interface.c:430
vals =
attrs =
v_avp =
a_avp =
err =
val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", len =
-133061172}}
attr = {n = 0, s = {s = 0x0, len = -133445686}}
at =
params = 0x0
__FUNCTION__ = "evi_raise_script_event"
#4 0x55cef8068c5f in w_raise_event (msg=,
ev_id=, attrs_avp=,
vals_avp=) at core_cmds.c:1204
__FUNCTION__ = "w_raise_event"
#5 0x55cef8086199 in do_action (a=0x7f932304d020, msg=0x7f9323134890)
at action.c:972
ret =
v =
i =
len =
cmatch =
aitem =
adefault =
spec =
val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = -129751552,
flags = 21966}
start = {tv_sec = 94347416839552, tv_usec = 140269924432168}
end_time =
cmd = 0x55cef832c550
acmd =
cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, 0x7f9323134890,
0x55cef80bb253 , 0x1, 0xc}
tmp_vals = {{rs = {s = 0x4 , len = 587509104}, ri = 18, flags = 0}, {rs = {s =
0x7f9323134890 "\001", len = 587509104}, ri = 588466320, flags = 32659},
{rs = {s = 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri =
-131568035, flags = 21966}, {rs = {s = 0x3 , len = 587512256}, ri = 3, flags = 0}, {rs = {s =
0x7ffcdf4d3790 "\220H\023#\223\177", len = 587509104}, ri = -131568035,
flags = 21966}, {rs = {s = 0x3 , len = 0}, ri = 587655824, flags = 32659}, {rs = {s = 0x0, len =
588466320}, ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7
"A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags = 0}}
sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = 587515424}
__FUNCTION__ = "do_action"
(full backtrace is available)
Build is taken from 3.1 branch on GitHub
Server is running Debian 10 (Buster)
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 - DB version table error
Thanks Liviu. That worked. On Tue, 28 Jul 2020 at 09:12, Liviu Chircu wrote: > On 28.07.2020 11:00, Mark Allen wrote: > > Presumably, there's somewhere that I should be telling opensips-cli > > that I want it to use the 3.1 schema? > > Hey, Mark! > > That seems to be the problem, indeed. I assume you haven't yet > installed the 3.1 opensips-mysql-module package, so the CLI can find the > new schema under /usr/local/share/opensips/mysql. Alternatively, if you > have a 3.1 source tree, just force the "database_schema_path" CLI > argument [1] and it should pick up the new tables. > > Hope this helps, > > [1]: > > https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/database.md#database-migration-mysql-only > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > OpenSIPS Summit 2020 Distributed >www.opensips.org/events/Summit-2020Distributed > > > ___ > 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.1 - DB version table error
[SOLVED] Scratch that. I answered my own question. I realised that I had missed the document https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/database.md I ran the command... opensips-cli -o database_schema_path=~/src/opensips-3.1/scripts \ -x database migrate 3.0_to_3.1 opensips opensips_mig_3_1 ...which seems to have upgraded to the correct version On Tue, 28 Jul 2020 at 09:00, Mark Allen wrote: > Presumably, there's somewhere that I should be telling opensips-cli that I > want it to use the 3.1 schema? > > On Tue, 28 Jul 2020 at 08:54, Mark Allen wrote: > >> Getting version table errors on startup after move to 3.1... >> >> ERROR:core:db_check_table_version: invalid version 10 for table >> dialog found, expected 11 >> >> Version 3.1 is built from 3.1 branch on GitHub. I think I've followed the >> documentation correctly but OpenSIPS 3.1 is not starting and I'm seeing >> this error. On our test setup I've tried both... >> >> opensips-cli -x database migrate 3.0_to_3.1 opensips opensips_3_1 >> >> and >> >> opensips-cli -x database create opensips-3_1 >> >> >> Using DB opensips-3_1, a 'SELECT * FROM version;' gives the following... >> >> after database migration: >> +--+---+ >> | table_name | table_version | >> +--+---+ >> | acc | 7 | >> | address | 5 | >> | clusterer| 4 | >> | dbaliases| 2 | >> | dialog |10 | >> | dialplan | 5 | >> | dispatcher | 8 | >> | domain | 3 | >> | dr_carriers | 2 | >> | dr_gateways | 6 | >> | dr_groups| 2 | >> | dr_partitions| 1 | >> | dr_rules | 3 | >> | grp | 3 | >> | load_balancer| 2 | >> | location | 1013 | >> | missed_calls | 5 | >> | re_grp | 2 | >> | rtpengine| 1 | >> | rtpproxy_sockets | 0 | >> | silo | 6 | >> | speed_dial | 3 | >> | subscriber | 7 | >> | tls_mgm | 3 | >> | uri | 2 | >> | usr_preferences | 3 | >> +--+---+ >> >> after database creation: >> +--+---+ >> | table_name | table_version | >> +--+---+ >> | acc | 7 | >> | address | 5 | >> | clusterer| 4 | >> | dbaliases| 2 | >> | dialog |10 | >> | dialplan | 5 | >> | dispatcher | 8 | >> | domain | 3 | >> | dr_carriers | 2 | >> | dr_gateways | 6 | >> | dr_groups| 2 | >> | dr_partitions| 1 | >> | dr_rules | 3 | >> | grp | 3 | >> | load_balancer| 2 | >> | location | 1013 | >> | missed_calls | 5 | >> | re_grp | 2 | >> | rtpengine| 1 | >> | rtpproxy_sockets | 0 | >> | silo | 6 | >> | speed_dial | 3 | >> | subscriber | 7 | >> | tls_mgm | 3 | >> | uri | 2 | >> | usr_preferences | 3 | >> +--+---+ >> >> What am I missing >> >> Documentation used: >> https://github.com/OpenSIPS/opensips/blob/master/INSTALL >> https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 >> >> ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 3.1 - DB version table error
Presumably, there's somewhere that I should be telling opensips-cli that I want it to use the 3.1 schema? On Tue, 28 Jul 2020 at 08:54, Mark Allen wrote: > Getting version table errors on startup after move to 3.1... > > ERROR:core:db_check_table_version: invalid version 10 for table dialog > found, expected 11 > > Version 3.1 is built from 3.1 branch on GitHub. I think I've followed the > documentation correctly but OpenSIPS 3.1 is not starting and I'm seeing > this error. On our test setup I've tried both... > > opensips-cli -x database migrate 3.0_to_3.1 opensips opensips_3_1 > > and > > opensips-cli -x database create opensips-3_1 > > > Using DB opensips-3_1, a 'SELECT * FROM version;' gives the following... > > after database migration: > +--+---+ > | table_name | table_version | > +--+---+ > | acc | 7 | > | address | 5 | > | clusterer| 4 | > | dbaliases| 2 | > | dialog |10 | > | dialplan | 5 | > | dispatcher | 8 | > | domain | 3 | > | dr_carriers | 2 | > | dr_gateways | 6 | > | dr_groups| 2 | > | dr_partitions| 1 | > | dr_rules | 3 | > | grp | 3 | > | load_balancer| 2 | > | location | 1013 | > | missed_calls | 5 | > | re_grp | 2 | > | rtpengine| 1 | > | rtpproxy_sockets | 0 | > | silo | 6 | > | speed_dial | 3 | > | subscriber | 7 | > | tls_mgm | 3 | > | uri | 2 | > | usr_preferences | 3 | > +--+---+ > > after database creation: > +--+---+ > | table_name | table_version | > +--+---+ > | acc | 7 | > | address | 5 | > | clusterer| 4 | > | dbaliases| 2 | > | dialog |10 | > | dialplan | 5 | > | dispatcher | 8 | > | domain | 3 | > | dr_carriers | 2 | > | dr_gateways | 6 | > | dr_groups| 2 | > | dr_partitions| 1 | > | dr_rules | 3 | > | grp | 3 | > | load_balancer| 2 | > | location | 1013 | > | missed_calls | 5 | > | re_grp | 2 | > | rtpengine| 1 | > | rtpproxy_sockets | 0 | > | silo | 6 | > | speed_dial | 3 | > | subscriber | 7 | > | tls_mgm | 3 | > | uri | 2 | > | usr_preferences | 3 | > +--+---+ > > What am I missing > > Documentation used: > https://github.com/OpenSIPS/opensips/blob/master/INSTALL > https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] OpenSIPS 3.1 - DB version table error
Getting version table errors on startup after move to 3.1... ERROR:core:db_check_table_version: invalid version 10 for table dialog found, expected 11 Version 3.1 is built from 3.1 branch on GitHub. I think I've followed the documentation correctly but OpenSIPS 3.1 is not starting and I'm seeing this error. On our test setup I've tried both... opensips-cli -x database migrate 3.0_to_3.1 opensips opensips_3_1 and opensips-cli -x database create opensips-3_1 Using DB opensips-3_1, a 'SELECT * FROM version;' gives the following... after database migration: +--+---+ | table_name | table_version | +--+---+ | acc | 7 | | address | 5 | | clusterer| 4 | | dbaliases| 2 | | dialog |10 | | dialplan | 5 | | dispatcher | 8 | | domain | 3 | | dr_carriers | 2 | | dr_gateways | 6 | | dr_groups| 2 | | dr_partitions| 1 | | dr_rules | 3 | | grp | 3 | | load_balancer| 2 | | location | 1013 | | missed_calls | 5 | | re_grp | 2 | | rtpengine| 1 | | rtpproxy_sockets | 0 | | silo | 6 | | speed_dial | 3 | | subscriber | 7 | | tls_mgm | 3 | | uri | 2 | | usr_preferences | 3 | +--+---+ after database creation: +--+---+ | table_name | table_version | +--+---+ | acc | 7 | | address | 5 | | clusterer| 4 | | dbaliases| 2 | | dialog |10 | | dialplan | 5 | | dispatcher | 8 | | domain | 3 | | dr_carriers | 2 | | dr_gateways | 6 | | dr_groups| 2 | | dr_partitions| 1 | | dr_rules | 3 | | grp | 3 | | load_balancer| 2 | | location | 1013 | | missed_calls | 5 | | re_grp | 2 | | rtpengine| 1 | | rtpproxy_sockets | 0 | | silo | 6 | | speed_dial | 3 | | subscriber | 7 | | tls_mgm | 3 | | uri | 2 | | usr_preferences | 3 | +--+---+ What am I missing Documentation used: https://github.com/OpenSIPS/opensips/blob/master/INSTALL https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri
[SOLVED] Thanks Stas. Your workaround did solve the problem and I see that with 3.1 path support is baked into mid-registrar module as options to mid_registrar_save(). Once we added in the path module functionality, at first it didn't work. Looking at sngrep traces we could see that the path information was appended on the inbound route from OpenSIPS to Asterisk, but when Asterisk made the call to the outbound destination it failed to include it as route info. This was resolved by setting supportpath="yes" in sip.conf and worked with CHAN_SIP. We tried to get it working with PJSIP without any joy but it's not a priority for us at the moment so we'll have to investigate the cause later. Thanks for your help Stas, and thanks also to the others who took the time to reply. cheers, Mark On Tue, 14 Jul 2020 at 16:23, Stas Kobzar wrote: > Hello Mark, > > I had a similar challenge. Using "path" module on both opensips helps > to overcome this problem. > https://opensips.org/docs/modules/3.2.x/path.html > > In your mid-registerer you need to enable path support. See "save" > function params p0 and v. > in your webrtc opensips use path module and function add_path_received > > On Tue, Jul 14, 2020 at 11:14 AM Mark Allen wrote: > > > > I'm new to OpenSIPS and I've hit a problem I can't find a way past > > > > We have a test setup with an OpenSIPS mid-registrar in front of an > Asterisk PBX. Mid-registrar is currently in mode 1 (registration > throttling). We have SIP and WebRTC endpoints that we want to use. > > > > Current state is: > > > > REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> > Asterisk = success > > REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> > Asterisk = success > > > > INVITE:SIP softphone-> OpenSIPS -> Asterisk -> OpenSIPS -> SIP > softphone = success, call connects with audio both ways > > INVITE:WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP > softphone = success, call connects with audio both ways > > INVITE:SIP softphone-> OpenSIPS -> Asterisk -> OpenSIPS -> > WebRTC webphone = fails with "476 Unresolvable destination" > > > > syslog messages: > > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri > > CRITICAL:core:mk_proxy: could not resolve hostname: > "4xp44jxl0qq0.invalid" > > ERROR:tm:uri2proxy: bad host name in URI ;rtcweb-breaker=yes;transport=wss> > > ERROR:tm:t_forward_nonack: failure to add branches > > > > > > Following past reports that I've found with a similar error, > fix_nated_contact() is run on INVITE messages just before rtpengine flags > are set and the t_relay() command, but it doesn't appear to make any > difference. If I change the t_relay() to t_relay(0x04,) to disable DNS > Failover, I still see the same errors in the log file. I've also checked > the record in the OpenSIPS DB "location" table and it seems to me that it > has the correct contact_id and contact info for the destination... > > > > contact_id: 2004383309156582802 > > contact:sips:11001@4xp44jxl0qq0.invalid > ;rtcweb-breaker=yes;transport=wss > > > > I'm stuck on where I can go from here - any help very much appreciated! > > > > thx > > > > Mark > > > > > > Setup: > > OpenSIPS 3.0.2 on Debian Buster > > RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 > > > > INVITE: > > 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 > > INVITE sip:11001@192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 > > Via: SIP/2.0/UDP 192.168.50.185:5060 > ;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 > > From: "11002" >;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 > > To: > > Contact: > > Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 > > CSeq: 24456 INVITE > > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, > CANCEL, UPDATE, PRACK, MESSAGE, REFER > > Supported: 100rel, timer, replaces, norefersub > > Session-Expires: 1800 > > Min-SE: 90 > > P-Asserted-Identity: "11002" > > Max-Forwards: 70 > > User-Agent: FPBX-15.0.16.63(16.9.0) > > Content-Type: application/sdp > > Content-Length: 411 > > > > v=0 > > o=- 263255642 263255642 IN IP4 192.168.50.185 > > s=Asterisk > > c=IN IP4 192.168.50.185 > > t=0 0 > > m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 > > a=rtpmap:9 G722/8000 > > a=rtpmap:107 opus/48000/2 > > a=fmtp:107 useinbandfec=1 > > a=rtpmap:8
Re: [OpenSIPS-Users] Documentation error?
Hi Răzvan - thanks for that info. >From memory, I believe that I tried using the sample script and got errors so then went to see if I could find a version of the tutorial for 3.0. As for updating the wiki, I'm still finding my way around OpenSIPS and haven't got it working properly yet. However, once I'm up to speed, if I get a chance I'll suggest an update. Cheers, Mark On Fri, 17 Jul 2020 at 12:21, Răzvan Crainea wrote: > Hi, Mark! > > Actually that's just a dangling page, generated by our scripts for > "creating" a new version. Did you get to that page through a link or > something? As the Index page[1] doesn't reference it. > TBH we weren't planning of updating the tutorial, since nothing major > has changed, there are only some syntactic changes (according to my > analysis). I do agree an updated version would be better, but due to > lack of resources, this hasn't reached our priority list. > Nevertheless, that is a wiki page, and any contribution is more than > welcome. > > [1] https://www.opensips.org/Documentation/Tutorials#toc9 > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/16/20 4:03 PM, Mark Allen wrote: > > Not sure where to report this, so apologies if it's in the wrong place. > > > > The tutorial for Web Sockets with 3.0 looks to be wrong when running > > 3.0.2. Example script is full of obsolete commands, modules and > > variables - not very helpful. Will this be rectified on release of 3.1 > > Stable? > > > > https://opensips.org/Documentation/Tutorials-WebSocket-3-0 > > > > > > > > ___ > > 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] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri
Hi Alexey - thanks for responding.
I've seen past reports where NAT was causing this type of problem. I tried
your suggestion but, along with other tests such as forcing
fix_nated_register() or fix_nated_contact() on all messages, and after
trying Stas' suggestion, it still doesn't work for me. I believe that I've
followed the tutorials correctly but, as per another post of mine, there
are issues with the 3.0 tutorial scripts being out of date - so maybe the
problem lies somewhere in how I've tried to fix the script errors for 3.0.2?
It's very frustrating because I can look at the "location" table in MySQL
and see the information being correctly stored, it just appears that for
some reason when it looks up and retrieves the information it doesn't
recognise that the destination retrieved is a WebSocket and so tries to
treat it as a FQDN - or at least that's what it seems to be saying to me.
cheers,
Mark
On Fri, 17 Jul 2020 at 07:07, Alexey Vasilyev
wrote:
> Hi Mark,
>
> try this:
>
> if (nat_uac_test("123")) {
> if (is_method("REGISTER")) {
> fix_nated_register();
> } else {
> fix_nated_contact();
> }
> }
>
>
>
> -
> ---
> Alexey Vasilyev
> --
> Sent from:
> http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html
>
> ___
> 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] Documentation error?
Not sure where to report this, so apologies if it's in the wrong place. The tutorial for Web Sockets with 3.0 looks to be wrong when running 3.0.2. Example script is full of obsolete commands, modules and variables - not very helpful. Will this be rectified on release of 3.1 Stable? https://opensips.org/Documentation/Tutorials-WebSocket-3-0 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri
Thanks Stas - I'll have a look at that. For clarification, we only have one OpenSIPS server acting as mid-registrar. Endpoints register through it to extensions on Asterisk, and Asterisk acts as B2BUA for calls from one extension to another. We've got a lot of additional functionality linked to the Asterisk server so our main need for OpenSIPS is to reduce unnecessary load (e.g. re-REGISTER from mobile devices). On Tue, 14 Jul 2020 at 16:23, Stas Kobzar wrote: > Hello Mark, > > I had a similar challenge. Using "path" module on both opensips helps > to overcome this problem. > https://opensips.org/docs/modules/3.2.x/path.html > > In your mid-registerer you need to enable path support. See "save" > function params p0 and v. > in your webrtc opensips use path module and function add_path_received > > On Tue, Jul 14, 2020 at 11:14 AM Mark Allen wrote: > > > > I'm new to OpenSIPS and I've hit a problem I can't find a way past > > > > We have a test setup with an OpenSIPS mid-registrar in front of an > Asterisk PBX. Mid-registrar is currently in mode 1 (registration > throttling). We have SIP and WebRTC endpoints that we want to use. > > > > Current state is: > > > > REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> > Asterisk = success > > REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> > Asterisk = success > > > > INVITE:SIP softphone-> OpenSIPS -> Asterisk -> OpenSIPS -> SIP > softphone = success, call connects with audio both ways > > INVITE:WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP > softphone = success, call connects with audio both ways > > INVITE:SIP softphone-> OpenSIPS -> Asterisk -> OpenSIPS -> > WebRTC webphone = fails with "476 Unresolvable destination" > > > > syslog messages: > > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri > > CRITICAL:core:mk_proxy: could not resolve hostname: > "4xp44jxl0qq0.invalid" > > ERROR:tm:uri2proxy: bad host name in URI ;rtcweb-breaker=yes;transport=wss> > > ERROR:tm:t_forward_nonack: failure to add branches > > > > > > Following past reports that I've found with a similar error, > fix_nated_contact() is run on INVITE messages just before rtpengine flags > are set and the t_relay() command, but it doesn't appear to make any > difference. If I change the t_relay() to t_relay(0x04,) to disable DNS > Failover, I still see the same errors in the log file. I've also checked > the record in the OpenSIPS DB "location" table and it seems to me that it > has the correct contact_id and contact info for the destination... > > > > contact_id: 2004383309156582802 > > contact:sips:11001@4xp44jxl0qq0.invalid > ;rtcweb-breaker=yes;transport=wss > > > > I'm stuck on where I can go from here - any help very much appreciated! > > > > thx > > > > Mark > > > > > > Setup: > > OpenSIPS 3.0.2 on Debian Buster > > RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 > > > > INVITE: > > 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 > > INVITE sip:11001@192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 > > Via: SIP/2.0/UDP 192.168.50.185:5060 > ;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 > > From: "11002" >;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 > > To: > > Contact: > > Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 > > CSeq: 24456 INVITE > > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, > CANCEL, UPDATE, PRACK, MESSAGE, REFER > > Supported: 100rel, timer, replaces, norefersub > > Session-Expires: 1800 > > Min-SE: 90 > > P-Asserted-Identity: "11002" > > Max-Forwards: 70 > > User-Agent: FPBX-15.0.16.63(16.9.0) > > Content-Type: application/sdp > > Content-Length: 411 > > > > v=0 > > o=- 263255642 263255642 IN IP4 192.168.50.185 > > s=Asterisk > > c=IN IP4 192.168.50.185 > > t=0 0 > > m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 > > a=rtpmap:9 G722/8000 > > a=rtpmap:107 opus/48000/2 > > a=fmtp:107 useinbandfec=1 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:3 GSM/8000 > > a=rtpmap:111 G726-32/8000 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-16 > > a=ptime:20 > > a=maxptime:20 > > a=sendrecv > > a=rtcp-mux > > > > > > ___ > > 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
[OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri
I'm new to OpenSIPS and I've hit a problem I can't find a way past We have a test setup with an OpenSIPS mid-registrar in front of an Asterisk PBX. Mid-registrar is currently in mode 1 (registration throttling). We have SIP and WebRTC endpoints that we want to use. *Current state is:* REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> Asterisk = success REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> Asterisk = success INVITE:SIP softphone-> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways INVITE:WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways INVITE:SIP softphone-> OpenSIPS -> Asterisk -> OpenSIPS -> WebRTC webphone = *fails with "**476 Unresolvable destination"* *syslog messages:* ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid" ERROR:tm:uri2proxy: bad host name in URI ERROR:tm:t_forward_nonack: failure to add branches Following past reports that I've found with a similar error, *fix_nated_contact()* is run on INVITE messages just before rtpengine flags are set and the *t_relay()* command, but it doesn't appear to make any difference. If I change the *t_relay()* to *t_relay(0x04,)* to disable DNS Failover, I still see the same errors in the log file. I've also checked the record in the OpenSIPS DB "location" table and it seems to me that it has the correct *contact_id* and *contact* info for the destination... contact_id: 2004383309156582802 contact:sips:11001@4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss I'm stuck on where I can go from here - any help very much appreciated! thx Mark *Setup: * OpenSIPS 3.0.2 on Debian Buster RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 *INVITE*: 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 INVITE sip:11001@192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 Via: SIP/2.0/UDP 192.168.50.185:5060 ;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 From: "11002" ;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 To: Contact: Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 CSeq: 24456 INVITE Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 P-Asserted-Identity: "11002" Max-Forwards: 70 User-Agent: FPBX-15.0.16.63(16.9.0) Content-Type: application/sdp Content-Length: 411 v=0 o=- 263255642 263255642 IN IP4 192.168.50.185 s=Asterisk c=IN IP4 192.168.50.185 t=0 0 m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 a=rtpmap:9 G722/8000 a=rtpmap:107 opus/48000/2 a=fmtp:107 useinbandfec=1 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:111 G726-32/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:20 a=sendrecv a=rtcp-mux ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
