Re: [OpenSIPS-Users] Message buffer formatting
I spoke too soon. When I run opensips in debug mode on the terminal the formatting looks good. If I monitor the log facility the $mb dump is not formatted. Perhaps this is normal? On Tuesday, April 9, 2024 11:47:05 P.M. PDT Bogdan-Andrei Iancu wrote: > There is no formatting added, maybe the diff comes for the actual > logging. What are the 2 versions you tested ? > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >https://www.opensips-solutions.com >https://www.siphub.com > > On 10.04.2024 00:21, Robert Dyck wrote: > > In the past I would insert xlog with $mb into my script for debugging > > purposes. Now I find that the message buffer output is not being > > formatted. > > > > > > Instead of > > > > > > Message Buffer > > > > REGISTER sip:192.168.1.2 SIP/2.0 > > > > Via: SIP/2.0/UDP > > 192.168.1.4:5070;branch=z9hG4bKce021e1d6a292d1504d0ff89e60c9ba;rport > > > > > > I get > > > > > > Message Buffer#012 REGISTER sip:192.168.1.2 SIP/2.0#015#012Via: > > SIP/2.0/UDP 192.168.1.4:5070;branch=z > > 9hG4bKce021e1d6a292d1504d0ff89e60c9ba;rport#015#012 > > > > > > Instead of LF I get #012 > > > > Instead of CR I get #015 > > > > > > What may have caused this change and how can I restore the old behaviour? > > > > > > ___ > > 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] Message buffer formatting
I had been running 3.4. I fired up 3.3. Had to modify the config because syslog syntax had changed. $mb worked as expected. I went back to 3.4. I got notices about the log stuff being deprecated so I went back to the new syntax. Now $mb works as expected on 3.4. I have concluded that something about the original 3.4 config was messed up. All good now. On Tuesday, April 9, 2024 11:47:05 P.M. PDT Bogdan-Andrei Iancu wrote: > There is no formatting added, maybe the diff comes for the actual > logging. What are the 2 versions you tested ? > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >https://www.opensips-solutions.com >https://www.siphub.com > > On 10.04.2024 00:21, Robert Dyck wrote: > > In the past I would insert xlog with $mb into my script for debugging > > purposes. Now I find that the message buffer output is not being > > formatted. > > > > > > Instead of > > > > > > Message Buffer > > > > REGISTER sip:192.168.1.2 SIP/2.0 > > > > Via: SIP/2.0/UDP > > 192.168.1.4:5070;branch=z9hG4bKce021e1d6a292d1504d0ff89e60c9ba;rport > > > > > > I get > > > > > > Message Buffer#012 REGISTER sip:192.168.1.2 SIP/2.0#015#012Via: > > SIP/2.0/UDP 192.168.1.4:5070;branch=z > > 9hG4bKce021e1d6a292d1504d0ff89e60c9ba;rport#015#012 > > > > > > Instead of LF I get #012 > > > > Instead of CR I get #015 > > > > > > What may have caused this change and how can I restore the old behaviour? > > > > > > ___ > > 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] Message buffer formatting
In the past I would insert xlog with $mb into my script for debugging purposes. Now I find that the message buffer output is not being formatted. Instead of Message Buffer REGISTER sip:192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.4:5070;branch=z9hG4bKce021e1d6a292d1504d0ff89e60c9ba;rport I get Message Buffer#012 REGISTER sip:192.168.1.2 SIP/2.0#015#012Via: SIP/2.0/UDP 192.168.1.4:5070;branch=z 9hG4bKce021e1d6a292d1504d0ff89e60c9ba;rport#015#012 Instead of LF I get #012 Instead of CR I get #015 What may have caused this change and how can I restore the old behaviour? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Question about rls_presentity table
I was too hasty. The subscriber has a long expiry on it's subscribe ( 1 hr ) and it is not configurable. The entry was eventually deleted. Currently using opensips-3.4.3. I am experimenting with using resource lists for presence. I have a question about table rls_presentity. When a UA subscribes to a presentity using an entry in a resource list an entry is created in the DB table rls_presentity. When the presentity sends publish its state is added to the entry in rls_presentity. What I find peculiar, there seems to be no way for opensips to delete the entry. If both the watcher/subscriber and the presentity are offline the entry in the table remains. Only the state is removed. Is this intended behaviout? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Question about rls_presentity table
Currently using opensips-3.4.3. I am experimenting with using resource lists for presence. I have a question about table rls_presentity. When a UA subscribes to a presentity using an entry in a resource list an entry is created in the DB table rls_presentity. When the presentity sends publish its state is added to the entry in rls_presentity. What I find peculiar, there seems to be no way for opensips to delete the entry. If both the watcher/subscriber and the presentity are offline the entry in the table remains. Only the state is removed. Is this intended behaviout? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Debug logs show To tag which are actually From tag
While running opensips in debug mode I noticed that for initial requests of dialog creating methods the debug logs were showing a To tag where none actually exists. The tag displayed was actually the From tag. INVITE sip:8@192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.k7nLoQHpR;rport From: ;*tag=GSq6JzXiH * To: sip:8@192.168.1.2 CSeq: 21 INVITE Call-ID: VCALnmUf8V Nov 23 11:02:32 [1131200] DBG:maxfwd:is_maxfwd_present: value = 70 Nov 23 11:02:32 [1131200] *DBG:sipmsgops:has_totag: no totag * Nov 23 11:02:32 [1131200] Initial request, method is INVITE, URI is sip:8@192.168.1.2 Nov 23 11:02:32 [1131200] DBG:core:check_self: host != me Nov 23 11:02:32 [1131200] DBG:core:parse_headers: flags=78 Nov 23 11:02:32 [1131200] DBG:tm:t_lookup_request: start searching: hash=42361, isACK=0 Nov 23 11:02:32 [1131200] DBG:tm:matching_3261: RFC3261 transaction matching failed Nov 23 11:02:32 [1131200] DBG:tm:t_lookup_request: no transaction found Nov 23 11:02:32 [1131200] *DBG:core:parse_to_param: tag=GSq6JzXiH * Nov 23 11:02:32 [1131200] DBG:core:parse_to_param: end of header reached, state=11 PUBLISH sip:7@192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.myBdBZt3P;rport From: ;*tag=cbp~iz4fq* To: sip:7@192.168.1.2 CSeq: 21 PUBLISH Call-ID: cRC6Gw590w Max-Forwards: 70 Nov 23 11:07:08 [1133909] DBG:maxfwd:is_maxfwd_present: value = 70 Nov 23 11:07:08 [1133909] *DBG:sipmsgops:has_totag: no totag* Nov 23 11:07:08 [1133909] Initial request, method is PUBLISH, URI is sip:7@192.168.1.2 Nov 23 11:07:08 [1133909] DBG:core:check_self: host != me Nov 23 11:07:08 [1133909] DBG:core:parse_headers: flags=78 Nov 23 11:07:08 [1133909] DBG:tm:t_lookup_request: start searching: hash=7222, isACK=0 Nov 23 11:07:08 [1133909] DBG:tm:matching_3261: RFC3261 transaction matching failed Nov 23 11:07:08 [1133909] DBG:tm:t_lookup_request: no transaction found Nov 23 11:07:08 [1133909] *DBG:core:parse_to_param: tag=cbp~iz4fq* Nov 23 11:07:08 [1133909] DBG:core:parse_to_param: end of header reached, state=11 SUBSCRIBE sip:rls@192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.OkkDHBafu;rport From: ;*tag=g2aNdkn4o * To: sips:rls@192.168.1.2 CSeq: 21 SUBSCRIBE Call-ID: L9LKmnZVY7 Max-Forwards: 69 Nov 23 11:07:07 [1133909] DBG:maxfwd:is_maxfwd_present: value = 70 Nov 23 11:07:07 [1133909] *DBG:sipmsgops:has_totag: no totag* Nov 23 11:07:07 [1133909] Initial request, method is SUBSCRIBE, URI is sip:rls@192.168.1.2 Nov 23 11:07:07 [1133909] DBG:core:check_self: host != me Nov 23 11:07:07 [1133909] DBG:core:parse_headers: flags=78 Nov 23 11:07:07 [1133909] DBG:tm:t_lookup_request: start searching: hash=33557, isACK=0 Nov 23 11:07:07 [1133909] DBG:tm:matching_3261: RFC3261 transaction matching failed Nov 23 11:07:07 [1133909] DBG:tm:t_lookup_request: no transaction found Nov 23 11:07:07 [1133909] *DBG:core:parse_to_param: tag=g2aNdkn4o * Nov 23 11:07:07 [1133909] DBG:core:parse_to_param: end of header reached, state=1 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Learning about resource lists
Is the RLS tutorial valid? Do we know that there are working examples? On Wednesday, November 22, 2023 4:01:30 A.M. PST Adrian Georgescu wrote: > Hi Bogdan, > > My two cents. The reality is that adoption of XCAP is practically zero. Even > if you build a client, you cannot make it interoperable with another, and > XCAP was suppose to be interoperable. If I build a buddy list on one client > and I cannot load it in another client, it makes no sense. > > I think that anyone building a SIP app that needs to store/fetch data on the > SIP server can better do it using PUT/GET with a JSON, for example we took > this path for Sylk client rather than implementing XCAP again. This is not > interoperable between different clients, but there is no replacement > standard for XCAP either and is much cheaper and more reliable to do it > like this. > > As far as OpenSIPS is concerned one can probably make a new module or > better, modify that existing RLS module so that it can read contacts > directly from a database table with a schema that can be defined by the > user. In the end what one needs is a list of URIs and a flag to see who is > granted to see your presence, is a very simple database model. > > — > Adrian > > > On 22 Nov 2023, at 07:02, Bogdan-Andrei Iancu wrote: > > > > HI Adrian, > > > > should we understand the everything related to xcap, like RLS, buddy list, > > auth, etc are dropped dead at this time? if so, are you aware of any > > replacement / alternatives here ? > > > > Thanks and regards, > > > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > > > https://www.opensips-solutions.com <https://www.opensips-solutions.com/> > > https://www.siphub.com <https://www.siphub.com/> > > > > On 11/20/23 11:11 PM, Adrian Georgescu wrote: > >> XCAP is a failure. Not that we did not try, it was a bad idea and it > >> failed. > >> > >> — > >> Adrian > >> > >>> On 20 Nov 2023, at 14:27, Robert Dyck > >>> <mailto:rob.d...@telus.net> wrote: > >>> > >>> The context here is subscription to presence by way of a resource list. > >>> The learning curve is steep. I have read the tutorial. The tutorial > >>> gives an example of a rls-service xml document. In the example the > >>> resource list is contained within the services document. Various other > >>> examples I have found use a separate document to hold the list. The > >>> services document then references the list document. > >>> > >>> https://xcap.example.com/xcap-root/resource-lists/users/s > >>> ip:al...@example.com/index/~~/resource-lists/list%5b@name=%22l1%22%5d >>> esource-list> If I use an integrated server the xml documents reside in > >>> a local database rather than the file system. Http isn't going to work. > >>> How would one reference the database and table using rls-services > >>> document? Or is a separate resource-lists document not supported when > >>> using an integrated rls server? > >>> ___ > >>> Users mailing list > >>> Users@lists.opensips.org <mailto:Users@lists.opensips.org> > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> ___ > >> Users mailing list > >> Users@lists.opensips.org <mailto: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] Learning about resource lists
The context here is subscription to presence by way of a resource list. The learning curve is steep. I have read the tutorial. The tutorial gives an example of a rls-service xml document. In the example the resource list is contained within the services document. Various other examples I have found use a separate document to hold the list. The services document then references the list document. *https://xcap.example.com/xcap-root/resource-lists/users*/ sip:al...@example.com/index/~~/resource-lists/list%5b@name=%22l1%22%5d If I use an integrated server the xml documents reside in a local database rather than the file system. Http isn't going to work. How would one reference the database and table using rls-services document? Or is a separate resource-lists document not supported when using an integrated rls server? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] invalid contact wss
I forgot to mention that nat_uac_test should use at least flag 2. This insures that usrloc contains "Received". On Thursday, January 19, 2023 10:27:47 A.M. PST nutxase via Users wrote: > Hi guys > > So i notice when i register a WSS client to opensips the contact shows > something like Contact": "sip:62dntqm1@rwtjcrhyne3j.invalid;transport=wss", > > which causes inbound calls to not route and show 476 unresolvable > destination. > > any tips of where to look here? > > Sent with [Proton Mail](https://proton.me/) secure email. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] invalid contact wss
Do you have opensips-cli setup? If so, do "mi ul_dump". Look for your "invalid" contact. Your should have a line like "Received": "sip:1.2.3.4:60310;transport=wss", The IP address should be routable. On Thursday, January 19, 2023 10:27:47 A.M. PST nutxase via Users wrote: > Hi guys > > So i notice when i register a WSS client to opensips the contact shows > something like Contact": "sip:62dntqm1@rwtjcrhyne3j.invalid;transport=wss", > > which causes inbound calls to not route and show 476 unresolvable > destination. > > any tips of where to look here? > > Sent with [Proton Mail](https://proton.me/) secure email. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] can several SIP phones with same SIP account ring together and hang up asynchronous
This is a Linphone problem. A simple UA has no way of knowing that all the other UAs are unable to take the call. The Linphone developers should be encouraged to change the default response to a rejected call. Perhaps a universal reject could be an option but not the default. On Tuesday, October 25, 2022 1:28:48 A.M. PDT cheny via Users wrote: > Hi Bogdan-Andrei,thanks for your reply. I had set up a opensips service on > my Ubuntu 18.04.6 , and opensips version: opensips 3.2.6 (x86_64/linux). > When I test that case, I use two desktop linphone login same sip accout > 01010101 (callee A/B). and I use my Android linphone(caller C) invite A/B, > A/B rings together which works well. but I hang up the callee A , B also > terminated . I use wireshark to capture the packet on server side. it > show that : 1. when callee A(192.168.2.123) hand up, it respond 603 to the > server(192.168.2.108) 2. server(192.168.2.108) forwards the respond 603 to > caller C(192.168.2.115) 3. server(192.168.2.108) create a CANCEL to callee > B(192.168.2.127) so, it seems opensips server CANCEL B automatically. My > project need to meet the ability that callee A declines but callee B still > ring. I am a newbia to opensips, I don't know what is going on . How to > enable the ability as you say? Best Regards, > > > Chen ___ 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
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] rtp_relay module documentation
I am interested in trying the rtp_relay module but the documentation about the $rtp_relay pseudo-variable seems sparse. This variable can become quite complex with several components some of which have sub-components. In particular the flags, peer and delete components could have several parts. What delimiters are used and where does one use them? Some complex examples would be useful. That goes for the documentation as well. I questions also about the $rtp_relay_peer variable. It is not clear to me when it should be used. Does it take the place of the peer component in $rtp_relay? I am looking forward to trying this. Thank you, Rob ___ 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
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
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]: > > [internal
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
We need a preview of the downstream via which would be unique per branch. 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]: > > [internal
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Yes parallel forking. The via-branch downstream is unique but via-branch=1 gets the upstream branch parameter. That would be the caller or perhaps an outgoing proxy. via- branch=2 would be empty. The via is added just before relaying downstream. The debug logs from rtpengine show that the via-branch parameters for each branch is identical. Furthermore when rtpengine gets further branches it says "found existing monologue". As an experiment I used via-branch=extra with extra-id being the branch index. This seems to work well for initial INVITES because rtpengine says "creating new monologue" for each branch. This often breaks subsequent INVITEs because they are always branch 0. 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": "z9hG4bK3
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Attached here is a prettier version of the three offers.>From opensips
Jan 1 10:03:57 [2670144] Invite with first via host 192.168.1.2 and branch ID
z9hG4bKd83e.3a8b6577.0
Jan 1 10:03:57 [2670144] WebRTC-legacy interworking
Jan 1 10:03:57 [2670144] The answer profile must be opposite of the offer
profile
Jan 1 10:03:57 [2670144] Setting RTP profile for answer to debug via-branch=2
SDES-off ICE=force UDP/TLS/RTP/SAVPF replace-session-connection replace-origin
DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid
Jan 1 10:03:57 [2670144] DBG:core:comp_scriptvar: str 29: in-iface=ipv4-priv
out-iface=ipv6
Jan 1 10:03:57 [2670144] Interfaces are in-iface=ipv4-priv out-iface=ipv6
Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=
Jan 1 10:03:57 [2670144] DBG:core:decode_mime_type: Decoding MIME type
for:[application/sdp]
Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=40
Jan 1 10:03:57 [2670144] DBG:core:parse_to_param: tag=as1g4gcnjp
Jan 1 10:03:57 [2670144] DBG:core:_parse_to: end of header reached, state=29
Jan 1 10:03:57 [2670144] DBG:core:_parse_to: display={"Guest"},
ruri={sip:7...@cwdrive.mooo.com}
Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=4
Jan 1 10:03:57 [2670144] DBG:rtpengine:rtpe_function_call: proxy reply:
d3:sdp741:v=0
o=twinkle 2116263177 238598101 IN IP6 2001:569:7eb9:a400:223:7dff:feb8:d2b4
s=-
c=IN IP6 2001:569:7eb9:a400:223:7dff:feb8:d2b4
t=0 0
m=audio 35020 UDP/TLS/RTP/SAVPF 0 110
a=mid:0
a=rtpmap:0 PCMU/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=rtcp:35021
a=setup:active
a=fingerprint:sha-256
D9:B5:31:EE:D5:88:EC:84:B7:D7:D6:C7:73:45:A3:09:3B:A4:32:0A:C0:B0:DC:28:56:4C:DB:03:22:0B:22:DE
a=ptime:20
a=ice-ufrag:ARYGxrUa
a=ice-pwd:jyP7JQCqLbW9wGFzL5ClW45SLj
a=ice-options:trickle
a=candidate:1wwouT4DYwT3ocfl 1 UDP 2130706431
2001:569:7eb9:a400:223:7dff:feb8:d2b4 35020 typ host
a=candidate:1wwouT4DYwT3ocfl 2 UDP 2130706430
2001:569:7eb9:a400:223:7dff:feb8:d2b4 35021 typ host
a=end-of-candidates
6:result2:oke
Notice from above --
Setting RTP profile for answer to debug via-branch=2 SDES-off ICE=force
UDP/TLS/RTP/SAVPF replace-session-connection replace-origin
DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid
rtcp-mux-required was passed to rtpengine but sdp from rtpengine did not
include it.
>From the caller web application
ac_webrtc.min.js:9 emit "peerconnection:setremotedescriptionfailed"
[error:DOMException: Failed to execute 'setRemoteDescription' on
'RTCPeerConnection': Failed to set remote answer sdp: The m= section with
mid='0' is invalid. RTCP-MUX is not enabled when it is required.]
>From rtpengine log
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",
[OpenSIPS-Users] Trouble with forked calls and rtpengine
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: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp For the second and third offers the debug logs say "found existing monologue". This tells me that the offers are considered to be unique. However to requirements for modifying the SDP are unique. The identical "via-branch": "z9hG4bK3119290" appears in each offer. My theory is that the requirements for the three branches are being stacked on top of each because rtpengine considers them all to be a single offer. The theory seems to fit with what I have observed. The calls may or not fail. It seems to be influenced by the order of the branches and also which branch is actually answered. I get weird failures like rtc-mux being missing from the sdp when clearly it was submitted in the offer. Any ideas? Regards, Rob ___ Users mailing list Users@lists.opensips.org
Re: [OpenSIPS-Users] Some questions regarding configuring msilo
How very odd. I revisited the documentation and the code snippet I was
referencing indeed does not exist. The snippet shown in my previous email was
a copy and paste.
Thank you for investigating.
Rob
On Thursday, November 18, 2021 11:48:29 P.M. PST Bogdan-Andrei Iancu wrote:
> Hi Robert,
>
> I guess you are talking about his
> https://opensips.org/html/docs/modules/3.2.x/msilo.html#idp5708384 ?
> Which looks like it was not updated since ages.it is not even 3.2
> compatible actually.
>
> The "# if the downstream UA does not support MESSAGE requests" block is
> outside the "if(!lookup("location")) ", so it is done when the lookup()
> succeeded. And to be honest I do not see that "t_on_if()" anywhere .
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
> OpenSIPS eBootcamp 2021
>https://opensips.org/training/OpenSIPS_eBootcamp_2021/
>
> On 11/11/21 10:34 PM, Robert Dyck wrote:
> > The module documentation for msilo gives us an example of
> > configuration to deploy the service.
> >
> > In a block staring with "if(!lookup("location"))" we see the following --
> >
> >
> > # if the downstream UA does not support MESSAGE requests
> ># go to failure_route[1]
> >t_on_if (!db_does_uri_exist("$ru","subscriber"))failure("1");
> >t_relay();
> >exit;
> > We didn't actually establish that the lookup failed because Message is
> > unsupported. Lookup has only one failure return code -1. This does not
> > tell us if the lookup failure was due to an non-existant AOR, no UAs
> > registered or method not supported.
> >
> >
> > In the statement "t_on_if
> > (db_does_uri_exist("$ru","subscriber"))failure("1"); " t_on_if is not
> > documented. Does it mean we should immediately go to the failure route
> > if the AOR does not exist.
> >
> >
> > If the AOR does not exist why would we do ---
> >
> >if (m_store("$ou"))
> >{
> >log("MSILO: offline message stored\n");
> >t_reply("202", "Accepted");
> >}else{
> >log("MSILO: offline message NOT stored\n");
> >t_reply("503", "Service Unavailable");
> >};
> >
> >
> > Some clarification would be appreciated.
> >
> > Rob
> >
> >
> > ___
> > 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] msilo module offline message time stamp
Found the patches. Applied, recompiled, and reinstalled the module. All good now. Thanks On Tuesday, November 16, 2021 2:54:02 A.M. PST Bogdan-Andrei Iancu wrote: > Hi Robert, > > What OpenSIPS version are you using? Asking as I remember of a recent > fix in that area [1] > > [1] > https://github.com/OpenSIPS/opensips/commit/cc20f738b83f5a9c7f24630309ddb5ba > b889bf56 > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 >https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 11/13/21 12:12 AM, Robert Dyck wrote: > > How does one set the time stamp that openips prefixes to an offline > > message that is sent when the UA registers? > > > > 2021-11-12 14:06 from 5 "[Offline message - Wed Dec 31 16:00:00 1969 ] HI > > THERE" > > > > Thanks, Rob > > > > > > > > ___ > > 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] msilo module offline message time stamp
tls_wolfssl last week. On Tuesday, November 16, 2021 7:58:12 A.M. PST Bogdan-Andrei Iancu wrote: > oky...could you point me to that report? > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 >https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 11/16/21 5:54 PM, Robert Dyck wrote: > > I think I saw a report of a seg fault. > > > > On Tuesday, November 16, 2021 7:52:26 A.M. PST Bogdan-Andrei Iancu wrote: > >> What kind of difficulties with 3.2.3 ? > >> > >> Regards, > >> > >> Bogdan-Andrei Iancu > >> > >> OpenSIPS Founder and Developer > >> > >> https://www.opensips-solutions.com > >> > >> OpenSIPS eBootcamp 2021 > >> > >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > >> > >> On 11/16/21 5:42 PM, Robert Dyck wrote: > >>> Still on 3.2.2. I saw reports of difficulty with 3.2.3. > >>> Should I be recompiling? > >>> Thanks, Rob > >>> > >>> On Tuesday, November 16, 2021 2:54:02 A.M. PST Bogdan-Andrei Iancu wrote: > >>>> Hi Robert, > >>>> > >>>> What OpenSIPS version are you using? Asking as I remember of a recent > >>>> fix in that area [1] > >>>> > >>>> [1] > >>>> https://github.com/OpenSIPS/opensips/commit/cc20f738b83f5a9c7f24630309d > >>>> db > >>>> 5ba b889bf56 > >>>> > >>>> Regards, > >>>> > >>>> Bogdan-Andrei Iancu > >>>> > >>>> OpenSIPS Founder and Developer > >>>> > >>>> https://www.opensips-solutions.com > >>>> > >>>> OpenSIPS eBootcamp 2021 > >>>> > >>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > >>>> > >>>> On 11/13/21 12:12 AM, Robert Dyck wrote: > >>>>> How does one set the time stamp that openips prefixes to an offline > >>>>> message that is sent when the UA registers? > >>>>> > >>>>> 2021-11-12 14:06 from 5 "[Offline message - Wed Dec 31 16:00:00 1969 ] > >>>>> HI > >>>>> THERE" > >>>>> > >>>>> Thanks, Rob > >>>>> > >>>>> > >>>>> > >>>>> ___ > >>>>> 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] msilo module offline message time stamp
I think I saw a report of a seg fault. On Tuesday, November 16, 2021 7:52:26 A.M. PST Bogdan-Andrei Iancu wrote: > What kind of difficulties with 3.2.3 ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 >https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 11/16/21 5:42 PM, Robert Dyck wrote: > > Still on 3.2.2. I saw reports of difficulty with 3.2.3. > > Should I be recompiling? > > Thanks, Rob > > > > On Tuesday, November 16, 2021 2:54:02 A.M. PST Bogdan-Andrei Iancu wrote: > >> Hi Robert, > >> > >> What OpenSIPS version are you using? Asking as I remember of a recent > >> fix in that area [1] > >> > >> [1] > >> https://github.com/OpenSIPS/opensips/commit/cc20f738b83f5a9c7f24630309ddb > >> 5ba b889bf56 > >> > >> Regards, > >> > >> Bogdan-Andrei Iancu > >> > >> OpenSIPS Founder and Developer > >> > >> https://www.opensips-solutions.com > >> > >> OpenSIPS eBootcamp 2021 > >> > >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > >> > >> On 11/13/21 12:12 AM, Robert Dyck wrote: > >>> How does one set the time stamp that openips prefixes to an offline > >>> message that is sent when the UA registers? > >>> > >>> 2021-11-12 14:06 from 5 "[Offline message - Wed Dec 31 16:00:00 1969 ] > >>> HI > >>> THERE" > >>> > >>> Thanks, Rob > >>> > >>> > >>> > >>> ___ > >>> 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] msilo module offline message time stamp
Still on 3.2.2. I saw reports of difficulty with 3.2.3. Should I be recompiling? Thanks, Rob On Tuesday, November 16, 2021 2:54:02 A.M. PST Bogdan-Andrei Iancu wrote: > Hi Robert, > > What OpenSIPS version are you using? Asking as I remember of a recent > fix in that area [1] > > [1] > https://github.com/OpenSIPS/opensips/commit/cc20f738b83f5a9c7f24630309ddb5ba > b889bf56 > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 >https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 11/13/21 12:12 AM, Robert Dyck wrote: > > How does one set the time stamp that openips prefixes to an offline > > message that is sent when the UA registers? > > > > 2021-11-12 14:06 from 5 "[Offline message - Wed Dec 31 16:00:00 1969 ] HI > > THERE" > > > > Thanks, Rob > > > > > > > > ___ > > 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] msilo module offline message time stamp
How does one set the time stamp that openips prefixes to an offline message that is sent when the UA registers? 2021-11-12 14:06 from 5 "[Offline message - Wed Dec 31 16:00:00 1969 ] HI THERE" Thanks, Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Some questions regarding configuring msilo
The module documentation for msilo gives us an example of configuration to
deploy the
service.
In a block staring with "if(!lookup("location"))" we see the following --
# if the downstream UA does not support MESSAGE requests
# go to failure_route[1]
t_on_if (!db_does_uri_exist("$ru","subscriber"))failure("1");
t_relay();
exit;
We didn't actually establish that the lookup failed because Message is
unsupported.
Lookup has only one failure return code -1. This does not tell us if the lookup
failure was
due to an non-existant AOR, no UAs registered or method not supported.
In the statement "t_on_if (db_does_uri_exist("$ru","subscriber"))failure("1");
" t_on_if is not
documented. Does it mean we should immediately go to the failure route if the
AOR does
not exist.
If the AOR does not exist why would we do ---
if (m_store("$ou"))
{
log("MSILO: offline message stored\n");
t_reply("202", "Accepted");
}else{
log("MSILO: offline message NOT stored\n");
t_reply("503", "Service Unavailable");
};
Some clarification would be appreciated.
Rob
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DTLS in Opensips
Opensips doesn't care about media. However rtpengine can bridge DTLS to non- DTLS. On Friday, December 25, 2020 12:30:22 P.M. PST Ali Alawi wrote: > Hello, > > Is there a way to use DTLS on opensips through openssl? > > Any help or guid would be appreciated. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Opensips-3.0.4 compile tcp fails
net/tcp_common.c will not compile. Too many errors to list here. It seems to be a new file as compared to my 3.0.2. Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Should opensips support pong on websocket?
Context opensips-3.0.2 The TCP protocol enables support for ping/pong by default. It is the underlying protocol for websocket. I am seeing short messages from webrtc UAs at 10 second intervals. Opensips is rejecting the messages. Sep 4 11:15:30 [3091728] DBG:proto_wss:ws_process: Using the global ( per process ) buff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Register problem, 2 UA address conflict
Unfortunately I was hasty in my interpretation. There is definitely a problem but it lies with the UA and not opensips. The UA mis-identifies itself and the caller sends the ACK to the wrong UA. On Saturday, August 15, 2020 8:39:20 A.M. PDT Robert Dyck wrote: I should explain the consequence of this error. A and B register with the same AOR. A receives the correct instance ID while B receives A's ID. There is a call to the AOR. B answers the call and sends 200 OK and identifies itself incorrectly. Caller receives 200 OK and sends an ACK to the instance. Opensips translates the instance to an IP address and routes the ACK to A. B times out since it didn't receive an ACK and drops the session. I hope that helps Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Need help transitioning to opensips-cli
My database was created with the old opensipsdbctl tool. The database engine is sqlite. I want to start using opensips-cli to administer the subscriber table. The trouble I am having is opensips-cli wants to connect to the database named "opensips". How do I associate the sqlite database at / usr/local/etc/opensips/sqlite with the name "opensips"? As a learning exercise I wanted to create a new database using opensips-cli "database create sqlite:///tmp" or "database create sqlite:///tmp/tmp.db". The response was invariably "*ERROR*: Bad URL, it should resemble: sqlite:/// path/to/db". Omitting the path gives the same error message. What am I missing? Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Register problem, 2 UA address conflict
I should explain the consequence of this error. A and B register with the same AOR. A receives the correct instance ID while B receives A's ID. There is a call to the AOR. B answers the call and sends 200 OK and identifies itself incorrectly. Caller receives 200 OK and sends an ACK to the instance. Opensips translates the instance to an IP address and routes the ACK to A. B times out since it didn't receive an ACK and drops the session. I hope that helps Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Register problem, 2 UA address conflict
Two UAs with the same AOR register. Both support GRUU. Both are assigned the same sip instance.. 0fb66f5c-90f4-4611-9141-2594480977aa SIP/2.0 200 OK received=2001::9B5D;rport=46004;branch=z9hG4bK598182 To: ;tag=59de.372db74950592a93c1f2e8ff9432ad9f From: "test" ;tag=q3obuoma57 Call-ID: cphnnphgouu7e9dbuetsg2 CSeq: 32 REGISTER Contact: ;expires=600;received="sip: [2001::9B5D]:46004;transport=wss";pub-gruu="sip:4...@bogus.com:8000;gr=urn:uuid: 0fb66f5c-90f4-4611-9141-2594480977aa";temp- gruu="sip:tgruu.AUUKWWcCQGIFQRNac0QCPQoFRgc3C0A1UkYFCGZSXWoAFgdDZwdBYh1JAlpiH ejmcuqhvmmir2rrermni1kepuayvaemrec2crrrgzzfa...@bogus.com:8000;gr"; +sip.instance="urn:uuid:0fb66f5c-90f4-4611-9141-2594480977aa", ;expires=600;received="sip:[2001::380C]: 37584;transport=wss";pub-gruu="sip:4...@bogus.com:8000;gr=urn:uuid:123f9901-705f-4510- a420-bd414f394a3a";temp- gruu="sip:tgruu.AUUKWWcCQGIFQRNac0QCPQoFRgc3C0FhAxYKV2MAXWQARVVDZwRBYx0RB1x jhbi3beehcgairdidermca0dajquaqxojcekiaxnzxjdvf...@bogus.com:8000;gr"; +sip.instance="urn:uuid:123f9901-705f-4510-a420-bd414f394a3a" Server: OpenSIPS (3.0.2 (x86_64/linux)) Content-Length: 0 The following sip instance is not correct. SIP/2.0 200 OK Via: SIP/2.0/WSS nn5hyo9ppowu.invalid;received=2001::380C;rport=37584;branch=z9hG4bK1423857 To: ;tag=59de.6a64ebfefdb29af9b8e48fb34ce54f94 From: "Rob" ;tag=9fllgd1to2 Call-ID: l8v0v5jptp99q3cj0dde7r CSeq: 8 REGISTER Contact: ;expires=383;received="sip:[2001::9B5D]: 44248;transport=wss";pub-gruu="sip:4...@bogus.com:8000;gr=urn:uuid: 0fb66f5c-90f4-4611-9141-2594480977aa";temp- gruu="sip:tgruu.AUUKWWcCQGIFQRNac0QCPQoFRgc3C0A1UkYFCGZSXWoAFgdDZwdBYh1JAlpiH ejmcuqhvmmir2rrermni1kepuayvaemrec2crrrgzzfa...@bogus.com:8000;gr"; +sip.instance="urn:uuid:0fb66f5c-90f4-4611-9141-2594480977aa", ;expires=600;received="sip:[2001::380C]: 37584;transport=wss";pub-gruu="sip:4...@bogus.com:8000;gr=urn:uuid:123f9901-705f-4510- a420-bd414f394a3a";temp- gruu="sip:tgruu.AUUKWWcCQGIFQRNac0QCPQoFRgc3C0FhAxYKV2MAXWQARVVDZwRBYx0RB1x jhbi3beehcgairdidermca0dajquaqxojcekiaxnzxjdvf...@bogus.com:8000;gr"; +sip.instance="urn:uuid:123f9901-705f-4510-a420-bd414f394a3a" Server: OpenSIPS (3.0.2 (x86_64/linux)) Content-Length: 0 >From ul_dump "AOR": "4", ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SDES and DTLS mutually exclusive
Doh One tiny line. Indeed it eliminates the crypto. It would seem that invalid flags are simply ignored. On Monday, July 6, 2020 8:20:24 A.M. PDT Ovidiu Sas wrote: According to the documentation, the prefix for sdes flags is ‘SDES-‘ (dash not equal). -ovidiu On Mon, Jul 6, 2020 at 10:45 Robert Dyck wrote: Perhaps you misinterpreted my wording. I actually tired SDES=off but crypto attributes were still inserted.. It is a bit strange that ICE=force should arbitrarily add the crypto. On Monday, July 6, 2020 12:25:44 A.M. PDT Răzvan Crainea wrote:> You should use the SDES- off flag to rtoengine.> > Best regards,> > Răzvan Crainea> OpenSIPS Core Developer> http:// www.opensips-solutions.com[2] Users@lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] Users@lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] Users@lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] -- VoIP Embedded, Inc. http://www.voipembedded.com[5] [1] mailto:rob.d...@telus.net [2] http://www.opensips-solutions.com [3] mailto:Users@lists.opensips.org [4] http://lists.opensips.org/cgi-bin/mailman/listinfo/users [5] http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SDES and DTLS mutually exclusive
Perhaps you misinterpreted my wording. I actually tired SDES=off but crypto attributes were still inserted.. It is a bit strange that ICE=force should arbitrarily add the crypto. On Monday, July 6, 2020 12:25:44 A.M. PDT Răzvan Crainea wrote: > You should use the SDES-off flag to rtoengine. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/4/20 10:34 PM, Robert Dyck wrote: > > I have run into an issue with rtpengine and the ICE=force option. > > > > To quote the rtpengine README > > > > With `force`, ICE attributes are first stripped, then new attributes are > > > > generated and inserted, which leaves the media proxy as the only > > > > ICE candidate. > > > > When using the force option where I think it will be appropriate I found > > it also adds crypto attributes. I believe this invokes SDES security. If > > the setup attribute is also present ( DTLS security ) the call fails > > with bad description. SDES=off does not prevent this behaviour. The > > error message from the UA says there cannot be both. > > > > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > > inline:/msDyiV8x6qpcH4m1iEmxo8aqAAhhkGctQbxvkNy > > > > a=crypto:2 AES_CM_128_HMAC_SHA1_32 > > inline:JgDv7fMfKd1GQcFq9Jn0tMf1C5DE0VaRDe6Js8D6 > > > > a=crypto:3 AES_192_CM_HMAC_SHA1_80 > > inline:CiCkAETMov/tbVsqykp7j3/PB7aUfQjv+nozBQuOUMBnJlrm8bU > > > > a=crypto:4 AES_192_CM_HMAC_SHA1_32 > > inline:6ktVsgwfiGg4US2BLWuV3XpCt0fvkiuFgcEr8n83KDln8w9ar+c > > > > a=crypto:5 AES_256_CM_HMAC_SHA1_80 > > inline:l1pr/67vqwthDdnRoSaTbGvRPBNP7uHIhjfeG8InuqWQZjLkumU5MVKz2mAujw > > > > a=crypto:6 AES_256_CM_HMAC_SHA1_32 > > inline:V+K2bK8Zahr9KX7zswVwM2cpZ+/g8hMD4a5PmJzncH8WgDnCH/xLH0CFRwYKgg > > > > a=crypto:7 F8_128_HMAC_SHA1_80 > > inline:Z00dhmeQwuttjeRawylGKannT7KbBZhDExDxETNo > > > > a=crypto:8 F8_128_HMAC_SHA1_32 > > inline:R5Vqt9WQ1wU76GcS7CvDosgbWHRYLV7CRnGre+uV > > > > a=crypto:9 NULL_HMAC_SHA1_80 > > inline:TP2aKDSKe8G9E7kd+w7XpOhcItzd0xmBN3g06WC1 > > > > a=crypto:10 NULL_HMAC_SHA1_32 > > inline:xKFUEuwLpexe84KKCulBSThMx75T74U7/K7qJbKi > > > > a=setup:actpass > > > > > > ___ > > 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] SDES and DTLS mutually exclusive
I have run into an issue with rtpengine and the ICE=force option. To quote the rtpengine README With `force`, ICE attributes are first stripped, then new attributes are When using the force option where I think it will be appropriate I found it also adds crypto attributes. I believe this invokes SDES security. If the setup attribute is also present ( DTLS security ) the call fails with bad description. SDES=off does not prevent this behaviour. The error message from the UA says there cannot be both. a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/ msDyiV8x6qpcH4m1iEmxo8aqAAhhkGctQbxvkNy a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:JgDv7fMfKd1GQcFq9Jn0tMf1C5DE0VaRDe6Js8D6 a=crypto:3 AES_192_CM_HMAC_SHA1_80 inline:CiCkAETMov/tbVsqykp7j3/ PB7aUfQjv+nozBQuOUMBnJlrm8bU a=crypto:4 AES_192_CM_HMAC_SHA1_32 inline: 6ktVsgwfiGg4US2BLWuV3XpCt0fvkiuFgcEr8n83KDln8w9ar+c a=crypto:5 AES_256_CM_HMAC_SHA1_80 inline:l1pr/ 67vqwthDdnRoSaTbGvRPBNP7uHIhjfeG8InuqWQZjLkumU5MVKz2mAujw a=crypto:6 AES_256_CM_HMAC_SHA1_32 inline:V+K2bK8Zahr9KX7zswVwM2cpZ+/ g8hMD4a5PmJzncH8WgDnCH/xLH0CFRwYKgg a=crypto:7 F8_128_HMAC_SHA1_80 inline:Z00dhmeQwuttjeRawylGKannT7KbBZhDExDxETNo a=crypto:8 F8_128_HMAC_SHA1_32 inline:R5Vqt9WQ1wU76GcS7CvDosgbWHRYLV7CRnGre+uV a=crypto:9 NULL_HMAC_SHA1_80 inline:TP2aKDSKe8G9E7kd+w7XpOhcItzd0xmBN3g06WC1 a=crypto:10 NULL_HMAC_SHA1_32 inline:xKFUEuwLpexe84KKCulBSThMx75T74U7/K7qJbKi a=setup:actpass ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Rtpengine configuration problem
Answering my own question, it appears that rtpengine reverses the logic of rtpproxy with regard to the media source address. It trusts the "c" ( connection ) address that the UA puts there. In this case the UA had learned what its public address was. Rtpengine trusts this instead using the source address. Now that the binding request is going to the UA I have to find where the binding response is going. On Friday, July 3, 2020 8:06:16 P.M. PDT Robert Dyck wrote: While configuring my script for rtpengine I got a rather confusing result. The test involved a UA tethered to a phone with only IPV4 availble. The test was a call to a UA registered with an IPV6 address. The call was answered successfully but there was no media. A sniffer at the rtpengine host ( also opensips ) revealed the following -- continuous binding request, no media wireless IPV4 -> rtpengine in port -> rtpengine out port -> IPV6 -> AB:CD:: The destination address was obviously bogus. Since the address was so short on a hunce I converted it to decimal. It turns out that the binding request was being sent to the NAT's public IPV4 address but as an IPV6 packet. The signalling looked. Is this a misconfiguration? Rtpengine is configured in bridging mode with an IPV4 address and an IPV6 address. INVTEe ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Rtpengine configuration problem
While configuring my script for rtpengine I got a rather confusing result. The test involved a UA tethered to a phone with only IPV4 availble. The test was a call to a UA registered with an IPV6 address. The call was answered successfully but there was no media. A sniffer at the rtpengine host ( also opensips ) revealed the following -- continuous binding request, no media wireless IPV4 -> rtpengine in port -> rtpengine out port -> IPV6 -> AB:CD:: The destination address was obviously bogus. Since the address was so short on a hunce I converted it to decimal. It turns out that the binding request was being sent to the NAT's public IPV4 address but as an IPV6 packet. The signalling looked. Is this a misconfiguration? Rtpengine is configured in bridging mode with an IPV4 address and an IPV6 address. INVTEe ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Useless NAT check with IPV6
The bug report was deemed unnecessary. For those searching the archive you can
eliminate this
type of error by ensuring that your script employs fix_nated_register and
fix_nated_contact.
Without it the contact will contain gibbrish and the location table will not
record the actual
address in the "received" field. Call routing will fail. This applies whether
or not the contact is
nated when GRUU is in use. Perhaps uncommon once but always present in WEBRTC.
On Thursday, June 25, 2020 9:56:39 A.M. PDT Robert Dyck wrote:
I have submitted bug #2154.
I believe it is a registration problem. The "received" should never be null in
the location table.
On Wednesday, June 24, 2020 2:36:04 P.M. PDT Robert Dyck wrote:
Context: opensips 3.0.2
I wanted to cleanup a working configuration so I eliminated the NAT check if
the address family
was IPV6. This was in the initial request route. I was surprised to see that an
IPV6 INVITE would
fail. The REGISTERs were good.
Could someone explain to me what is happening.
Thanks, Rob
Config and debug on failure
if ($af == "INET") {
un 24 10:09:34 [1682250] Branch index is 0
Debug of NAT check, working scenario
Jun 24 13:59:52 [1707071] Received request from WAN, Method is INVITE
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Useless NAT check with IPV6
I have submitted bug #2154.
I believe it is a registration problem. The "received" should never be null in
the location table.
On Wednesday, June 24, 2020 2:36:04 P.M. PDT Robert Dyck wrote:
Context: opensips 3.0.2
I wanted to cleanup a working configuration so I eliminated the NAT check if
the address family
was IPV6. This was in the initial request route. I was surprised to see that an
IPV6 INVITE would
fail. The REGISTERs were good.
Could someone explain to me what is happening.
Thanks, Rob
Config and debug on failure
if ($af == "INET") {
un 24 10:09:34 [1682250] Branch index is 0
Debug of NAT check, working scenario
Jun 24 13:59:52 [1707071] Received request from WAN, Method is INVITE
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Useless NAT check with IPV6
Context: opensips 3.0.2
I wanted to cleanup a working configuration so I eliminated the NAT check if
the address family
was IPV6. This was in the initial request route. I was surprised to see that an
IPV6 INVITE would
fail. The REGISTERs were good.
Could someone explain to me what is happening.
Thanks, Rob
Config and debug on failure
if ($af == "INET") {
un 24 10:09:34 [1682250] Branch index is 0
Debug of NAT check, working scenario
Jun 24 13:59:52 [1707071] Received request from WAN, Method is INVITE
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rtpengine documentation
Actually I had read the readme and I was wondering if opensips perhaps didn't support all the flags since some were missing from the documentation. Also on the subject of DTLS I am guessing that no flags means DTLS pass through but not certain. Also on the subject of DTLS when it plays MITM it sends a fingerprint that is generated with the SHA-1 hash which is deemed inadequate these days. With regard to the crypto aspect DTLS is supposed to follow TLS. Thanks everyone for the input. Rob On Tuesday, May 19, 2020 7:20:48 P.M. PDT Ovidiu Sas wrote: Hello Robert, Take a look at the README file. Based on the flags, rtpengine can bridge encrypted RTP traffic to unencrypted RTP traffic. It can also do transcoding. So yes, it plays man-in-the-middle :) Regards, Ovidiu Sas On Tue, May 19, 2020 at 18:32 Robert Dyck wrote: Perhaps someone with knowledge of the inner workings of rtpengine could enlighten us about the interaction between ICE and DTLS. My experience suggests that it plays man-in-the-middle and fakes the DTLS negotiation in some circumstances. Rob On Tuesday, May 19, 2020 3:15:54 P.M. PDT Giovanni Maruzzelli wrote: On Tue, May 19, 2020, 20:10 Ovidiu Sas wrote: opensips rtpengine module provides amechanism to pass those flags as strings to the rtpengine instance.Maybe we should add this to the documentation. +1 +1 +1 (me, myself and I) -giovanni Regards,Ovidiu Sas On Sat, May 16, 2020 at 3:37 PM Robert Dyck wrote:>> I am wanting to convert my config/script to use rtpengine instead of rtpproxy.> I think it would better deal with webrtc. After looking at some examples I> found, I see a couple of parameters that are not mentioned in the opensips> documentation. First there is the offer/answer option ice=force- relay and> secondly DTLS=passive.>> Are these options obsolete/deprecated/intentionally omitted?>> On the subject of DTLS I noticed that when I use ice=force in offer and answer> rtpengine sends new DTLS fingerprints to the parties. I appears to operate as> back-to-back DTLS agent. I know this because both UAs sent SHA-256> fingerprints but they received SHA-1 fingerprints. This may have worked but> one UA will only accept SHA-256 and it drops the call.>> The documentation does not mention that the ice= option can influence DTLS.>> Regards, Rob>>>> ___> Users mailing list> Users@lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] http://www.voipembedded.com[5] Users@lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] ___Users mailing list Users@lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] -- VoIP Embedded, Inc. http://www.voipembedded.com[5] [1] mailto:rob.d...@telus.net [2] mailto:o...@voipembedded.com [3] mailto:Users@lists.opensips.org [4] http://lists.opensips.org/cgi-bin/mailman/listinfo/users [5] http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rtpengine documentation
Perhaps someone with knowledge of the inner workings of rtpengine could enlighten us about the interaction between ICE and DTLS. My experience suggests that it plays man-in-the-middle and fakes the DTLS negotiation in some circumstances. Rob On Tuesday, May 19, 2020 3:15:54 P.M. PDT Giovanni Maruzzelli wrote: On Tue, May 19, 2020, 20:10 Ovidiu Sas wrote: opensips rtpengine module provides amechanism to pass those flags as strings to the rtpengine instance.Maybe we should add this to the documentation. +1 +1 +1 (me, myself and I) -giovanni Regards,Ovidiu Sas On Sat, May 16, 2020 at 3:37 PM Robert Dyck wrote:>> I am wanting to convert my config/script to use rtpengine instead of rtpproxy.> I think it would better deal with webrtc. After looking at some examples I> found, I see a couple of parameters that are not mentioned in the opensips> documentation. First there is the offer/answer option ice=force- relay and> secondly DTLS=passive.>> Are these options obsolete/deprecated/intentionally omitted?>> On the subject of DTLS I noticed that when I use ice=force in offer and answer> rtpengine sends new DTLS fingerprints to the parties. I appears to operate as> back-to-back DTLS agent. I know this because both UAs sent SHA-256> fingerprints but they received SHA-1 fingerprints. This may have worked but> one UA will only accept SHA-256 and it drops the call.>> The documentation does not mention that the ice= option can influence DTLS.>> Regards, Rob>>>> ___> Users mailing list> Users@lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] http://www.voipembedded.com[5] Users@lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] [1] mailto:o...@voipembedded.com [2] mailto:rob.d...@telus.net [3] mailto:Users@lists.opensips.org [4] http://lists.opensips.org/cgi-bin/mailman/listinfo/users [5] http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] rtpengine documentation
I am wanting to convert my config/script to use rtpengine instead of rtpproxy. I think it would better deal with webrtc. After looking at some examples I found, I see a couple of parameters that are not mentioned in the opensips documentation. First there is the offer/answer option ice=force-relay and secondly DTLS=passive. Are these options obsolete/deprecated/intentionally omitted? On the subject of DTLS I noticed that when I use ice=force in offer and answer rtpengine sends new DTLS fingerprints to the parties. I appears to operate as back-to-back DTLS agent. I know this because both UAs sent SHA-256 fingerprints but they received SHA-1 fingerprints. This may have worked but one UA will only accept SHA-256 and it drops the call. The documentation does not mention that the ice= option can influence DTLS. Regards, Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] rtpproxy module not supporting valid payload types
Regarding opensips-3.0 Use case - webrtc client behind NAT The rtpproxy module emitted the error message "can't extract media port from the message" ( by the way, very misleading ). In reality extract_mediainfo fails because it could not find a supported payload type in the media description. The payload type in question is "UDP/TLS/RTP/SAVPF". RFC 5764 section 8 introduces four more RTP types. DCCP/TLS/RTP/SAVP and SAVPF UDP/TLS/RTP/SAVP and SAVPF Should rtpproxy.c be extended to support these additional RTP types? Thank you, Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] SEG violation in 3.0.2
The following configuration snippet worked for me in 2.4 but causes a coredump
in 3.0.1 and
3.0.2.
In request route ( sequential )
xlog("Check for GRUU, Method is $rm\n");
Results
Mar 06 13:39:37 slim.mylan /usr/local/sbin/opensips[62100]: *Check for GRUU,
Method is BYE*
*Request URI is
sip:4@192.168.1.2:5060;gr=urn:uuid:13acf37f-2138-0064-a85a-fb5d39f65cc0*
DBG:core:grep_sock_info_ext: checking if host==us: 11==11 && [192.168.1.2] ==
[192.168.
DBG:core:grep_sock_info_ext: checking if host==us: 11==11 && [192.168.1.2] ==
[192.168.
DBG:core:parse_params: Parsing params
for:[gr=urn:uuid:13acf37f-2138-0064-a85a-fb5d39f65
*Found GRUU*
DBG:registrar:parse_lookup_flags: final flags: 1
DBG:registrar:extract_aor: has gruu
DBG:registrar:extract_aor: public gruu
DBG:registrar:select_contacts: ct: sip:4@192.168.1.75:49479;transport=udp
DBG:registrar:select_contacts: ruri has gruu
*CRITICAL:core:sig_usr: segfault in process pid: 62100, id: 5*
DBG:core:restore_segv_handler: restoring SIGSEGV handler...
DBG:core:restore_segv_handler: successfully restored system SIGSEGV handler
DBG:core:handle_sigs: OpenSIPS exit status = 139
[root@slim opensips]# coredumpctl info 62100
PID: 62100 (opensips)
UID: 1001 (opensips)
GID: 1002 (opensips)
Signal: 11 (SEGV)
Timestamp: Fri 2020-03-06 13:39:37 PST (3min 25s ago)
Command Line: /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f
/usr/local/etc/opensips/opensips.cfg -m 64 -M 4
Executable: /usr/local/sbin/opensips
Control Group: /system.slice/opensips.service
Unit: opensips.service
Slice: system.slice
Boot ID: 9478439d3253442c8068265e87ac6928
Machine ID: d00237b6be8b4893b5359ee676dfc035
Hostname: slim.mylan
Storage:
/var/lib/systemd/coredump/core.opensips.1001.9478439d3253442c8068265e87ac6928.62100.1583530777.lz4
Message: Process 62100 (opensips) of user 1001 dumped core.
Stack trace of thread 62100:
#0 0x7ffa4ee8fb6a __GI___strlen_sse2 (libc.so.6)
#1 0x7ffa4ee5d5fe __vfprintf_internal (libc.so.6)
#2 0x7ffa4eeebb04 __vsyslog_internal (libc.so.6)
#3 0x7ffa4eeebf8a syslog (libc.so.6)
#4 0x7ffa4a876f66 select_contacts (registrar.so)
#5 0x7ffa4a877aa6 lookup (registrar.so)
#6 0x00433ada do_action (opensips)
#7 0x0043bf47 run_action_list (opensips)
#8 0x0048997b eval_elem (opensips)
#9 0x0048938d eval_expr (opensips)
#10 0x0048943a eval_expr (opensips)
#11 0x00489375 eval_expr (opensips)
#12 0x00433b8d do_action (opensips)
#13 0x0043bf47 run_action_list (opensips)
#14 0x004392a5 do_action (opensips)
#15 0x0043bf47 run_action_list (opensips)
#16 0x004392a5 do_action (opensips)
#17 0x0043c113 run_action_list (opensips)
#18 0x00449e45 receive_msg (opensips)
#19 0x006212ff udp_read_req (opensips)
#20 0x005fbb55 handle_io (opensips)
#21 0x006000ec udp_start_processes (opensips)
#22 0x0041a5e3 main_loop (opensips)
#23 0x7ffa4ee171a3 __libc_start_main (libc.so.6)
#24 0x0041b07e _start (opensips)
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Fate of dbtext
With opensips 3.0 the new tool for accessing opensips is opensips-cli. The database module of opensips-cli only accepts the SQL variants. Does this mean that dbtext will in the future be deprecated? Eventually not supported? Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Issue with opensips-3.0.1 using dbtext
Never mind. A stupid mistake on my part. I should have just copied from my
working 2.4.5
instead of relying on faulty memory.
On Monday, October 14, 2019 7:32:18 P.M. PDT Robert Dyck wrote:
I am test driving 3.0.1. Using menuconfig I compiled the core, the default
modules and extra
modules mysql, presence, presence_xml and xcap.
Using menuconfig I generated a residential script with auth and presence. I
want to use db_text
with this minimal installation. I tweaked the configuration to load the db_text
module and the
db_url. The configuration appears to be correct as far as syntax is concerned.
I recycled the
"subscriber" table from a working 2.4.5 installation.
Usrloc does not initialize at runtime. Where have I gone wrong?
modparam("usrloc", "working_mode_preset", "single-instance-sql-write-back")
modparam("auth_db", "db_url",
Oct 14 19:12:07 [16761] DBG:core:init_mod: register MI for db_text
Oct 14 19:12:07 [16761] DBG:core:init_mod: initializing module usrloc
Oct 14 19:12:07 [16761] DBG:usrloc:mod_init: initializing
Oct 14 19:12:07 [16761] DBG:usrloc:check_runtime_config: ul config: db_mode=-1,
cluster_mode=0, rrp=1, sql_wm=2
Oct 14 19:12:07 [16761] INFO:usrloc:ul_init_locks: locks array size 512
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:db_bind_mod: using export interface to bind
db_textdb
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module db_textdb
not found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb
not found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in
module
db_textdb not found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb
not found
Oct 14 19:12:07 [16761] ERROR:core:db_check_api: module db_textdb does not
export
db_use_table function
Oct 14 19:12:07 [16761] ERROR:usrloc:mod_init: failed to bind database module
Oct 14 19:12:07 [16761] ERROR:core:init_mod: failed to initialize module usrloc
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Issue with opensips-3.0.1 using dbtext
I am test driving 3.0.1. Using menuconfig I compiled the core, the default
modules and extra
modules mysql, presence, presence_xml and xcap.
Using menuconfig I generated a residential script with auth and presence. I
want to use db_text
with this minimal installation. I tweaked the configuration to load the db_text
module and the
db_url. The configuration appears to be correct as far as syntax is concerned.
I recycled the
"subscriber" table from a working 2.4.5 installation.
Usrloc does not initialize at runtime. Where have I gone wrong?
modparam("usrloc", "working_mode_preset", "single-instance-sql-write-back")
modparam("auth_db", "db_url",
Oct 14 19:12:07 [16761] DBG:core:init_mod: register MI for db_text
Oct 14 19:12:07 [16761] DBG:core:init_mod: initializing module usrloc
Oct 14 19:12:07 [16761] DBG:usrloc:mod_init: initializing
Oct 14 19:12:07 [16761] DBG:usrloc:check_runtime_config: ul config: db_mode=-1,
cluster_mode=0, rrp=1, sql_wm=2
Oct 14 19:12:07 [16761] INFO:usrloc:ul_init_locks: locks array size 512
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:db_bind_mod: using export interface to bind
db_textdb
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module db_textdb
not found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb
not found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb not
found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in
module
db_textdb not found
Oct 14 19:12:07 [16761] DBG:core:find_mod_export: in module
db_textdb
not found
Oct 14 19:12:07 [16761] ERROR:core:db_check_api: module db_textdb does not
export
db_use_table function
Oct 14 19:12:07 [16761] ERROR:usrloc:mod_init: failed to bind database module
Oct 14 19:12:07 [16761] ERROR:core:init_mod: failed to initialize module usrloc
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Feature request - pseudo-variable for destination IP address
Using the ip transform to resolve the address worked for me. When I get around to it I should do it on opensips start up and cache the address On Thursday, July 18, 2019 7:53:41 A.M. PDT Vitalii Aleksandrov wrote: > Hi, > > Original question was about different thing but the destination IP of a > request or reply is not hard to get. I wrote a small module which > extracts the destination uri from ru (du) for requests and from via for > replies, makes a dns resolve if it's a domain name and then detects the > outgoing interface of opensips and exports it as a PV to config. The > goal was to configure rtpengine's direction to bridge between different > interfaces. Adding just a few more lines of code will export the > destination IP as a PV. Since I use dns cache module resolve happens > only once and when t_relay() (tm module) searches for a destination it > just reuses previously resolved values from cache. I can share it if > anybody needs it. > > > As far as I know, the equivalent variable to $si on the destination side > > is either $dd, which may not always be set, or $rd. Those are not > > guaranteed to be IP addresses, however. If DNS is being used, I don't > > believe OpenSIPS provides the results of the DNS lookup to the script in > > any variable, so I don't think there is a way to find the actual IP aside > > from doing your own DNS lookup (or possibly using the dns_cache module > > and snooping the cache, but I have had issues with this module in the > > past.) > > > > Ben Newlin > > > > On 6/28/19, 10:16 AM, "Users on behalf of rob.d...@telus.net" wrote: > > Unfortunately the address of the interface where the request was > > receeived is private. I am using 1 to 1 NAT. > > > > - Original Message - > > From: "Ovidiu Sas" > > To: "OpenSIPS users mailling list" > > Sent: Thursday, June 27, 2019 3:31:34 PM > > Subject: Re: [OpenSIPS-Users] Feature request - pseudo-variable for > > destination IP address > > > > Check out the $Ri pvar: > > https://www.opensips.org/Documentation/Script-CoreVar-3-0#toc78 > > > > -ovidiu > > > > On Thu, Jun 27, 2019 at 6:23 PM rob.d...@telus.net wrote: > > > I was looking for something similar to the $si PV but for the > > > destination IP address. Either it doesn't exist or I am blind. I > > > can't find things in the refrigerator either. > > > > > > The motivation. > > > > > > I have a working instance of Opensips with a basic residential > > > configuration. I extended it to allow calling UAs on the LAN from > > > the outside. It is a typical residential LAN without a fixed IP > > > address. Dynamic DNS is working for me. I read the tutorial about > > > Opensips behind NAT. Following the recommendations there I was > > > able to setup rtpproxy, the advertised address and an alias for my > > > Opensips. Initial testing using a softphone on a laptop using > > > either WiFi or a mobile phone tethered to the laptop worked well. > > > However it seems that some UAs will not accept a domain name in > > > the SDP connection. The UAs that failed could be made to work by > > > coding in an IP address. This is not a satisfactory solution > > > because the router's address may chaange. There is probably some > > > convoluted way to import the needed address into the script. A > > > pseudo-variable representing the destination IP address of the > > > received INVITE or 200 OK could then be passed as the advertised > > > address to the rtpproxy module. > > > > > > Thank you for having a look. > > > Rob > > > > > > ___ > > > 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Feature request - pseudo-variable for destination IP address
Thank you Yuri Ritvin
{ip.resolve} transform works for me. The example given in the documentation is
misleading. You can't use a literal string. You need to put into a var of some
sort and then transform it.
On Thursday, June 27, 2019 3:35:37 P.M. PDT rob.d...@telus.net wrote:
> On second thought it probably isn't poosible to do in any direct way because
> the information is lost in the router. The only possible way is a DNS
> query.
>
> - Original Message -
> From: "rob dyck"
> To: users@lists.opensips.org
> Sent: Thursday, June 27, 2019 3:21:59 PM
> Subject: Feature request - pseudo-variable for destination IP address
>
> I was looking for something similar to the $si PV but for the destination IP
> address. Either it doesn't exist or I am blind. I can't find things in the
> refrigerator either.
>
> The motivation.
>
> I have a working instance of Opensips with a basic residential
> configuration. I extended it to allow calling UAs on the LAN from the
> outside. It is a typical residential LAN without a fixed IP address.
> Dynamic DNS is working for me. I read the tutorial about Opensips behind
> NAT. Following the recommendations there I was able to setup rtpproxy, the
> advertised address and an alias for my Opensips. Initial testing using a
> softphone on a laptop using either WiFi or a mobile phone tethered to the
> laptop worked well. However it seems that some UAs will not accept a domain
> name in the SDP connection. The UAs that failed could be made to work by
> coding in an IP address. This is not a satisfactory solution because the
> router's address may chaange. There is probably some convoluted way to
> import the needed address into the script. A pseudo-variable representing
> the destination IP address of the received INVITE or 200 OK could then be
> passed as the advertised address to the rtpproxy module.
>
> Thank you for having a look.
> Rob
>
> ___
> 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] Flush bad user data from from running opensips
So now I am confused. I am unable to reproduce the problem regardless of the
"use_domain"
setting. I even tried eliminating that line from the configuration ( that is
how it was originally )
and the client can register whether I had created the user as abc xyz or
abc@192.168.1.2 xyz. A
few days ago I reproduced it several times.
the line "DBG:auth_db:get_ha1: no result for user 'abc@'" no longer appears in
the debug.
For your curiosity here are my auth settings.
AUTHentication modules
On Thursday, November 15, 2018 5:50:08 AM PST Bogdan-Andrei Iancu wrote:
Hi Robert,So, the data in DB is ok, but the auth still fails -
please paste the exact
setting/modparams you have for the auth_db module along with the return
code provided by
the www_auth function - seehttp://www.opensips.org/html/docs/modules/2.4.x/
auth_db.html#func_www_authorize[1]
Bogdan-Andrei IancuOpenSIPS Founder and Developer
http://www.opensips-solutions.com[2]OpenSIPS Bootcamp 2018
http://opensips.org/training/
OpenSIPS_Bootcamp_2018/[3]
On 11/14/2018 08:03 PM, Robert Dyck wrote:
I added "modparam("auth_db", "use_domain", 1)" but it doesn't make a difference
to the
subscriber table.
On Wednesday, November 14, 2018 9:36:34 AM PST Robert Dyck wrote:
[root@slim opensips]# opensipsctl add abc xyz Updated subscriber, rows
affected: 1 *new user
'abc' added*
10:abc:localhost:xyz::
6c7faf173d3b8e26d95e7f26dd0388d6:e091cc8c08b19e1d50ee3891d3f37153:
[root@slim opensips]# opensipsctl rm abc Updated dbaliases, rows affected:
0[root@slim
opensips]# opensipsctl add abc@192.168.1.2[4] xyzUpdated
subscriber, rows
affected: 1 *new user '_abc@192.168.1.2_' added*
10:abc:192.168.1.2:xyz::
9ce761c3a9f328510ea011bd5c9bd2c5:cc312796ec331326cd537f3a3ffad7b6:
The difference being localhost vs 192.168.1.2
abc@ not found.
On Wednesday, November 14, 2018 8:59:10 AM PST Bogdan-Andrei Iancu wrote:
That's the whole idea - if the "use_domain" is on 0, OpenSIPS will
reference the users only
by username. So try "opensipsctl add abc xyz" and post what record you get
into the
subscriber table.Regards,
Bogdan-Andrei IancuOpenSIPS Founder and Developer
http://www.opensips-solutions.com[2]OpenSIPS Bootcamp 2018
http://opensips.org/training/
OpenSIPS_Bootcamp_2018/[3]
On 11/14/2018 06:52 PM, Robert Dyck wrote:
I do not have that parameter set and I do not use multiple domains.
The problem was that after I corrected the error ( missing domain ), opensips
continued to look
for abc@ rather than abc. I was looking for a graceful way to correct the
internal representation
of the user name. Restarting opensips is no problem on a small installation but
it is less than
ideal.
On Wednesday, November 14, 2018 6:11:52 AM PST Bogdan-Andrei Iancu wrote:
Hi Robert,Do you have the "use_domain" parameter enabled in the
auth_db module
?
http://www.opensips.org/html/docs/modules/2.4.x/auth_db.html#param_use_domain[5]
Regards,
Bogdan-Andrei IancuOpenSIPS Founder and Developer
http://www.opensips-solutions.com[2]OpenSIPS Bootcamp 2018
http://opensips.org/training/
OpenSIPS_Bootcamp_2018/[3]
On 11/07/2018 04:30 AM, Robert Dyck wrote:
I have updated my small test bed from 2.3.2 to 2.4.2. I didn't bother to back
up the 'subscriber"
table and it was wiped by the installation. No big deal, it was tiny.
So I added the users but made an error.
opensipsctl add abc xyz -- I didn't specify the domain. The UAC would not
register.
I corrected the user.
opensipsctl rm abc, opensipsctl add abc@192.168.1.2[4] xyz
The UAC still cannot register.
DBG:auth_db:get_ha1: no result for user 'abc@'
Opensips is restarted and the UAC registers.
Restaring a production machine is problematic. Is there a way to flush the bad
data which I
assume has been cached?
Some error checking in opensipsctl or the DB interface would be helpful.
Thanks for your time and the product.
Rob
___Users mailing
listus...@lists.opensips.org[6]http://lists.opensips.org/cgi-bin/mailman/listinfo/users[7]
[1
Re: [OpenSIPS-Users] Flush bad user data from from running opensips
I added "modparam("auth_db", "use_domain", 1)" but it doesn't make a difference
to the
subscriber table.
On Wednesday, November 14, 2018 9:36:34 AM PST Robert Dyck wrote:
[root@slim opensips]# opensipsctl add abc xyz
*new user 'abc' added*
10:abc:localhost:xyz::
6c7faf173d3b8e26d95e7f26dd0388d6:e091cc8c08b19e1d50ee3891d3f37153:
[root@slim opensips]# opensipsctl rm abc
[root@slim opensips]# opensipsctl add abc@192.168.1.2 xyz
*new user 'abc@192.168.1.2' added*
10:abc:192.168.1.2:xyz::
9ce761c3a9f328510ea011bd5c9bd2c5:cc312796ec331326cd537f3a3ffad7b6:
The difference being localhost vs 192.168.1.2
abc@ not found.
On Wednesday, November 14, 2018 8:59:10 AM PST Bogdan-Andrei Iancu wrote:
That's the whole idea - if the "use_domain" is on 0, OpenSIPS will
reference the users only
by username. So try "opensipsctl add abc xyz" and post what record you get
into the
subscriber table.Regards,
Bogdan-Andrei IancuOpenSIPS Founder and Developer
http://www.opensips-solutions.com[1]OpenSIPS Bootcamp 2018
http://opensips.org/training/
OpenSIPS_Bootcamp_2018/[2]
On 11/14/2018 06:52 PM, Robert Dyck wrote:
I do not have that parameter set and I do not use multiple domains.
The problem was that after I corrected the error ( missing domain ), opensips
continued to look
for abc@ rather than abc. I was looking for a graceful way to correct the
internal representation
of the user name. Restarting opensips is no problem on a small installation but
it is less than
ideal.
On Wednesday, November 14, 2018 6:11:52 AM PST Bogdan-Andrei Iancu wrote:
Hi Robert,Do you have the "use_domain" parameter enabled in the
auth_db module
?
http://www.opensips.org/html/docs/modules/2.4.x/auth_db.html#param_use_domain[3]
Regards,
Bogdan-Andrei IancuOpenSIPS Founder and Developer
http://www.opensips-solutions.com[1]OpenSIPS Bootcamp 2018
http://opensips.org/training/
OpenSIPS_Bootcamp_2018/[2]
On 11/07/2018 04:30 AM, Robert Dyck wrote:
I have updated my small test bed from 2.3.2 to 2.4.2. I didn't bother to back
up the 'subscriber"
table and it was wiped by the installation. No big deal, it was tiny.
So I added the users but made an error.
opensipsctl add abc xyz -- I didn't specify the domain. The UAC would not
register.
I corrected the user.
opensipsctl rm abc, opensipsctl add abc@192.168.1.2[4] xyz
The UAC still cannot register.
DBG:auth_db:get_ha1: no result for user 'abc@'
Opensips is restarted and the UAC registers.
Restaring a production machine is problematic. Is there a way to flush the bad
data which I
assume has been cached?
Some error checking in opensipsctl or the DB interface would be helpful.
Thanks for your time and the product.
Rob
___Users mailing
listus...@lists.opensips.org[5]http://lists.opensips.org/cgi-bin/mailman/listinfo/users[6]
[1] http://www.opensips-solutions.com
[2] http://opensips.org/training/OpenSIPS_Bootcamp_2018/
[3]
http://www.opensips.org/html/docs/modules/2.4.x/auth_db.html#param_use_domain
[4] mailto:abc@192.168.1.2
[5] mailto:Users@lists.opensips.org
[6] 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] GRUU contact not found
I started with the sample residential script from some time back. GRUU was enabled in the sample. When I started working with a UA that registers a GRUU I noticed it was not receiving BYE when the other end released the call. I have since experimented with checking for GRUU while in dialog. That seems to work. The documentation doesn't mention anything about modifying the script other than enabling or disabling GRUU. Do you have any tips regarding GRUU in the script? Are there corner cases I should be aware of? Rob On Wednesday, November 14, 2018 6:14:20 AM PST Bogdan-Andrei Iancu wrote: Hi Robert,According to docs, the gruu is by default off - seehttp://www.opensips.org/ html/docs/modules/2.3.x/registrar.html#idp5567984[1] Bogdan-Andrei IancuOpenSIPS Founder and Developer http://www.opensips-solutions.com[2]OpenSIPS Bootcamp 2018 http://opensips.org/training/ OpenSIPS_Bootcamp_2018/[3] On 11/07/2018 10:09 PM, Robert Dyck wrote: My understanding is that GRUU processing in opensips is automatic, provided it is not disabled. No further configuration or scripting is required. Is that correct. A GRUU capable UA rergisters and receives public and temporary GR identities. The UA establishes a dialog with another UA. The callee ends the call. The caller does not recive the BYE. Caller : Request-Line: INVITE sip:7@192.168.1.2[4] SIP/2.0 Contact URI: sip:4@192.168.1.2:5060;gr=urn:uuid:35dfa98a-2feb-482a-bde7-7568a86348b1[5] Callee: Status-Line: SIP/2.0 200 OK Caller: Request-Line: ACK sip:7@192.168.1.3:5062[6] SIP/2.0 Callee: Request-Line: BYE sip:4@192.168.1.2:5060;gr=urn:uuid:35dfa98a-2feb-482a- bde7-7568a86348b1[5] SIP/2.0 Proxy ( opensips @ 192.168.1.2 ) Status-Line: SIP/2.0 404 Not here Am I missing something? Should "opensipsctl ul show" show the GRUU? AOR:: 4 Contact:: sip:4@192.168.1.72:5062;transport=udp[7] Q= ContactID:: 3518589640418194Expires:: 3586Callid:: OL1gvsViBJCseq:: 21 User-agent:: LinphoneAndroid/4.0.1 (belle-sip/1.6.3) State:: CS_NEW Flags:: 0Cflags:: Socket:: udp:192.168.1.2:5060 Methods:: 4294967295SIP_instance:: ___Users mailing listus...@lists.opensips.org[8]http://lists.opensips.org/cgi-bin/mailman/listinfo/users[9] [1] http://www.opensips.org/html/docs/modules/2.3.x/registrar.html#idp5567984 [2] http://www.opensips-solutions.com [3] http://opensips.org/training/OpenSIPS_Bootcamp_2018/ [4] sip:7@192.168.1.2 [5] sip:4@192.168.1.2:5060;gr=urn:uuid:35dfa98a-2feb-482a-bde7-7568a86348b1 [6] sip:7@192.168.1.3:5062 [7] sip:4@192.168.1.72:5062;transport=udp [8] mailto:Users@lists.opensips.org [9] 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] Flush bad user data from from running opensips
I do not have that parameter set and I do not use multiple domains. The problem was that after I corrected the error ( missing domain ), opensips continued to look for abc@ rather than abc. I was looking for a graceful way to correct the internal representation of the user name. Restarting opensips is no problem on a small installation but it is less than ideal. On Wednesday, November 14, 2018 6:11:52 AM PST Bogdan-Andrei Iancu wrote: Hi Robert,Do you have the "use_domain" parameter enabled in the auth_db module ? http://www.opensips.org/html/docs/modules/2.4.x/auth_db.html#param_use_domain[1] Bogdan-Andrei IancuOpenSIPS Founder and Developer http://www.opensips-solutions.com[2]OpenSIPS Bootcamp 2018 http://opensips.org/training/ OpenSIPS_Bootcamp_2018/[3] On 11/07/2018 04:30 AM, Robert Dyck wrote: I have updated my small test bed from 2.3.2 to 2.4.2. I didn't bother to back up the 'subscriber" table and it was wiped by the installation. No big deal, it was tiny. So I added the users but made an error. opensipsctl add abc xyz -- I didn't specify the domain. The UAC would not register. I corrected the user. opensipsctl rm abc, opensipsctl add abc@192.168.1.2[4] xyz The UAC still cannot register. DBG:auth_db:get_ha1: no result for user 'abc@' Opensips is restarted and the UAC registers. Restaring a production machine is problematic. Is there a way to flush the bad data which I assume has been cached? Some error checking in opensipsctl or the DB interface would be helpful. Thanks for your time and the product. Rob ___Users mailing listus...@lists.opensips.org[5]http://lists.opensips.org/cgi-bin/mailman/listinfo/users[6] [1] http://www.opensips.org/html/docs/modules/2.4.x/auth_db.html#param_use_domain [2] http://www.opensips-solutions.com [3] http://opensips.org/training/OpenSIPS_Bootcamp_2018/ [4] mailto:abc@192.168.1.2 [5] mailto:Users@lists.opensips.org [6] 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] check for NULL values
Just a guess. Try
if $tu {remove("location","$tu");}
Not tested. A nonzero value may evaluate as TRUE.
On Tuesday, November 13, 2018 12:56:42 AM PST Pasan Meemaduma via Users wrote:
Hey,
Anyone have a suggestion for this?
On Thursday, 8 November 2018, 8:09:50 AM GMT+5:30, Pasan Meemaduma
wrote:
ERROR:core:comp_scriptvar: cannot get left var value
WARNING:core:do_action: error in expression at /etc/opensips/opensips.cfg:806
and line 806 contains following.
if ( $tu != NULL ) {remove("location","$tu");}
any suggestion on how to test for NULL values without getting above error. I'm
using opensips
2.3.5
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] GRUU contact not found
After some thought I realized that a lookup had to be invoked while in dialog.
The BYE was
directed at the proxy and the GRUU needed to be mapped to the device that was
the intended
target.
Added the following to script for "in dialog"
xlog("Check for GRUU, Method is $rm\n");
Nov 8 11:49:30 [24807] DBG:rr:after_loose: Topmost route URI: 'sip:
192.168.1.2;lr;ftag=SAjVc2sqm' is me
Nov 8 11:49:30 [24807] DBG:core:parse_headers: flags=200
Nov 8 11:49:30 [24807] DBG:core:get_hdr_field: cseq : <252>
Nov 8 11:49:30 [24807] DBG:core:get_hdr_field: content_length=0
Nov 8 11:49:30 [24807] DBG:core:get_hdr_field: found end of header
Nov 8 11:49:30 [24807] DBG:rr:find_next_route: No next Route HF found
Nov 8 11:49:30 [24807] DBG:rr:after_loose: No next URI found!
Nov 8 11:49:30 [24807] DBG:core:parse_headers: flags=78
Nov 8 11:49:30 [24807] DBG:core:parse_to_param: tag=uqzwj
Nov 8 11:49:30 [24807] DBG:core:_parse_to: end of header reached, state=29
Nov 8 11:49:30 [24807] DBG:core:_parse_to: display={}, ruri={sip:7@192.168.1.2}
Nov 8 11:49:30 [24807] DBG:rr:check_route_param: params are
<;lr;ftag=SAjVc2sqm>
Nov 8 11:49:30 [24807] DBG:rr:check_route_param: params are
<;lr;ftag=SAjVc2sqm>
Nov 8 11:49:30 [24807] Check for GRUU, Method is BYE
Nov 8 11:49:30 [24807] Found GRUU
Nov 8 11:49:30 [24807] DBG:registrar:parse_lookup_flags: final flags: 1
Nov 8 11:49:30 [24807] DBG:registrar:extract_aor: has gruu
Nov 8 11:49:30 [24807] DBG:registrar:extract_aor: public gruu
Nov 8 11:49:30 [24807] DBG:registrar:select_contacts: ct: sip:
4@192.168.1.72:5062;transport=udp
Nov 8 11:49:30 [24807] DBG:registrar:select_contacts: ruri has gruu
Nov 8 11:49:30 [24807] DBG:registrar:select_contacts: matched sip instance
Nov 8 11:49:30 [24807] DBG:registrar:push_branch: setting as ruri
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] test - please ignore
___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] GRUU contact not found
My understanding is that GRUU processing in opensips is automatic, provided it is not disabled. No further configuration or scripting is required. Is that correct. A GRUU capable UA rergisters and receives public and temporary GR identities. The UA establishes a dialog with another UA. The callee ends the call. The caller does not recive the BYE. Caller : Request-Line: INVITE sip:7@192.168.1.2 SIP/2.0 Contact URI: sip:4@192.168.1.2:5060;gr=urn:uuid:35dfa98a-2feb-482a-bde7-7568a86348b1 Callee: Status-Line: SIP/2.0 200 OK Caller: Request-Line: ACK sip:7@192.168.1.3:5062 SIP/2.0 Callee: Request-Line: BYE sip:4@192.168.1.2:5060;gr=urn:uuid:35dfa98a-2feb-482a- bde7-7568a86348b1 SIP/2.0 Proxy ( opensips @ 192.168.1.2 ) Status-Line: SIP/2.0 404 Not here Am I missing something? Should "opensipsctl ul show" show the GRUU? AOR:: 4 Contact:: sip:4@192.168.1.72:5062;transport=udp Q= ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Flush bad user data from from running opensips
I have updated my small test bed from 2.3.2 to 2.4.2. I didn't bother to back up the 'subscriber" table and it was wiped by the installation. No big deal, it was tiny. So I added the users but made an error. opensipsctl add abc xyz -- I didn't specify the domain. The UAC would not register. I corrected the user. opensipsctl rm abc, opensipsctl add abc@192.168.1.2 xyz The UAC still cannot register. DBG:auth_db:get_ha1: no result for user 'abc@' Opensips is restarted and the UAC registers. Restaring a production machine is problematic. Is there a way to flush the bad data which I assume has been cached? Some error checking in opensipsctl or the DB interface would be helpful. Thanks for your time and the product. Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Auth parameter disable_nonce_check not working as expected
I have to accept that I cannot work around the UA's bug. A strange bug that only manifests itself after an hour or so. The servers say the nonce is stale when in fact the UA presents a nonce of its own invention even changing the number of characters in the nonce. Thank you for your time Rob On Wednesday, January 10, 2018 1:14:22 AM PST Bogdan-Andrei Iancu wrote: > Hi Robert, > > Yes, it is exactly what I understood :). Again, if the nonce is expired > (too old - see nonce_expire - > http://www.opensips.org/html/docs/modules/2.3.x/auth.html#idp185504), > there is no way to force its acceptance. OpenSIPS will reject it as > stale (even if there is correct auth answer). > > The disable_nonce_check parameter > (http://www.opensips.org/html/docs/modules/2.3.x/auth.html#idp5552944) > is exclusively for nonce re-usage. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >http://www.opensips-solutions.com > OpenSIPS Summit 2018 >http://www.opensips.org/events/Summit-2018Amsterdam > > On 01/09/2018 05:53 PM, Robert Dyck wrote: > > Let me rephrase. The UA receives a 401 message from opensip. The nonce is > > reported as stale. The UA attempts again to register using the same nonce > > as previously. On and on. I calculated the digest myself and it is > > correct for the stale nonce. My thinking is that if opensips ignored the > > fact that the nonce has expired then register should succeed. > > > > On Tuesday, January 9, 2018 6:39:04 AM PST Bogdan-Andrei Iancu wrote: > >> Hi Rob, > >> > >> A "reused" and a "stale" nonce are different things. A reused one means > >> that same nonce is to be used for multiple auth attempts. A stale nonce > >> means the nonce (used or not) is rejected as it is too old (relative to > >> the time when the nonce was generated by the server). > >> > >> Of course, the stale check is first perform (and mandatory). After that > >> (according to disable_nonce_check option) the nonce re-usage is checked. > >> > >> Regards, > >> > >> Bogdan-Andrei Iancu > >> > >> OpenSIPS Founder and Developer > >> > >> http://www.opensips-solutions.com > >> > >> OpenSIPS Summit 2018 > >> > >> http://www.opensips.org/events/Summit-2018Amsterdam > >> > >> On 01/08/2018 08:36 PM, Robert Dyck wrote: > >>> Using opensips 2.3.2 compiled from source > >>> > >>> I have a buggy UA that insists on reusing a stale nonce. I tried to > >>> work around it by setting disable_nonce_check. It didn't work for me. > >>> Am I misunderstanding the purpose of the parameter or is this an > >>> opensips bug? > >>> > >>> Jan 8 09:46:19 [11380] DBG:core:set_mod_param_regex: found > >>> in module auth [/usr/lib64/opensips/modules/] > >>> > >>> Rob > >>> > >>> > >>> > >>> ___ > >>> 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] Auth parameter disable_nonce_check not working as expected
Let me rephrase. The UA receives a 401 message from opensip. The nonce is reported as stale. The UA attempts again to register using the same nonce as previously. On and on. I calculated the digest myself and it is correct for the stale nonce. My thinking is that if opensips ignored the fact that the nonce has expired then register should succeed. On Tuesday, January 9, 2018 6:39:04 AM PST Bogdan-Andrei Iancu wrote: > Hi Rob, > > A "reused" and a "stale" nonce are different things. A reused one means > that same nonce is to be used for multiple auth attempts. A stale nonce > means the nonce (used or not) is rejected as it is too old (relative to > the time when the nonce was generated by the server). > > Of course, the stale check is first perform (and mandatory). After that > (according to disable_nonce_check option) the nonce re-usage is checked. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >http://www.opensips-solutions.com > OpenSIPS Summit 2018 >http://www.opensips.org/events/Summit-2018Amsterdam > > On 01/08/2018 08:36 PM, Robert Dyck wrote: > > Using opensips 2.3.2 compiled from source > > > > I have a buggy UA that insists on reusing a stale nonce. I tried to > > work around it by setting disable_nonce_check. It didn't work for me. > > Am I misunderstanding the purpose of the parameter or is this an > > opensips bug? > > > > Jan 8 09:46:19 [11380] DBG:core:set_mod_param_regex: found > > in module auth [/usr/lib64/opensips/modules/] > > > > Rob > > > > > > > > ___ > > 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] Auth parameter disable_nonce_check not working as expected
Using opensips 2.3.2 compiled from source I have a buggy UA that insists on reusing a stale nonce. I tried to work around it by setting disable_nonce_check. It didn't work for me. Am I misunderstanding the purpose of the parameter or is this an opensips bug? Jan 8 09:46:19 [11380] DBG:core:set_mod_param_regex: found in module auth [/usr/lib64/opensips/ modules/] Rob ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Install opensips to systemd
I had a working opensips 1.11 installed by Fedora package manager. I have been trying opensips 2.2.2 and decided to make the jump. Since 2.2.2 is not available as a package from Fedora I cloned the source. I have tried installing using menuconfig and also make but neither installs the necessary files for systemd. I see that the files exist in the source directory "packaging". Is there a way to trigger the installation of the necessary files for systemd or does it need to be done manually. I have thought of re-installing 1.11 from the package manager and then overwriting the opensips binary. The problem I see is that a package upgrade would overwrite 2.2.2 because the package manager sees opensips as an installed package. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Ipv6 on non-default port not working
I am embarrassed to say that I created my own problem. I had forgotten some of the details of my firewall configuration. Iptables was set to allow everything from the LAN, that is to say 192.168.0.0. Ip6tables was not set that way because the hosts on the LAN had global addresses. To allow SIP incoming from outside I had allowed port 5060 in both iptables and ip6tables. For port 5062 in IPV6 I need to allow it regardless whether the request originated on the LAN or not. If I had been testing with a remote site, I probably would have tweaked the firewall at the start. Note to self -- When in doubt, briefly disable the firewall and try again. Thank you On December 15, 2016 02:36:43 PM Bogdan-Andrei Iancu wrote: > Hi Robert, > > As the waiting queue (on the socket) is 0, there are 2 options: > > 1) packets are not delivered to the socket (firewall??) > 2) packets are actually read by OpenSIPS (run with log_level 4 to see if > you get any kind of logs). > > If the packets were put on the socket, but OpenSIPS does not read them > -> you should see the IN queue size higher than 0. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 07.12.2016 22:43, Robert Dyck wrote: > > Actually when I was testing I entered the listen parameters on the command > > line. I have now added them to the configuration file. The result is the > > same. The UA keeps sending the REGISTER request but there is no response > > from opensips. A UA on IPV4 can register on port 5062. > > > > The configuration file I am using was taken from the rtpproxy modules > > examples. It was out of date so I had to add the UDP protocol and also > > change each instance of "break" to "exit". > > > > [root@slim src]# opensips -V > > version: opensips 2.2.2 (x86_64/linux) > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > > F_MALLOC, > > FAST_LOCK-ADAPTIVE_WAIT > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > > git revision: d250e1c > > main.c compiled on 15:03:38 Nov 30 2016 with gcc 6.2.1 > > > > > > [root@slim src]# netstat -ulnp | grep opensips > > udp0 0 192.168.1.1:50620.0.0.0:* > > 10036/opensips > > udp6 0 0 fd00::223:7dff:feb:5062 :::* > > 10036/opensips > > > > listen=udp:192.168.1.1:5062 > > listen=udp:[fd00::223:7dff:feb8:d2b4]:5062 > > > > On December 7, 2016 09:14:53 PM Bogdan-Andrei Iancu wrote: > >> Hello Robert, > >> > >> Please post the "listen" lines you have in cfg and the output of > >> "netstat -ulnp | grep opensips" . > >> > >> Best regards, > >> > >> Bogdan-Andrei Iancu > >> OpenSIPS Founder and Developer > >> http://www.opensips-solutions.com > >> > >> On 05.12.2016 21:37, Robert Dyck wrote: > >>> This is a re-send. I apologize if it is a duplicate. I suspect my > >>> subscription was not enabled. > >>> > >>> > >>> -- > >>> > >>> > >>> I have been doing some testing with opensips 2.2.2 using ipv6. I found > >>> that > >>> the server will only respond to a request over IPV6 if it is configured > >>> to > >>> listen on the default port. > >>> > >>> Wireshark sees a request addressed to the server but there is no reply. > >>> > >>> Running opensips in the foreground show no activity associated with a > >>> request. > >>> > >>> Netstat however shows the listening port. ( UDP 5062 ) > >>> > >>> Tried with global address and ULA. > >>> > >>> IPv4 works with non-default port. > >>> > >>> ___ > >>> 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] Ipv6 on non-default port not working
Actually when I was testing I entered the listen parameters on the command line. I have now added them to the configuration file. The result is the same. The UA keeps sending the REGISTER request but there is no response from opensips. A UA on IPV4 can register on port 5062. The configuration file I am using was taken from the rtpproxy modules examples. It was out of date so I had to add the UDP protocol and also change each instance of "break" to "exit". [root@slim src]# opensips -V version: opensips 2.2.2 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. git revision: d250e1c main.c compiled on 15:03:38 Nov 30 2016 with gcc 6.2.1 [root@slim src]# netstat -ulnp | grep opensips udp0 0 192.168.1.1:50620.0.0.0:* 10036/opensips udp6 0 0 fd00::223:7dff:feb:5062 :::* 10036/opensips listen=udp:192.168.1.1:5062 listen=udp:[fd00::223:7dff:feb8:d2b4]:5062 On December 7, 2016 09:14:53 PM Bogdan-Andrei Iancu wrote: > Hello Robert, > > Please post the "listen" lines you have in cfg and the output of > "netstat -ulnp | grep opensips" . > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 05.12.2016 21:37, Robert Dyck wrote: > > This is a re-send. I apologize if it is a duplicate. I suspect my > > subscription was not enabled. > > > > -- > > > > > > I have been doing some testing with opensips 2.2.2 using ipv6. I found > > that > > the server will only respond to a request over IPV6 if it is configured to > > listen on the default port. > > > > Wireshark sees a request addressed to the server but there is no reply. > > > > Running opensips in the foreground show no activity associated with a > > request. > > > > Netstat however shows the listening port. ( UDP 5062 ) > > > > Tried with global address and ULA. > > > > IPv4 works with non-default port. > > > > ___ > > 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] Ipv6 on non-default port not working
This is a re-send. I apologize if it is a duplicate. I suspect my subscription was not enabled. -- I have been doing some testing with opensips 2.2.2 using ipv6. I found that the server will only respond to a request over IPV6 if it is configured to listen on the default port. Wireshark sees a request addressed to the server but there is no reply. Running opensips in the foreground show no activity associated with a request. Netstat however shows the listening port. ( UDP 5062 ) Tried with global address and ULA. IPv4 works with non-default port. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Ipv6 on non-default port not working
I have been doing some testing with opensips 2.2.2 using ipv6. I found that the server will only respond to a request over IPV6 if it is configured to listen on the default port. Wireshark sees a request addressed to the server but there is no reply. Running opensips in the foreground show no activity associated with a request. Netstat however shows the listening port. ( UDP 5062 ) Tried with global address and ULA. IPv4 works with non-default port. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Rtpproxy and IPV4 IPV6 interworking
Thank you Assuming rtpproxy was started with IPV4 as the first address and IPV6 as the second, then in the NAT scenario, are the II flags mandatory in offer/answer? Slightly off topic, what sort of scenario would require the address parameter for offer/answer? On November 8, 2016 09:57:30 AM Răzvan Crainea wrote: > Hi, Robert! > > See my answers inline. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/08/2016 02:15 AM, Robert Dyck wrote: > > I have some question regarding rtpproxy capabilities in relation to > > IPV4-IPV6 interworking. > > > > The articles I have read say that you need to assign an address from each > > address family to rtpproxy. They go on to say that rtpproxy will then be > > in > > bridged mode. Others define bridge mode as assigning two interfaces to > > rtpproxy. > > As long as you have RTPProxy listening on two IPs, you have it set in > bridge mode. It doesn't matther whether one of them is IPv6, or both are. > > > If the IPV4 and IPV6 addresses are on the same interface, is the rtpproxy > > indeed in bridged mode? Should one avoid the use of engage_rtpproxy? > > Yes, as stated above, RTPProxy is in bridged mode and you should avoid > using engage_rtpproxy(). That's because the function can't know/decide > which interface is which and cannot map with the RTPProxy's one. > > > Assuming that IPV4- IPV6 interworking is actually possible using opensips > > and rtpproxy, does that mean that an instance of rtpproxy is not > > available to enable NAT traversal - would NAT traversal require using > > another instance of rtpproxy using a single IPV4 address? > > No, you don't need an extra instance - a single instance will do both > bridging and nat traversal. > > > Furthermore is the multihome parameter relevant to IPV4-IPV6 interworking > > if opensips only listens on one interface? > > The multihome parameter is only relevant for OpenSIPS, it doesn't > influence RTPProxy's behavior at all. > > ___ > 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] Rtpproxy and IPV4 IPV6 interworking
I have some question regarding rtpproxy capabilities in relation to IPV4-IPV6 interworking. The articles I have read say that you need to assign an address from each address family to rtpproxy. They go on to say that rtpproxy will then be in bridged mode. Others define bridge mode as assigning two interfaces to rtpproxy. If the IPV4 and IPV6 addresses are on the same interface, is the rtpproxy indeed in bridged mode? Should one avoid the use of engage_rtpproxy? Assuming that IPV4- IPV6 interworking is actually possible using opensips and rtpproxy, does that mean that an instance of rtpproxy is not available to enable NAT traversal - would NAT traversal require using another instance of rtpproxy using a single IPV4 address? Furthermore is the multihome parameter relevant to IPV4-IPV6 interworking if opensips only listens on one interface? Thank you all ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] How to ensure current IPV6 listening address
I am reluctant to take out a github membership to simply request a feature. Perhaps someone with an existing membership could request the feature. Opensips currently is unable to detect the IPV6 address of an interface when given the interface name in the configuration. This is a request to implement that capability. On October 26, 2016 04:20:23 PM Răzvan Crainea wrote: > Hi, Robert! > > After further documenting, it seems that linux can only provide IPv4 > interfaces (for more info, see [1], check for SIOCGIFCONF). In order to > support IPv6, we need to find a different way to get the addresses. > Please open a feature request on our tracker[2], and we will check how > to support this. > > [1] https://linux.die.net/man/7/netdevice > [2] https://github.com/OpenSIPS/opensips/issues > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 10/20/2016 02:21 PM, Bogdan-Andrei Iancu wrote: > > Hi Robert, > > > > If you use in the listener definition the name of an interface, it > > should detect IPV6 too. Is this working ? > > > > Regards, > > > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > > http://www.opensips-solutions.com > > > > On 20.10.2016 00:35, Robert Dyck wrote: > >> Thanks for your input. The second scenario doesn't appear to be an > >> issue. > >> > >> If opensips can detect the IPV4 address on an interface should it > >> > >> be only a > >> minor enhancement to detect the IPV6 address? > >> > >> On October 19, 2016 11:09:50 PM Bogdan-Andrei Iancu wrote: > >>> Hi Robert, > >>> > >>> I see here two aspects: > >>> > >>> 1) how to determine the IP at OpenSIPS startup - you need to perform > >>> the > >>> IPv6 detection in a pre-start script and feed it to OpenSIPS. That is > >>> the way it should be > >>> > >>> 2) if the IP changes during runtime, there is nothing you can do rather > >>> then restarting - OpenSIPS cannot change listeners during runtime. > >>> > >>> Regards, > >>> > >>> Bogdan-Andrei Iancu > >>> OpenSIPS Founder and Developer > >>> http://www.opensips-solutions.com > >>> > >>> On 19.10.2016 19:14, Robert Dyck wrote: > >>>> Using 1.10.5 > >>>> My ISP provides an IPV6 prefix which unfortunately is not static. My > >>>> address does not change spontaneously but if the host is down for a > >>>> significant time the address will change. > >>>> > >>>> I thought it would be simply solved by specifying a listening > >>>> interface in > >>>> the configuration file. Unfortunately that only picks up the IPV4 > >>>> address. > >>>> > >>>> I have a DDNS provider and I can specify a domain name in the > >>>> configuration but my concern is that the address bound to the > >>>> domain name > >>>> may be stale at the moment that opensips comes up. Does opensips > >>>> verify > >>>> an address obtained through DNS? > >>>> > >>>> ___ > >>>> 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] How to ensure current IPV6 listening address
Thank you for investigating this. To improve the chance of Opensips getting the current IP address from the FQDN I employed the NetworkManager dispatcher to send an immediate update to the name server. I am sure that one could parse the output of 'ip addr" and somehow update opensips.cfg but bash scripts are a mystery to me. On October 26, 2016 04:20:23 PM Răzvan Crainea wrote: > Hi, Robert! > > After further documenting, it seems that linux can only provide IPv4 > interfaces (for more info, see [1], check for SIOCGIFCONF). In order to > support IPv6, we need to find a different way to get the addresses. > Please open a feature request on our tracker[2], and we will check how > to support this. > > [1] https://linux.die.net/man/7/netdevice > [2] https://github.com/OpenSIPS/opensips/issues > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 10/20/2016 02:21 PM, Bogdan-Andrei Iancu wrote: > > Hi Robert, > > > > If you use in the listener definition the name of an interface, it > > should detect IPV6 too. Is this working ? > > > > Regards, > > > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > > http://www.opensips-solutions.com > > > > On 20.10.2016 00:35, Robert Dyck wrote: > >> Thanks for your input. The second scenario doesn't appear to be an > >> issue. > >> > >> If opensips can detect the IPV4 address on an interface should it > >> > >> be only a > >> minor enhancement to detect the IPV6 address? > >> > >> On October 19, 2016 11:09:50 PM Bogdan-Andrei Iancu wrote: > >>> Hi Robert, > >>> > >>> I see here two aspects: > >>> > >>> 1) how to determine the IP at OpenSIPS startup - you need to perform > >>> the > >>> IPv6 detection in a pre-start script and feed it to OpenSIPS. That is > >>> the way it should be > >>> > >>> 2) if the IP changes during runtime, there is nothing you can do rather > >>> then restarting - OpenSIPS cannot change listeners during runtime. > >>> > >>> Regards, > >>> > >>> Bogdan-Andrei Iancu > >>> OpenSIPS Founder and Developer > >>> http://www.opensips-solutions.com > >>> > >>> On 19.10.2016 19:14, Robert Dyck wrote: > >>>> Using 1.10.5 > >>>> My ISP provides an IPV6 prefix which unfortunately is not static. My > >>>> address does not change spontaneously but if the host is down for a > >>>> significant time the address will change. > >>>> > >>>> I thought it would be simply solved by specifying a listening > >>>> interface in > >>>> the configuration file. Unfortunately that only picks up the IPV4 > >>>> address. > >>>> > >>>> I have a DDNS provider and I can specify a domain name in the > >>>> configuration but my concern is that the address bound to the > >>>> domain name > >>>> may be stale at the moment that opensips comes up. Does opensips > >>>> verify > >>>> an address obtained through DNS? > >>>> > >>>> ___ > >>>> 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] How to ensure current IPV6 listening address
Thanks for your input. The second scenario doesn't appear to be an issue. If opensips can detect the IPV4 address on an interface should it be only a minor enhancement to detect the IPV6 address? On October 19, 2016 11:09:50 PM Bogdan-Andrei Iancu wrote: > Hi Robert, > > I see here two aspects: > > 1) how to determine the IP at OpenSIPS startup - you need to perform the > IPv6 detection in a pre-start script and feed it to OpenSIPS. That is > the way it should be > > 2) if the IP changes during runtime, there is nothing you can do rather > then restarting - OpenSIPS cannot change listeners during runtime. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 19.10.2016 19:14, Robert Dyck wrote: > > Using 1.10.5 > > My ISP provides an IPV6 prefix which unfortunately is not static. My > > address does not change spontaneously but if the host is down for a > > significant time the address will change. > > > > I thought it would be simply solved by specifying a listening interface in > > the configuration file. Unfortunately that only picks up the IPV4 > > address. > > > > I have a DDNS provider and I can specify a domain name in the > > configuration but my concern is that the address bound to the domain name > > may be stale at the moment that opensips comes up. Does opensips verify > > an address obtained through DNS? > > > > ___ > > 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] How to ensure current IPV6 listening address
Using 1.10.5 My ISP provides an IPV6 prefix which unfortunately is not static. My address does not change spontaneously but if the host is down for a significant time the address will change. I thought it would be simply solved by specifying a listening interface in the configuration file. Unfortunately that only picks up the IPV4 address. I have a DDNS provider and I can specify a domain name in the configuration but my concern is that the address bound to the domain name may be stale at the moment that opensips comes up. Does opensips verify an address obtained through DNS? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] nat_traversal fails on loose_route ACK
Maybe before fiddling with the contact make sure you are not being hit by a
bug in some versions of asterisk. The re-invite arrived OK but not the ACK.
Was the route set present in the ACK. In-dialog messages should not alter the
route set. The UAS is not required to send a route header in the reply while
in-dialog. The UAC should not interpret this as a null route set and must use
the route set already established. Private addresses can be reached this way.
On Friday 10 July 2009, Jeff Pyle wrote:
¡Easy indeed! I didn't have any NAT intelligence in the reply route.
Here's what I tried first:
onreply_route[1] {
if (client_nat_test(3)) {
xlog(L_INFO, NAT Reply\n);
fix_contact();
} else {
xlog(L_INFO, Reply\n);
}
}
This appeared to work a bit too well. The client_nat_test returned true
even for non-NAT'd hosts. I changed the test from 3 to 1 and it seems
to be behaving as expected.
None of the examples seem to use the number 4 private IP address in the
top Via field test. Is there any particular reason for that? In my
searches I haven't come across a discussion on the pros and cons of the
various tests.
- Jeff
On 7/10/09 5:03 PM, Iñaki Baz Castillo i...@aliax.net wrote:
Easy: you must ensure that the proxy performs NAT detection for reply
routes (onreply_route) for in-dialog requests, and fix the Contact
(fix_contact()) in onreply_route.
This is:
- The UA sends INVITE behind NAT.
- OpenSIPS fixed Contact and routes it to Asterisk.
- Asterisk replies 200 = proxy = UA.
- UA sends ACK = proxy = Asterisk.
- Now Asterisk sends re-INVITE (in-dialog request) to the proxy.
- The proxy routes it to UA.
- UA replies 200.
- Proxy *fixes Contact* for the 200 and routes to Asterisk.
- Asterisk now will send ACK to proxy with RURI containing the fixed
Contact address (UA's public IP:port).
___
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 ALG
I like the idea that we could maintain a local registrar that accurately reflects the remote registration. I would go so far as to say that it would be useful to be able to optimize opensips as an ALG. Some people could use a proxy as an edge device on a LAN. You could have several phones with the same user name register with a service provider. Some service providers limit the number of contacts per AOR. This would have the side effect of keeping the signaling associated with forking on the LAN. By detecting local calls, media could also be kept on the LAN. Such an edge device might have a dynamic IP address. It would be helpful if opensips could conveniently be setup to fix the contacts. Using the received address does not work when the phones are on the same LAN as the proxy. Opensips has a bias toward service providers. This is quite understandable. However I feel with a bit of tweaking it could serve as an ALG for the home owner or a small business. On Wednesday 13 May 2009, Bogdan-Andrei Iancu wrote: Hi Jeff, theoretically yes, because you have all the needed information (hmm...maybe except the NAT status from request, but you can store it via transaction)Practically, the save() function does expect to receive a request only, so it must be changed to work with a reply also. Regards, Bogdan Jeff Pyle wrote: I've thought a lot about this as well, although I haven't taken it nearly as far as John has. A thought: is it possible to do a save() in the reply route, only upon a 200 OK from the end registrar? - Jeff On 5/12/09 5:09 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi John, This mid-registrar approach may work but it is not 100% correct as OpenSIPS (as mid-registrar) does not obey the actions of the final registrar (Asterisk). Ex: - Asterisk may forbid the registration and you already saved the registration on OpenSIPS - Asterisk may change the Expire time while to saved the registration with the expire sent by client. Anyhow, ignoring this aspects, lets go further :) : 1) is the registration scenario working ok? if not what is the exact problem (some trace will help). I will wait for you answer before moving further with the calling stuff. Regards, Bogdan John Morris wrote: After several days of playing with OpenSIPS 1.5.0 and RTPProxy 1.2.0, I have a partially working SIP+RTP ALG configuration, and have gotten stuck. I could use some general advice from the list. The company has an Asterisk/FreePBX server on an internal network, and the CEO wants to use a SIP phone from outside. Because the sip alg iptables module isn't working, and in preparation for another project, I started investigating OpenSIPS for use as a border proxy to connect phones across NAT (and, the next project, to route a SIP trunk over a VPN from the network of a DSL+phone company that intermittently blocks SIP traffic in hopes of plugging revenue leaks). The network looks like this: SIP UA - home NAT gateway - Internet - OpenSIPS server/NAT router - Asterisk The standard opensips.cfg file doesn't work as is. The SIP phone needs to register to the Asterisk server directly. In addition, it seems there is extra logic needed to support multiple network interfaces (mhomed=1 only partially solves the problem). The way I've gone with this in testing is to relay REGISTERs to Asterisk, but after a save(location,0x02) to enable a lookup(location) on messages originating from the PBX. The phone is configured with an outbound proxy, and all packets to the proxy matching uri==myself are thrown away. This worked great on the single-interfaced, internal test installation. Now that there are multiple interfaces involved, things are breaking again; ACKs and BYEs are sent out the wrong interface, and RTPProxy is behaving strangely in bridged mode. There seem to be no good configuration examples for either multi-homed proxies or for proxies that relay REGISTERs. This makes me think that I'm going about this the wrong way. Also, I have looked at other software, like siproxd, opensbc and uh, that other b2bua that functions as an SBC, but none of those seem to allow this REGISTER pass-through function. What is the best approach for this scenario? The above approach of relaying REGISTERs to Asterisk? Is there maybe another approach where phones register to OpenSIPS directly, and OpenSIPS in turn somehow sends another REGISTER to Asterisk? Or am I missing the idea completely? I'd appreciate general pointers about how to proceed. I've been putting some Asterisk and FreePBX tutorials and CentOS RPMs on http://www.zultron.com, mostly aimed at small office-like environments. Looking through various lists, this seems a highly sought-after configuration. If I succeed, I'll document it in hopes of filling the gap in this sort of
Re: [OpenSIPS-Users] Rtp proxy issue
Additionally SDP can be sent in an ACK following 200 OK when the INVITE did not include it. On Sunday 08 March 2009, Alex Balashov wrote: It means you are applying the NAT UAC test function for SDP to a request that does not have an SDP payload. It should only be applied to messages that contain SDP payloads. Easy way to check: if(search(Content-Type: application/sdp)) Also, only the following kinds of messages can contain SDP descriptors: 1) Initial INVITEs; 2) Sequential INVITEs; 3) 200 OKs to INVITE transactions; 4) Non-100 1xx provisional messages -- these are usually 183 Session in Progress and 180 Ringing messages. However, technically, any non-100 1xx message can contain an SDP body per the RFC. In practise, this is rare, so t_check_status(200|183|180) will work for most scenarios. But if you want to be strictly correct, do: if((t_check_status(200|183|180) search(Content_Type: application/sdp)) || search(Content-Type: application/sdp)) michel freiha wrote: Hi all, I'm getting the below error when trying to make a call through OpenSIPS DBG:core:parse_headers: flags= Mar 6 20:43:29 [7117] ERROR:nathelper:extract_body: message body has length zero Mar 6 20:43:29 [7117] ERROR:nathelper:force_rtp_proxy2_f: can't extract body from the message Can you explain please how this is affecting the call specially that the call is working fine 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
Re: [OpenSIPS-Users] Old question about mediaproxy bridge mode between public and private networks
I wasn't suggesting it was a B2BUA. It was a wish. The funny thing is that people on the FreeSwitch list are asking for proxy-like behaviour so they can pass through things like REGISTER. On Wednesday 10 December 2008, Brett Nemeroff wrote: I don't think you'll get what you want out of OpenSIPs. It's not a B2BUA and does not mask topology. I'd love to hear other's who don't believe this. www.opensipstack.org has an open source SBC, but I can't vouch for it's capabilities. You may also want to check out FreeSwitch. -Brett On Wed, Dec 10, 2008 at 2:32 PM, Robert Dyck [EMAIL PROTECTED] wrote: I see a need for a very basic proxy-like B2BUA. This would completely hide the local topology. This would provide privacy and extra security as well as working around the bad behaviour of some service providers. Rob On Wednesday 10 December 2008, Brett Nemeroff wrote: For what it's worth, I've had problems doing this with some [broken] carriers. Namely they see a private address in one of the Vias and they assume it's NAT.. Pretty messy. If you look through the archive you'll see what happened to me. That being said, I think it's pretty unusual that this happens. -Brett On Wed, Dec 10, 2008 at 8:14 AM, Giuseppe Roberti [EMAIL PROTECTED] wrote: Hi. I have an opensips server running between a man local area and internet. This mean that UAC comes from local area and gateways are on internet. The local interface (eth0) ip is not reachable from internet. Opensips server can traverse the nat using add_local_rport(), can mediaproxy do the same ? Regards. -- Giuseppe Roberti [EMAIL PROTECTED] ___ 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
