In an amazing twist of fate, within one evening I have made several calls from an actual, albeit slightly modernized payphone and taken over the first phone number we have owned and consequently I have ever memorized. This GAAD was a good one. #Telephony#SIP#VOIP
Took a research survey looking into effectiveness of #ACPE Spiritually Integrated Psychotherapy ( #SIP) training.
I am looking forward to the training.
I'm peeved about the survey. They can't list every religion in the world, but with Neo-Pagan religions being the fastest growing cluster of religions in the USA, do better than sticking us in "OTHER"! Limits the research effectiveness & hides us.
My love of Android waxes and wanes according to how much the software feels like it is fighting me. On a good day, I can flash the OS and install whatever apps I want. On a bad day, I can't remove bloatware and I'm forbidden from changing the internals.
I started using the latest Google version of Android on their Pixel 8 Pro. I say "their" because it never really felt like the device was mine. Google kept popping up and asking me to do things which were clearly in their interest; not mine. There was very little way to remove Google's features. I was beholden to them. Forget that noise! I flashed GrapheneOS and regained some control.
But there are still some things missing from the modern Android experience. Things which I'm sure used to exist on earlier versions, but have since been scrapped or severely restricted.
I can't remember which version of Android I first had which let me change the font to Comic Sans. But that ability doesn't exist any more - not without rooting your phone and severely monkeying with its internals.
Google's Noto font is, sadly, abandonware. Aside from new Emoji, Google show no interest in putting a modern font stack into Android. So we're left with a fairly dull and incomplete corporate font.
Android originally had the back button on the right of the screen. Then, in Google's infinite wisdom, it was swapped to the left. Why? Fuck your muscle-memory, I guess?
Nevertheless, Android used to let you swap the order of the on-screen keys. This is not a particularly challenging software requirement - yet seems beyond modern Android.
I'm sure that I used to be able to set a different vibration pattern for different sorts of alerts. But I can't find that functionality anywhere these days. Same for different alert tones for different people.
If I want to close all my open apps, I have to go to task switcher then scroll all the way across. It was handy when there was a "close all" button at the bottom of the screen.
I have multiple SIMs. They can both receive calls and texts, but only one can be used for data. There used to be a button I could press to flip between the two. Now I have to go into the settings, and fiddle with a bunch of options. Annoying!
Online Mutual fund investment calculator helps to calculate the returns from your mutual fund investments. Start investing in SIP or lump sum investment with FundsIndia!
Spiritually Integrated Psychotherapy (SIP) upcoming Training Info
Very interesting looking training program! Broken into 15 CEU segments -- take 1 or both (for 30 CEUs). NBCC approved. Optional certification process afterwards, and optional peer support ongoing groups (they call them communities of practice).
I doubt the flyer attachment will stay attached, so here are a few links to find out more about the training program:
Here is a bit more about the program cut & paste from the links above:
ACPE SIP Training Level 1 with Wayne Gustafson (online)
May 4-18, 2024
- 05/04/2024, 9:30 am – 4:30 pm EST
- 05/11/2024, 9:30 am – 4:30 pm EST
- 05/18/2023, 9:30 am-12:30 pm EST
Curriculum
The word psychotherapy means “care of the soul” (from the Greek psyche + therapeia). While the history of psychotherapy includes theorists and practitioners with a bias against spirituality and religion, there have always been those who found effective ways to include spiritual wisdom in psychotherapeutic work. In recent years, there has been an outpouring of research and instruction in spiritually integrated psychotherapy, and empirical evidence demonstrating the therapeutic efficacy of attending to clients’ spiritual beliefs and practices.
The ACPE SIP Curriculum draws upon diverse spiritual traditions and psychological research to provide practical, usable resources to help therapists integrate spirituality into their work. It teaches therapists how to elicit and make therapeutic use of their clients’ spiritual perspectives and how to make ethically appropriate use of their own spiritual perspectives.
Beginning January 1, 2023, the curriculum will consist of two levels of training, with each level including 5 3-hour continuing education courses.
Level 1 Course Titles & Contact Hours
1.1 Foundations and Ethics of Spiritually Integrated Psychotherapy 3
1.2 Developing Spiritual Conversations in Psychotherapy 3
1.3 Spiritual Assessment 3
1.4 Spiritual Interventions: Working with Spiritual Resources, Part 1 3
1.5 Spiritual Interventions: Working with Spiritual Struggles 3
Level 1 Contact Hour Total: 15
Level 2 Course Titles
2.1 Spiritual Interventions: Working with Spiritual Resources, Part 2 3
2.2 Spiritual Interventions: Working with Harmful Spirituality and Religion 3
2.3 Spirituality and Belief System of the Therapist 3
2.4 Spiritually Integrated Case Conceptualization, Part 1 3
2.5 Spiritually Integrated Case Conceptualization, Part 2 3
Level 2 Contact Hour Total: 15
The courses draw upon multiple modes of teaching and learning, including:
interactive seminars;
role plays;
small group work; and case illustrations and case conceptualization.
--- Forwarded message ---
From: Gustafson, Wayne <Wayne.Gustafson@acpe.edu>
Date: Thu, Feb 1, 2024 at 3:52 PM
Subject: Spiritually Integrated Psychotherapy (SIP) upcoming Training Info
Greetings colleagues,
Once again, I am writing this informational email to all who are on the ACPE SIP Training interest list. (I attempted to remove emails of those who have previously registered for SIP training, but I may have missed you.)
I am both informing you about my upcoming training and asking for your help to spread the word.
I am presently recruiting for a SIP training (Levels 1 and 2).
Level 1 begins May 4 and ends May 18.
Level 2 begins June 1 and ends June 15.
I have attached a flyer with specific details.
See the flyer for details on CEUs including for several licensure categories in New York.
If you are interested in this particular training, please let me know soon. There is a limit on the number of registrations.
If you are interested, but this schedule does not work for you, more trainings can be found by following this link:
Even if you are not interested in SIP or if it is not quite right for you, please pass the information on to anyone who might be interested.
It is important that participants in SIP be actively engaged in some clinical practice. SIP Training is primarily for those engaged in psychotherapy, but in certain cases, chaplains who do counseling in their work also may benefit.
If you are looking for training in pastoral care rather than psychotherapy, check this link for details:
The first step towards registering for my SIP training will be a brief Zoom conversation with me. This is primarily to make sure that what you are seeking and what the program offers are compatible.
Thanks so much for your interest in SIP and for helping to pass the word along.
🚨 Attn: #Women in the #fediverse and on #mastondon we need a hastag like #fedihelps for each other when the trolls descend so the squad shows up. Any ideas what it should be? 💅
I'm old. I was thinking something along the lines of Sisterhood is Powerful as the bat signal. Abbreviated to #SIP . You either know the acronym or you learn it pretty quick.
A while ago I mentioned I use Android-10 with the built in SIP stack and that the Google stack was pretty buggy and I had to fix it simply to get it to function without disconnecting all the time. Since then I’ve upported my fixes to Android-11 (the jejb-11 branch in the repositories) by using LineageOS-19.1. However, another major deficiency in the Google SIP stack is its complete lack of security: both the SIP signalling and the media streams are all unencrypted meaning they can be intercepted and tapped by pretty much anyone in the network path running tcpdump. Why this is so, particularly for a company that keeps touting its security credentials is anyone’s guess. I personally suspect they added SIP in Android-4 with a view to basing Google Voice on it, decided later that proprietary VoIP protocols was the way to go but got stuck with people actually using the SIP stack for other calling services so they couldn’t rip it out and instead simply neglected it hoping it would die quietly due to lack of features and updates.
This blog post is a guide to how I took the fully unsecured Google SIP stack and added security to it. It also gives a brief overview of some of the security protocols you need to understand to get secure VoIP working.
What is SIP
What I’m calling SIP (but really a VoIP system using SIP) is a protocol consisting of several pieces. SIP (Session Initiation Protocol), RFC 3261, is really only one piece: it is the “signalling” layer meaning that call initiation, response and parameters are all communicated this way. However, simple SIP isn’t enough for a complete VoIP stack; once a call moves to in progress, there must be an agreement on where the media streams are and how they’re encoded. This piece is called a SDP (Session Description Protocol) agreement and is usually negotiated in the body of the SIP INVITE and response messages and finally once agreement is reached, the actual media stream for call audio goes over a different protocol called RTP (Real-time Transport Protocol).
How Google did SIP
The trick to adding protocols fast is to take them from someone else (if you’re open source, this is encouraged) so google actually chose the NIST-SIP java stack (which later became the JAIN-SIP stack) as the basis for SIP in android. However, that only covered signalling and they had to plumb it in to the android Phone model. One essential glue piece is <a href="https://android.googlesource.com/platform/frameworks/opt/net/voip/">frameworks/opt/net/voip</a> which supplies the SDP negotiating layer and interfaces the network codec to the phone audio. This isn’t quite enough because the telephony service and the Dialer also need to be involved to do the account setup and call routing. It always interested me that SIP was essentially special cased inside these services and apps instead of being a plug in, but that’s due to the fact that some of the classes that need extending to add phone protocols are internal only; presumably so only manufacturers can add phone features.
Securing SIP
This is pretty easy following the time honoured path of sending messages over TLS instead of in the clear simply by using a TLS wrappering technique of secure sockets and, indeed, this is how RFC 3261 says to do it. However, even this minor re-engineering proved unnecessary because the nist-sip stack was already TLS capable, it simply wasn’t allowed to be activated that way by the configuration options Google presented. A simple 10 line patch in a couple of repositories (<a href="https://github.com/jejb/android_external_nist-sip/commit/fc1a69d1df6ed784b3913404f653b83cf49063b1">external/nist_sip</a>, <a href="https://github.com/jejb/android_packages_services_Telephony/commit/a6c4f6e9d876a9a3b9a5bb051e2656ec18ae3c10">packages/services/Telephony</a> and <a href="https://github.com/jejb/android_frameworks_opt_net_voip/commit/1800c4bfcba093f4a834fb0b23f5b8d72b089b3c">frameworks/opt/net/voip</a>) fixed this and the SIP stack messaging was secured leaving only the voice stream insecure.
SDP
As I said above, the google frameworks/opt/net/voip does all the SDP negotiation. This isn’t actually part of SIP. The SDP negotiation is conducted over SIP messages (which means it’s secured thanks to the above) but how this should be done isn’t part of the SIP RFC. Instead SDP has its own RFC 4566 which is what the class follows (mainly for codec and port negotiation). You’d think that if it’s already secured by SIP, there’s no additional problem, but, unfortunately, using SRTP as the audio stream requires the exchange of additional security parameters which added to SDP by RFC 4568. To incorporate this into the Google SIP stack, it has to be integrated into the voip class. The essential additions in this RFC are a separate media description protocol (RTP/SAVP) for the secure stream and the addition of a set of tagged a=crypto: lines for key negotiation.
As will be a common theme: not all of RFC 4568 has to be implemented to get a secure RTP stream. It goes into great detail about key lifetime and master key indexes, neither of which are used by the asterisk SIP stack (which is the one my phone communicates with) so they’re not implemented. Briefly, it is best practice in TLS to rekey the transport periodically, so part of key negotiation should be key lifetime (actually, this isn’t as important to SRTP as it is to TLS, see below, which is why asterisk ignores it) and the people writing the spec thought it would be great to have a set of keys to choose from instead of just a single one (The Master Key Identifier) but realistically that simply adds a load of complexity for not much security benefit and, again, is ignored by asterisk which uses a single key.
In the end, it was a case of adding a new class for parsing the a=crypto: lines of SDP and doing a loop in the audio protocol for RTP/SAVP if TLS were set as the transport. This ended up being a ~400 line patch.
Secure RTP
RTP itself is governed by RFC 3550 which actually contains two separate stream descriptions: the actual media over RTP and a control protocol over RTCP. RTCP is mostly used for multi-party and video calls (where you want reports on reception quality to up/downshift the video resolution) and really serves no purpose for audio, so it isn’t implemented in the Google SIP stack (and isn’t really used by asterisk for audio only either).
When it comes to securing RTP (and RTCP) you’d think the time honoured mechanism (using secure sockets) would have applied although, since RTP is transmitted over UDP, one would have to use DTLS instead of TLS. Apparently the IETF did consider this, but elected to define a new protocol instead (or actually two: SRTP and SRTCP) in RFC 3711. One of the problems with this new protocol is that it also defines a new ciphersuite (AES_CM_…) which isn’t found in any of the standard SSL implementations. Although the AES_CM ciphers are very similar in operation to the AES_GCM ciphers of TLS (Indeed AES_GCM was adopted for SRTP in a later RFC 7714) they were never incorporated into the TLS ciphersuite definition.
So now there are two problems: adding code for the new protocol and performing the new encyrption/decryption scheme. Fortunately, there already exists a library (<a href="https://github.com/cisco/libsrtp/">libsrtp</a>) that can do this and even more fortunately it’s shipped in android (<a href="https://android.googlesource.com/platform/external/libsrtp2/">external/libsrtp2</a>) although it looks to be one of those throwaway additions where the library hasn’t really been updated since it was added (for cuttlefish gcastv2) in 2019 and so is still at a pre 2.3.0 version (I did check and there doesn’t look to be any essential bug fixes missing vs upstream, so it seems usable as is).
One of the really great things about libsrtp is that it has srtp_protect and srtp_unprotect functions which transform SRTP to RTP and vice versa, so it’s easily possible to layer this library directly into an existing RTP implementation. When doing this you have to remember that the encryption also includes authentication, so the size of the packet expands which is why the initial allocation size of the buffers has to be increased. One of the not so great things is that it implements all its own crypto primitives including AES and SHA1 (which most cryptographers think is always a bad idea) but on the plus side, it’s the same library asterisk uses so how much of a real problem could this be …
Following the simple layering approach, I constructed a patch to do the RTP<->SRTP transform in the JNI code if a key is passed in, so now everything just works and setting asterisk to SRTP only confirms the phone is able to send and receive encrypted audio streams. This ends up being a ~140 line patch.
So where does DTLS come in?
Anyone spending any time at all looking at protocols which use RTP, like webRTC, sees RTP and DTLS always mentioned in the same breath. Even asterisk has support for DTLS, so why is this? The answer is that if you use RTP outside the SIP framework, you still need a way of agreeing on the keys using SDP. That key agreement must be protected (and can’t go over RTCP because that would cause a chicken and egg problem) so implementations like webRTC use DTLS to exchange the initial SDP offer and answer negotiation. This is actually referred to as DTLS-SRTP even though it’s an initial DTLS handshake followed by SRTP (with no further DTLS in sight). However, this DTLS handshake is completely unnecessary for SIP, since the SDP handshake can be done over TLS protected SIP messaging instead (although I’ve yet to find anyone who can convincingly explain why this initial handshake has to go over DTLS and not TLS like SIP … I suspect it has something to do with wanting the protocol to be all UDP and go over the same initial port).
Conclusion
This whole exercise ended up producing less than 1000 lines in patches and taking a couple of days over Christmas to complete. That’s actually much simpler and way less time than I expected (given the complexity in the RFCs involved), which is why I didn’t look at doing this until now. I suppose the next thing I need to look at is reinserting the SIP stack into Android-12, but I’ll save that for when Android-11 falls out of support.
Hat jemand ne Empfehlung für eine 4-Parteien #Türsprechanlage? 2-Draht-Bus vorhanden. Das Gateway sollte #SIP, #IPv6 und/oder andere offene Standards sprechen. Video optional.
Guten Morgen Fedinaut*innen,
oder soll ich liebevoll Nerds sagen? Ich wurde von Aktivisti gefragt, ob ich Open Source Lösungen jenseits von Big Data kenne um Gruppenarbeit zu organisieren. Also ich denke mal Pads, offene Dokumente. Das einzige, was mir einfällt ist Nextcloud,wobei ich mich da auch nicht wirklich auskenne. Und wie hieß das nicht kommerzielle Big Blue Button Ding?Und dann weiß ich nicht, dass es im Fediverse etwas gibt zur Mobilisierung und ich habe vergessen wie es heißt.
Aber ihr könnt mir bestimmt helfen, oder?😉 #fedipower
Kommt gut in den Tag und seid nett zueinander 🥰
Have started telling organisations to not use the BT phone number but the voip one instead, so I guess that means I need to sort out the physical changeover.
One thing I've been wondering about #SIP;#VoIP though ... can someone call the line without trying to treat it as a phone number? AIUI there's nothing to signify a non-POTS line from a POTS one;; you dial the number without knowing how the connection will be made. But call dialing is how the telcos make their money, and I don't see them suddenly being fine with zero once they close down non-voip in the near future. BT like money!
I suspect that the eventual cross-platform solution to the incompatibility between #iMessage and #RCS in the #USA will just be everyone downloading an app like #Telegram (which is a honeypot) or #Signal, much how everyone uses #Whatsapp internationally.
Which I am sure that neither #Apple nor #Google wants.
I just want a simple, cheap, 2-way #sip#voip intercom that connects to my home PBX and dials a number for any of several preset channels depending on the button pressed, so I could put one in every room in the house.
I feel like this should be a common item but my searching turns up nothing!
Three years ago, I wrote about how you could add SIP calls to Android for free. Android had a well-integrated system which made VoIP calling a first-class citizen on its handsets. Sadly, Google killed native SIP calling in Android 12. FFS! It's relatively easy to get it set up again, although you'll need to install […]
Mutual fund Calculator - Calculate Your SIP Returns Online | FundsIndia (www.fundsindia.com)
Online Mutual fund investment calculator helps to calculate the returns from your mutual fund investments. Start investing in SIP or lump sum investment with FundsIndia!
SIP phones only have audio when talking to each other internally
MiVoice Office 400...