4 ms·

SIP has crept into so many spots - Need to connect two two-way radio systems? its SIP in a fancy dress. Need to connect a two-way to a console system? its SIP

by Aloha 4y ago

SIP has crept into so many spots - Need to connect two two-way radio systems? its SIP in a fancy dress. Need to connect a two-way to a console system? its SIP in a different colored fancy dress. NXDN is completely SIP internally, it's not standard SIP, but you can still construct a call ladder with conventional tools (or just read the captures), and have a rough idea of what it's doing, even if the headers are weird. P25, and DMR use SIP in various other places, either for logging, or for console connections. The workaround so you have Calling Party ID on radio systems is to imbed the metadata for a talkspurt inside the audio stream. The one gripe I have about SIP, is - I suspect mostly because (but not entirely) of the telco cruft, you can have two standards compliant SIP implementations that can't interop in a meaningful way. The lack of a required minimum codec support does add to those challenges, but I've seen SIP also fail to work even when both sides have the same codecs, but rather do not emit headers the other side expects. (For example when OPTIONS must occur before REGISTER) Gripes aside, I will take a SIP derived protocol any day over a binary protocol that needs some sort of magic decoder ring, I have to work with those, and I loathe them for obvious reasons. So thank you for the work you did to standardize something that has touched my daily working life for 15 years now.

kjellsbells 4y ago
> you can have two standards compliant SIP implementations that can't interop I spent years in telco. You would not believe how painful getting telco A to talk to telco B was, despite it all being SIP. There was a bazillion-dollar market for session border controllers that did nothing but protocol fixup all day. Incredibly, one of the things that SBCs had to do was transcode audio in near-real-time between one telco and another. This was very technically demanding since end users don't like glitchy audio, but also, in some sense, totally a waste of everyone's time and expensive DSP resources, since the two endpoints spoke the same codec but had to cross internal networks that did not.
- Aloha 4y ago
  That doesnt surprise me, there is a market at least for conversion between uLaw and aLaw - I've used Asterisk (as well as some other boxes from AudioCodes and another manufacturer who's name escapes me), in a similar role.

by Aloha 4y ago

kjellsbells 4y ago

> you can have two standards compliant SIP implementations that can't interop I spent years in telco. You would not believe how painful getting telco A to talk to telco B was, despite it all being SIP. There was a bazillion-dollar market for session border controllers that did nothing but protocol fixup all day. Incredibly, one of the things that SBCs had to do was transcode audio in near-real-time between one telco and another. This was very technically demanding since end users don't like glitchy audio, but also, in some sense, totally a waste of everyone's time and expensive DSP resources, since the two endpoints spoke the same codec but had to cross internal networks that did not.

Aloha 4y ago
That doesnt surprise me, there is a market at least for conversion between uLaw and aLaw - I've used Asterisk (as well as some other boxes from AudioCodes and another manufacturer who's name escapes me), in a similar role.