Can I also do this from the failure route? I noticed that it is not
properly showing the carrier ID where the call really went to, on our CDRs
right now it shows it went to carrier C, but when checking our carrier CDRs
the call went to carrier A,
On Fri, Jul 3, 2020 at 4:00 PM Răzvan Crainea
I see, Mark. It is true, in my case, I splitted webrtc to other
opensips (newer version) as our platform was too old.
I still think path module function should help:
https://opensips.org/docs/modules/3.1.x/path.html#func_add_path_received
Good luck
On Tue, Jul 14, 2020 at 11:48 AM Mark Allen
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
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
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:
Hi
I'm testing re-invites from a freeswitch server with this scenario:
client1,client2 <=> opensips (rtpproxy) <=> freeswitch
[image: arch.jpg]
freeswitch is used to announce some mid call sound file. At start
freeswitch is not in the rtp path and rtp goes through rtpproxy to clients.
After 7
