[OpenSIPS-Users] WebRTC and mid_registrar issue
Liviu Chircu
liviu at opensips.org
Mon Apr 22 02:10:54 EDT 2019
Hi Terry,
Currently, mid-registrar is incompatible with topology hiding, as they
both attempt to edit the "Contact" header field.
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 09.04.2019 14:01, Terry Walters wrote:
> I have a working OpenSIPS deployment running as a PSTN proxy and am
> trying to add in support for WebRTC which will forward requests to an
> internal SIP PBX. Currently the registrations appear to be passing
> through the mid_registrar correctly and the initial invite from my PBX
> is correctly routed to the websocket client.
>
> The PBX receives messages up to the 180 ringing correctly, but on the
> 200 OK from the websocket client the r.uri contains a d.id rather than
> the ctid, this then results in the calling timing out and the ACK from
> the PBX not routing to the websocket client. I believe this is the
> script area that is falling over once the has_totag function is checked.
>
> if (loose_route())
> {
> if (is_method("INVITE"))
> {
> # even if in most of the cases is useless, do RR for
> # re-INVITEs alos, as some buggy clients do change route set
> # during the dialog.
> record_route();
> }
> else if (is_method("ACK"))
> {
> if (has_body("application/sdp"))
> {
> # check if destination is WS
> if ($du != NULL)
> $var(proto) = $dP;
> else
> $var(proto) = $rP;
> if ($var(proto) == "WS" || $var(proto) == "WSS")
> setbflag(DST_WS);
>
> route(rtpengine_answer);
> }
> }
>
> # route it out to whatever destination was set by loose_route()
> # in $du (destination URI).
> route(websocket);
> }
> else
> {
> if ( is_method("ACK") )
> {
> if ( t_check_trans() )
> {
> # non loose-route, but stateful ACK; must be an ACK after
> # a 487 or e.g. 404 from upstream server
> t_relay();
> exit;
> }
> else
> {
> # ACK without matching transaction ->
> # ignore and discard
> exit;
> }
> }
> sl_send_reply("404","Not here");
>
> The route[websocket] is using force send socket to remove the NAT
> address that cannot be accessed internally:
>
> route[webscoket]
> {
> xlog("L_INFO","Entered websocket route");
> # for each branch we will call the function below
> t_on_branch("per_branch_ops");
>
> # for each reply we will call the function below
> t_on_reply("handle_nat");
> # initial invites from the main registrar - need to look them up!
> if (is_method("INVITE"))
> if($Ri == "1.1.1.1" and $Rp == 5070)
> {
> xlog("L_INFO","Call received for a websocket client");
> if (!mid_registrar_lookup("location"))
> {
> t_reply("404", "Not Found");
> exit;
> }
>
> }
> else if($Ri=="1.1.1.1" && $Rp == "8080")
> {
> xlog("L_INFO","Inbound call received on port 8080");
> route("ToInternal");
> t_on_failure("int_invites");
> }
>
> if((is_method("REGISTER"))&&($Ri=="1.1.1.1")&&($Rp =="8080"))
> {
> xlog("L_INFO","Register received - mid-registrar actions");
> fix_nated_register();
> mid_registrar_save("location");
> switch ($retcode)
> {
> case 1:
> xlog("L_INFO", "forwarding REGISTER to main registrar...\n");
> $ru = "sip:2.2.2.2:5060";
> force_send_socket(UDP:1.1.1.1:5070);
> if (!t_relay()) {
> send_reply("500", "Server Internal Error 1");
> }
> t_on_failure("int_invites");
> break;
> case 2:
> xlog("L_INFO", "REGISTER has been absorbed!\n");
> break;
> default:
> xlog("L_ERR", "mid-registrar error!\n");
> send_reply("500", "Server Internal Error 2");
> }
>
> exit;
> }
>
> # removing the rtpproxy session
> if(is_method("CANCEL|BYE"))
> {
> rtpengine_delete();
> }
>
> # try to send the request on its way, if it fails send back a
> # stateless error to the requestor
> if (t_relay())
> {
> xlog("L_INFO", "$ci|pass|$rd:$rp");
> }
> else
> {
> xlog("L_ERR", "$ci|end|unable to relay message");
>
> sl_reply_error();
> }
>
>
> }
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20190422/37488446/attachment.html>
More information about the Users
mailing list