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]: > > [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 > > >
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]: > > [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
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": "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": [
Re: [OpenSIPS-Users] Working out OpenSIPS 3.2 roadmap
On 03.12.2020 17:05, Saint Michael wrote: Some engines like RocksDB, open-source, should be part of Opensips and run in the same process space. This would be a first for any softswitch technology. We need full SQL technology, with tables, views, stored procedures, functions, timers, etc. Hi, Saint Michael! So with embed-able K/V databases such as LevelDB (Google) or RocksDB (Facebook, basically a fork of LevelDB), the only gain over the current, simplistic approach of "cachedb_local" could only be in terms of performance. Right or wrong? Regarding your other suggestion: that SQL "access" doesn't seem to have much to do with RocksDB anymore. And AFAIK, you can use avp_db_query() [1] to send any SQL query, regardless of how complex it is (SELECT, INSERT, UPDATE, DELETE, CALL PROCEDURE, CALL FUNCTION, CRATE TABLE, etc.). Can you elaborate as to what you are missing here? :-) [1]: https://opensips.org/docs/modules/3.3.x/avpops.html#func_avp_db_query Cheers, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Hi Robert, Are you doing parallel forking, right ? and keep in mind that via-branch (after forking) is unique and consistent "per branch", so you can rely on that. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/6/22 8:57 PM, Robert Dyck wrote: I am reaching out to the users out there to help me figure out why I get occasional call failures when it involves rtpengine and forked calls. Calls involving rtpengine but not forked are solid. For instance there is no problem with a call between a SIPified WEBRTC phone and some end of life device. WEBRTC has very strict requirements. ICE, DTLS and rtcmux are mandatory. These are unknown to some devices. I narrowed it down to forked calls. The documentation seems to suggest there are options for the offer command to deal with branches. Specifically the via- branch= variants. The auto option is mentioned in the documentation but it doesn't seem to be implemented in opensips. Then there is the 1 option for offers and the 2 option for answers. The 1/2 option did not help. Looking a little closer at what it does, I can't see how it could have helped anyway. The branch parameter in the via header is not unique for the different branches. We have multiple callees but only one caller. Diving deeper a look at the rtpengine debug logs only confirmed my doubt about the usefulness of via branch parameter. Here is an example of a three way fork. First offer "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: [core] Creating new call Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] creating new monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with 'as1g4gcnjp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] create new "other side" monologue for viabranch z9hG4bK3119290 Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] creating new monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with viabranch 'z9hG4bK3119290' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp Second offer "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] found existing monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp Third offer "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] found existing monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [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
