Re: [OpenSIPS-Users] is it OK to mix 3.1.7 and 3.2.4 in the same cluster?
Hi, I would definitely not advise this. There may be differences in the BIN proto or on how the modules are packing data for replication. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp https://www.opensips.org/Training/Bootcamp On 1/27/22 5:05 PM, Kingsley Tart wrote: Hi, I have a 4 node cluster running OpenSIPS 3.1.7. Is it OK to upgrade one node to 3.2.4 for a while for soak testing while leaving the others at 3.1.7? Cheers, Kingsley. ___ 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-cli and reload_routes : Permission denied
Hi Alain,
Maybe you are missing the `x` permission on one of the directories in
the path to the file.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS eBootcamp
https://www.opensips.org/Training/Bootcamp
On 1/27/22 6:39 PM, Alain Bieuzent wrote:
Hi all,
I have a problem with the possibility of reloading routes live with
opensips-cli :
root@lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in
opensips-cli -x mi version
{
"Server": "OpenSIPS (3.2.4 (x86_64/linux))"
}
root@lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in
opensips-cli -x mi reload_routes
ERROR: command 'reload_routes' returned: 500: reload failed
Logs say :
Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]:
ERROR:core:parse_opensips_cfg: loading config file
/usr/local//etc/opensips/opensips.cfg: Permission denied
Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]:
ERROR:core:reload_routing_script: parsing failed, abording
Right of /usr/local//etc/opensips/opensips.cfg
root@lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in ll
/usr/local//etc/opensips/opensips.cfg
-rw-r--r-- 1 root staff 80329 Jan 27 11:14
/usr/local//etc/opensips/opensips.cfg
Does anyone have an idea how to solve this problem of access rights?
Thanks
Alain
___
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] Audio problem because of "to-tag" changes during the call
Hi, I'm new to the community. I search to solve some audio problem (one way) with my provider. I suspect it is related to the changement of the "to-tag" between the SIP 183 session progress and the SIP 200 OK. I think the "to-tag" change make the rtpengine use a new RTP src port, this make my provider drop this flow :'( -->the source port is different than what has been announce in the SDP invite I send to him. Here an extract of what I suspect to be my problem : janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: Final packet stats: janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: --- Tag 'as32bd80f6', created 0:46 ago for branch '', in dialogue with 'SDr6vf398-MVIsCA' janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: -- Media #1 (audio over RTP/AVP) using PCMA/8000 janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: - PortX.Y.Z.B:5000 <> X.Y.Z.A :11636, SSRC 143ba6ae, 142 p, 24424 b, 0 e, 30 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: - PortX.Y.Z.B:5001 <> X.Y.Z.A :11637 (RTCP), SSRC 143ba6ae, 3 p, 152 b, 0 e, 30 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: --- Tag 'SDr6vf398-B7CIvQ', created 0:46 ago for branch '', in dialogue with 'as32bd80f6' janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: -- Media #1 (audio over RTP/AVP) using PCMA/8000 janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: - PortX.Y.Z.C:5000 <> X.Y.Z.D:33800, SSRC 326b3c5a, 778 p, 133816 b, 0 e, 30 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: - PortX.Y.Z.C:5001 <> X.Y.Z.D:33801 (RTCP), SSRC 326b3c5a, 1 p, 52 b, 0 e, 30 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: --- Tag 'SDr6vf398-MVIsCA', created 0:33 ago for branch '', in dialogue with 'as32bd80f6' janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: -- Media #1 (audio over RTP/AVP) using unknown codec janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: - PortX.Y.Z.C:5014 <> X.Y.Z.D:33800, SSRC 0, 0 p, 0 b, 0 e, 33 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638@X.Y.Z.A ]: - PortX.Y.Z.C:5015 <> X.Y.Z.D:33801 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 33 ts Does the option 'via-branch=auto' for the rtpengine_offer can help me to solve this issue ? What are the impact to do so ? Regards, Florent ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Opensips adds its via ( with branch info ) after script processing but before forwarding. Opensips branch info is not available to the script when processing an INVITE. I have attached some text of an INVITE with rtpengine and with "offer via-branch=1". What rtpengine receives is the branch parameter added by the upstream node. The upstream node has no knowledge of any forking that may occur after lookup. The branch parameter is a legacy of rfc2543. That rfc stated that a forking proxy would add branch info in a via parameter called branch. This parameter could be added by any hop but is ignored. It was only meaningful in a response received by the forking proxy. Rfc3261 retained the via parameter name, I assume for compatibility. Rfc3261 was clear however that "branch" was now a transaction ID. This is only of interest to the node that added it in a request. Now in the case of a forking proxy the branch parameter has the dual role of being a transaction ID and a branch ID. Opensips does this by adding the branch index as a suffix to the transaction ID. The opensips script may not have access to the eventual transaction ID but the branch index is available. Passing the branch index to rtpengine causes it to create a different profile for each branch rather than stacking the profiles. That stacking was causing trouble for me. When rtpengine is simply providing a public address to relay media the stacking does not appear to have any consequence. However when mixing WEBRTC and non-WEBRTC stacking the profiles in a single entry in rtpengine gives inconsistent results. On Thursday, January 27, 2022 3:57:07 A.M. PST Răzvan Crainea wrote: > Hi, Robert! > > Are you sure that via-branch=2 does not set different branches, and sets > the same param as via-branch=1? > If you are going to use the extra_id_pv, you should make sure that you > persist it over dialog, i.e. also provide it during sequential > offer/answer/delete commands. > > Best regards, > INVITE sip:2@192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.87:38268;branch=z9hG4bK24749ef66a21e2fd;rport Contact: Max-Forwards: 70 Proxy-Authorization: Digest username="4", realm="192.168.1.2", nonce="jzLa4gxOll83BD3v0WKZclEjjHyaJpxfmIWTVMw8WXcA", uri="sip:2@192.168.1.2", response="697304535675ddab4c8fec180eef338a", cnonce="fe5ab4853d24b69e", qop=auth, nc=0001, algorithm=MD5 To: From: ;tag=a331187bbb05d5eb Call-ID: 2a211cae7d8a4ec3 CSeq: 56918 INVITE User-Agent: baresip v1.1.0 (x86_64/linux) Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER Supported: gruu Content-Type: application/sdp Content-Length: 433 xlog Jan 27 08:24:27 [2683481] Invite with first via host 192.168.1.87 and branch ID z9hG4bK24749ef66a21e2fd xlog Jan 27 08:24:27 [2683481] profile is debug via-branch=1 SDES-off ICE=force UDP/TLS/RTP/SAVPF replace-session-connection replace-origin DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid >From rtpengine log Jan 27 08:24:27 slim rtpengine[1623448]: DEBUG: [2a211cae7d8a4ec3]: ... : "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv6" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "2a211cae7d8a4ec3", "via-branch": "z9hG4bK24749ef66a21e2fd", "received-from": [ "IP4", "192.168.1.87" ], "from-tag": "a331187bbb05d5eb", "command": "offer" } ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] opensips-cli and reload_routes : Permission denied
Hi all,
I have a problem with the possibility of reloading routes live with
opensips-cli :
root@lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in opensips-cli -x mi
version
{
"Server": "OpenSIPS (3.2.4 (x86_64/linux))"
}
root@lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in opensips-cli -x mi
reload_routes
ERROR: command 'reload_routes' returned: 500: reload failed
Logs say :
Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]: ERROR:core:parse_opensips_cfg:
loading config file /usr/local//etc/opensips/opensips.cfg: Permission denied
Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]:
ERROR:core:reload_routing_script: parsing failed, abording
Right of /usr/local//etc/opensips/opensips.cfg
root@lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in ll
/usr/local//etc/opensips/opensips.cfg
-rw-r--r-- 1 root staff 80329 Jan 27 11:14 /usr/local//etc/opensips/opensips.cfg
Does anyone have an idea how to solve this problem of access rights?
Thanks
Alain
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] is it OK to mix 3.1.7 and 3.2.4 in the same cluster?
Hi, I have a 4 node cluster running OpenSIPS 3.1.7. Is it OK to upgrade one node to 3.2.4 for a while for soak testing while leaving the others at 3.1.7? Cheers, Kingsley. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Hi, Robert! Are you sure that via-branch=2 does not set different branches, and sets the same param as via-branch=1? If you are going to use the extra_id_pv, you should make sure that you persist it over dialog, i.e. also provide it during sequential offer/answer/delete commands. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/7/22 23:06, Robert Dyck wrote: Further more via-branch=2 on answer gives us the upstream via again and not ours. On Friday, January 7, 2022 12:19:40 A.M. PST Bogdan-Andrei Iancu wrote: Hi Robert, Are you doing parallel forking, right ? and keep in mind that via-branch (after forking) is unique and consistent "per branch", so you can rely on that. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/6/22 8:57 PM, Robert Dyck wrote: I am reaching out to the users out there to help me figure out why I get occasional call failures when it involves rtpengine and forked calls. Calls involving rtpengine but not forked are solid. For instance there is no problem with a call between a SIPified WEBRTC phone and some end of life device. WEBRTC has very strict requirements. ICE, DTLS and rtcmux are mandatory. These are unknown to some devices. I narrowed it down to forked calls. The documentation seems to suggest there are options for the offer command to deal with branches. Specifically the via- branch= variants. The auto option is mentioned in the documentation but it doesn't seem to be implemented in opensips. Then there is the 1 option for offers and the 2 option for answers. The 1/2 option did not help. Looking a little closer at what it does, I can't see how it could have helped anyway. The branch parameter in the via header is not unique for the different branches. We have multiple callees but only one caller. Diving deeper a look at the rtpengine debug logs only confirmed my doubt about the usefulness of via branch parameter. Here is an example of a three way fork. First offer "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: [core] Creating new call Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] creating new monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with 'as1g4gcnjp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] create new "other side" monologue for viabranch z9hG4bK3119290 Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] creating new monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with viabranch 'z9hG4bK3119290' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp Second offer "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] found existing monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp Third offer "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] found existing monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25
