Loading ...
Sorry, an error occurred while loading the content.

6210D-Star <-> SIP and my thoughts on the matter...

Expand Messages
  • Karl Vesterling
    Jan 26, 2011
      [apologies for changing the subject, but it seemed appropriate - read the original post at the bottom of this message first]

      Armando; You're not an alien.

      Just remember; there IS  a REASON that it's called "AMATEUR" radio...

      2 cents?
      I'll go a bit more than two cents...

      About IAX:
      Let me get this out of the way immediately.  This is a BAD idea...  A very bad idea...  TCP is the wrong choice of protocol for RTP data.
      Using TCP as a transport for RTP is a very BAD idea.

      What is BAD?
      BAD is an acronym, it stands for [B]roken [A]s [D]esigned.  Drop a packet and TCP will cause latency in order to recover the dropped packet.  It was designed to do this in order to maintain the integrity of the transported payload.  With regard to audio, it's not a dropped syllable, it's latency that drives people bugnutz.  That latency with regard to D-Star may cause the repeater to stop transmitting.  Keep the data flowing and let D-Star FEC sort it out. 

      A missing (frame/packet) will only cause R2D2 for a second (or at most three if I understand it correctly).  Jitterbuffers are the answer to the problem of dropped packets causing a gap that would/may manifest itself as a dropped transmission.  There's nothing worse than getting done with a 60second transmission and having the folks at the receiving end tell you that you disappeared after only the 7th word.  UDP with jitter buffers is the way to go on this.

      Which brings me to the main course with regard to this installment of D-Star food for thought. ;-)

      What I see with D-Star:
      It's portable, it's digital, and the main problem is that the gateway from an architectural standpoint is a jackasstic design...  Yes...  You can quote me on that.  Jackasstic.

      The radio mind you, yeah it's cumbersome, but functionally the radio is a viable piece of comms gear, and the firmware within it is pretty much set in stone.  So looking at this from a standpoint of status, the radios are what we've got to work with, so we're best off to work with it since re-inventing them or re-working the firmware inside each model isn't practical.

      So the question becomes how do the radios get utilized as they are, and the underlying gateway infrastructure implemented in such a way that it's no longer something designed by the church of the immaculate contraption?

      Here are my thoughts on the answer(s) to the above question...

      Why D-Star <->  SIP?
      Simple...  Interoperability...  Everything literally falls into place once this integration is implemented.
      Including, but I have some ideas on this too:
      And autopatch also becomes entirely feasible.
      and and and...  (you get the idea)

      Most SIP protocol stacks worth their weight in bits have jitter buffer support built in!

      I wave my usual "consulting fee" and give these suggestions freely to the amateur community since amateur radio is a public service:

      D-Star <-> SIP seems not only viable, but entirely do-able.  Callsign as the SIP "user", etc...  It just makes so much sense I cannot for the life of me comprehend why it was done in any other way.  Just from the perspective of interoperability it screams out "THIS WAY!"

      SIP w/ AMBE Codec:
      I do understand there's FEC in a D-Star data stream for audio, (I suspect this isn't true for data) but let's assume the gateway could be re-worked such that it would perform the FEC and break out the D-Star interleaved transmission into it's raw elements which could be transmitted to the endpoint (SIP Enabled D-Star gateway, or whatnot).

      Raw Elements?  What do you mean Mr. Vesterling?
      D-Star Header (Your, MY, RPT1 RPT2, etc...) (more on this below)
      D-Star Data: Text messages, etc...
      D-Star Audio: (The AMBE encoded voice)

      The D-Star header (maps to SIP Control channel) could be used for the gateway to "place a call" for callsign routing (see below), or like in D-Plus be used to connect to a SIP type conference bridge (D-Plus, but SIP) suc as "SIP025BL" to connect to the conference bridge, "SIP    U" to un-link, err "hang up" I mean.  Clearly this is where most of the integration would have to be coded, but at the surface it seems the elements are there and an integration could be done.

      The D-Star Data (maps to SIP Data Channel) would be passed in the SIP session just as if it were other text data.  There's provisions for this in the SIP protocol.  Not all SIP devices know what the heck this is, but any SIP stack worth it's weight in bits shouldn't wedge when encountering this.

      The D-Star Audio (maps to SIP RTP Channel) could be reduced to merely it's AMBE codec and wouldn't need to be transcoded if the other end is a SIP enabled D-Star Gateway.  (See muxing / transcoding AMBE below)

      It would seem that all the gateway would have to do would be to separate the above which are interleaved in the D-Star data stream into their component parts, transmit them to the far end as SIP, and (if) the destination is another D-Star gateway, it would then re-assemble into an interleaved D-Star stream.

      PLEASE NOTE: Since the D-Star radio's (to my knowledge) don't pass DTMF sequences in the data channel, the inability for the SIP gateway to inspect the AMBE audio for DTMF would eliminate the possibility of intercepting DTMF for any sort of control.  (but hey, DTMF is so 1980's one may almost refer to it as Retro if it weren't still on every fone.  yes "f"one.)  Experimentation here in the lab suggests that one can in fact (with some tuning of the DTMF detection thresholds) get fairly reliable DTMF recognition from AMBE encoded streams.  So if the gateway were to transcode to a recognizable audio format, then DTMF received within the D-Star audio channel could then easily be put into RFC2833 for (whatever purpose desired)...

      It would be up to the D-Star SIP Gateway software to act on the part of the radio as the SIP client.
      I AM NOT suggesting that you'd be able to take a SIP phone like X-Lite and have it register with a D-Star SIP enabled gateway.



      Transcoding / Muxing:  Can it be done to facilitate transcoding AMBE?
      What I'm wondering is whether or not the DV-Dongle product can just take "a packet / a sample" of AMBE and turn it into raw audio data, and if so at what rate.

      If the Dongle can convert say 1,000 AMBE samples into (X) audio samples without the AMBE samples needing to be dependent on the preceding sample, then it ought to be a relatively simple matter to "mux" several AMBE streams through a single DV-Dongle chip and obtain several separate audio streams on the output.

      Picture it processing two streams (StreamA) and (StreamB), and in order as represented below:

      (Kind of like TDM)
      (StreamA-AMBE-Sample-A)---->[AMBE CHIP]------>(RawAudioSampleA-StreamA)
      (StreamB-AMBE-Sample-X)---->[AMBE CHIP]------>(RawAudioSampleX-StreamB)
      (StreamA-AMBE-Sample-B)---->[AMBE CHIP]------>(RawAudioSampleB-StreamA)
      (StreamB-AMBE-Sample-Y)---->[AMBE CHIP]------>(RawAudioSampleY-StreamB)
      (StreamA-AMBE-Sample-C)---->[AMBE CHIP]------>(RawAudioSampleC-StreamA)
      (StreamB-AMBE-Sample-Z)---->[AMBE CHIP]------>(RawAudioSampleZ-StreamB)

      But I don't know that much about AMBE...  If muxing can be done w/ the AMBE chip, then a $200 USB add on (DV-Dongle) would make transcoding for interoperability with other SIP devices a relatively cost effective option...  And one could use the same DV-Dongle to service repeater Ports A, B, C, (or whatnot in the future) simultaneously provided that the AMBE chip contained within the DV-Dongle is capable of muxing, perhaps as outlined above.


      ASSUMING the above is true, then:
      That would mean that you could (ok, may) be able to use the DV-Dongle to transcode several AMBE conversations to raw audio, then it's a simple matter to take that and transcode it into uLaw, aLaw, GSM, G.72(x), Speex, etc...  In this way one wouldn't be locked merely to AMBE as the gateways could transcode the AMBE to connect to (whatnot) for the SIP connection.

      This would mean that the D-Star system could be integrated into any communications infrastructure that supported SIP.

      Callsign Routing becomes sane:
      Callsign routing would be easily done w/ something similar to E.164 in that when a gateway received a callsign, it would then perform an E.164 inquiry to see if the SIP record points back to itself.  If not, then it would make a DNS update to enact the change.  So, each D-Star transmission winds up being a DNS request.   Each gateway is assigned a TSIG "key" to perform the updates to the DNS zone for the callsign record.

      Callsign routing via E.164 type mechanism (example):

      n.2.v.q.m.callsigns.dstar.org -> (whatevergatewaycallsign).us.gateways.dtstar.org

      Subsequently the SIP URL to call to me would become:
      n2vqm@(whatevergatewaycallsign).us.gateways.dstar.org

      Is the target gateway at a dynamic IP?  Not a problem, make the gatewaycallsign.us.gateways.dstar.org a CNAME that points to whatever the free DynDNS host name is.  This can be easily maintained via several dyndns software clients such as ez-ipupdate, ddclient, etc...  Heck, several consumer router devices even support DynDNS.

      So you see, this is easily accomplished WITHOUT  the preposterously jackasstic requirement for a 10.0.0.0 Class A network.  (Folks, I've got to tell you...  Question marks pop out of my head seemingly endlessly when I attempt to figure out what was going on in their minds...  The words perplexed, bamboozled, shocked, dismayed, don't quite seem to capture the moment when I heard this.  If you took all of those words, were capable of summing the meaning and impact of them all up, and then multiply by several factors of 10, you might almost capture the essence of what happened inside my mind mere moments before I asked the person whom stated that requirement to me to repeat themselves.)

      Thoughts on D-Star <-> SIP integration:
      If you think about it, SIP has "VAD", which stands for "VOICE ACTIVITY DETECTION" such that the RTP stream will cease to transmit packets when there is no audio.  D-Star is push-to-talk anyways, so on the surface it looks like a viable option for conveying PTT.  (Do your own experimentation...  This is just a theory.)

      Conference Bridging like D-Plus reflectors becomes a bit more interesting, but I've got some ideas on how to implement that...

      D-Plus / Conference Bridging:
      Let's see how this idea flies before I wind up getting into the esoteric technicals of how this may be accomplished.

      Summary:
      Armando; You're not an alien...


      Best Regards,
      Karl J. Vesterling
      kjv@...
      202-461-3231 x0

      "Failure is not an option!  It comes bundled with your Microsoft Operating System..."

      On Jan 26, 2011, at 3:40 PM, Armando Accardo wrote:

       


      On Jan 26, 2011, at 9:32 PM, dlake02 wrote:

       

      The whole "streaming" system in D-Star is broken. The connection and data planes should be separate and using different protocols, ideally TCP for the control, and RTP/UDP for the media.

      I'm glad to hear this, I though I was an "alien" thinking this about DStar, after years of IRLP/EchoLink, where that is normal practice.

      73's de Armando, IK2XYP.


    • Show all 24 messages in this topic