Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine

[Robert Dyck]

As mentioned in one of my previous notes I use via-branch=extra and set the 
avp to $T_branch_idx. That solved my problem. I had doubts about sequential 
INVITEs because the index would always be 0 and the call may have been 
establihed with a different index. My testing with rtpenigine debug logs showed 
that after the totag gets installed by the initial answer, via-branch is 
ignored. So no problem.

My concern now is with the documentation. via-branch=1 or 2 for answer do 
nothing for forked calls. Omitting via-branch accomplishes the same thing.
Because with via-branch=1 the result is identical for each branch, rtpengine 
just overwrites whatever flags it has already received.

In the documentation the bit about via-branch could be eliminated and opensips 
could arbitrarily set it to the branch index. It would work whether the call 
forked or not. If we actually wanted the via branch that opensips sends 
downstream we would need some mechanism that made it available to the script. 
The branch index is enough however so it's not worth the bother.
In general, opensips has no interest in a transaction ID from an upstream 
node. It is only of interest to that node.

On Friday, February 4, 2022 3:06:40 A.M. PST Răzvan Crainea wrote:
> Hi, Robert!
> 
> For a request, VIA 1 is always the previous hop - therefore, if you want
> to have different offer messages, you need to use something else - my
> proposal is to use the via-branch=3 and set the extra_avp to
> $T_branch_idx. You can do the same thing for replies, and that should
> cover all cases.
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 1/27/22 19:23, Robert Dyck wrote:
> > 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,
> >> 
> >> 
> >> ___
> >> 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] mid_registrar TLS

[Alberto]

Hi,
I have a sip client connecting to opensips using tls, all requests are then
routed to an asterisk server using mid_registrar.

UDP to UDP and TCP to TCP work fine, but TLS doesn't.

This is the error, but I'm having a hard time understanding it.

Feb  4 12:29:32 [3406] //etc/opensips/opensips.cfg:453 Forward REGISTER for
sip:tls-1001@10.0.0.252:5061 to 10.0.0.153:5061;transport=tls
Feb  4 12:29:32 [3406] ERROR:proto_tls:proto_tls_conn_init: no TLS client
domain found
Feb  4 12:29:32 [3406] ERROR:core:tcp_conn_create: failed to do proto 3
specific init for conn 0x7ff9be1810f8
Feb  4 12:29:32 [3406] ERROR:core:tcp_async_connect: tcp_conn_create
failed, closing the socket
Feb  4 12:29:32 [3406] ERROR:proto_tls:proto_tls_send: async TCP connect
failed
Feb  4 12:29:32 [3406] ERROR:tm:msg_send: send() to 10.0.0.153:5061 for
proto tls/3 failed
Feb  4 12:29:32 [3406] ERROR:tm:t_forward_nonack: sending request failed
Feb  4 12:29:32 [3406] ERROR:tm:w_t_relay: t_forward_nonack failed


My configuration:
#
loadmodule "mid_registrar.so"
modparam("mid_registrar", "attr_avp", "$avp(avp_json)")
modparam("mid_registrar", "max_contacts", 1)
modparam("mid_registrar", "mode", 0)
modparam("mid_registrar", "tcp_persistent_flag",
"TCP_PERSIST_REGISTRATIONS")

loadmodule "tls_mgm.so"
modparam("tls_mgm", "tls_library", "wolfssl")
modparam("tls_mgm", "server_domain", "dom1")
modparam("tls_mgm", "ca_list", "[dom1]/etc/letsencrypt/fullchain.pem")
modparam("tls_mgm", "certificate", "[dom1]/etc/letsencrypt/cert.pem")
modparam("tls_mgm", "private_key", "[dom1]/etc/letsencrypt/privkey.pem")
modparam("tls_mgm", "require_cert", "[dom1]0")
modparam("tls_mgm", "tls_method", "[dom1]TLSv1-")
modparam("tls_mgm", "verify_cert", "[dom1]0")

loadmodule "proto_tls.so"

###
$ru = "sip:10.0.0.153:5061;transport=tls";
setflag("TCP_PERSISTENT");
route(relay);


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

Re: [OpenSIPS-Users] Incorrect r-uri in final ACK

[Sergey Pisanko]

Hi, Bogdan.

I applied the modules you adviced and it really solved my issue.

Thanks a lot!

Best Regards!

[image: Mailtrack]

Sender
notified by
Mailtrack

02/04/22,
02:15:23 PM

пт, 28 янв. 2022 г. в 15:23, Bogdan-Andrei Iancu :

> Hi Sergey,
>
> I would strongly suggest to use dialog module + topo hiding  to get rid of
> this problem.
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS eBootcamp
>   https://www.opensips.org/Training/Bootcamp
>
> On 1/28/22 2:24 PM, Sergey Pisanko wrote:
>
>
> Hello.
>
> I have an issue with incorrect final ACK message from pbx which
> communicates to opensips. PBX sents to opensips proxy's r-uri instead of
> UA's one, though it receives correct callee's contact value in previous 200
> OK. The PBX seems to have a problem with SIP protocol realization and I
> would like to solve this issue on Opensips side rewriting r-uri with
> correct one. What is the best way to do this? As long as what comes to my
> mind is to use avpops module with it's function "avp_db_query" in order to
> get the UA's contact from database and store it to avp and then to pass
> this avp as a r-uri. But may be there is a better solution? And are the
> similar manipulations bad practic carrying potential risks?
>
> Best Regards,
> Sergey Pysanko.
>
>
> [image: Mailtrack]
> 
>  Sender
> notified by
> Mailtrack
> 
>  01/28/22,
> 02:22:52 PM
>
> ___
> 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] Trouble with forked calls and rtpengine

[Răzvan Crainea]

Hi, Robert!

For a request, VIA 1 is always the previous hop - therefore, if you want 
to have different offer messages, you need to use something else - my 
proposal is to use the via-branch=3 and set the extra_avp to 
$T_branch_idx. You can do the same thing for replies, and that should 
cover all cases.


Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 1/27/22 19:23, Robert Dyck wrote:

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,


___
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