Date   

Re: Using all digital modes

Steve N4IRS
 

Not yet. The basics are the same for all the modes. You will need to use different port numbers where there are conflict. For example, the USRP channel driver settings in rpt.conf will need to be different from the ones in use. You will need to run a second copy of Analog_Bridge. Again, ports can not conflict with ports in use.

C4FM (Fusion) is a lot like DMR. The one possible addition to the data path is YSFGateway (not really needed unless you plan to move around on different reflectors). Here is a quick diagram:

ASL <-> Analog_Bridge <-> MMDVM_Bridge <-> YSF Gateway <-> external YSF reflector.

MMDVM_Bridge can do more then one mode, so you will not need a second copy. I suggest you build out from ASL towards the YSF reflector.

Steve N4IRS

On 10/23/2018 3:28 PM, AA4II wrote:
OK great are there any docs or other groups with information about setting up D-Star and C4FM?

On Tue, Oct 23, 2018 at 2:14 PM Steve N4IRS <szingman@...> wrote:
You will need another ASL node. But you should be clear on terminology, an ASL server can host multiple nodes. So, yes, you will need (want) another node, but you wont need another server.
Hope that helps.

Steve

On 10/23/2018 3:10 PM, AA4II wrote:
I'm sorry if this has been covered already. I have set up my DMR bridge and all is well. I would like to try to bridge D-Star and C4FM into my ASL node too. I was wondering if I could do this on the node I just set up or if I would need to create another ASL node for each of them?



Re: Using all digital modes

K4VL
 

OK great are there any docs or other groups with information about setting up D-Star and C4FM?


On Tue, Oct 23, 2018 at 2:14 PM Steve N4IRS <szingman@...> wrote:
You will need another ASL node. But you should be clear on terminology, an ASL server can host multiple nodes. So, yes, you will need (want) another node, but you wont need another server.
Hope that helps.

Steve

On 10/23/2018 3:10 PM, AA4II wrote:
I'm sorry if this has been covered already. I have set up my DMR bridge and all is well. I would like to try to bridge D-Star and C4FM into my ASL node too. I was wondering if I could do this on the node I just set up or if I would need to create another ASL node for each of them?


locked Re: Blocking users from a network and common sense.

Robert Bretzman
 

I assure that the blocking of Steve was not intentional. I appreciate everything Steve stands for and has done for the TGIF group. This is the first I have heard of this. Ty who does much of the work on our server from what little I know had to block certain IP's to try and troubleshoot issues we were having with the server. This is all way above my pay grade. I have been trying to get a hold of Ty with no luck. Our server is not working at the moment. As soon as I get a hold of him I will have that unblocked. Steve and anyone else is always welcome on the TGIF Network.
Sorry for any inconvenience or disruptions this has caused.
I will get it resolved..
73
Robert
TGIF ADMIN 


Re: Using all digital modes

Steve N4IRS
 

You will need another ASL node. But you should be clear on terminology, an ASL server can host multiple nodes. So, yes, you will need (want) another node, but you wont need another server.
Hope that helps.

Steve

On 10/23/2018 3:10 PM, AA4II wrote:
I'm sorry if this has been covered already. I have set up my DMR bridge and all is well. I would like to try to bridge D-Star and C4FM into my ASL node too. I was wondering if I could do this on the node I just set up or if I would need to create another ASL node for each of them?


Using all digital modes

K4VL
 

I'm sorry if this has been covered already. I have set up my DMR bridge and all is well. I would like to try to bridge D-Star and C4FM into my ASL node too. I was wondering if I could do this on the node I just set up or if I would need to create another ASL node for each of them?


locked Re: Blocking users from a network and common sense.

Chris WB4ULK
 

That is a shame to see that. I hope it was a glitch. After all, that is what this stuff is all about. Un-fragmenting our networks.

Chris

On Oct 23, 2018, at 10:50 AM, Steve N4IRS <szingman@msgstor.com> wrote:

There has been some traffic lately about bridging modes to established Masters (Servers) and Talk Groups. Simply put, DO NOT just drop a bridge on any TG without checking first. I can understand wanting to listen to a active TG on some mode with your ASL node. I've done it for testing dozens of times. The key word here is LISTEN. Make sure there is no way you are transmitting into a active TG. Do not just drop a bridge from ANY mode to a TG without "permission" from the primary user or managing authority. When I'm testing a connection to BM DMR I use my DMRID (3112138) as the TG number. I can then be assured the only person I will bother is me. If you don't use a little simple common sense, it's a good bet you will receive a bunch of ugly e-mail and possible be banned from TG, server or network. THINK! Remember, DVSwitch has but a number of servers for testing. See the stickey on this sub group for login info.

While I'm on the subject of banning, There is a group that has started up a new "Network" That network is TGIF. They are using software from DVSwitch including HBlink to create the new network. I applaud the choice of SW. The interesting thing is I had been monitoring the new network on their Master tgif.network. My primary interest is to listen for problems and see if the problem could be solved withing the DVSwitch SW. I did not really care to talk there. I do not want ANYTHING to do with the politics of why they decided to build their own network. My interest is that I felt it was a good test of the SW in a real world environment.
Well, long story longer, my IP address has been blocked by tgif.network. All I had connected was a single HotSpot running Pi-Star. Some time last weekend the HS could no longer connect. I could not bring up the status page on my browser. I figured they were making changes, it is a new network after all and change is to be expected. On Monday I decided to ask others if they were having a problem connecting to tgif.network. The answer I got back was no problem. After testing from a different IP address I surmised my IP was blocked. Again, I do not want to get into the politics of the new network. I can understand blocking a user that caused problems or a user that did nothing but "bad mouth" a network. I don't think just listening to a TG on a Server applies here. I guarantee, the people running tgif.network know how to reach me if there was something wrong with my node. Since I provided the P25 to DMR bridge for them and they knew how to reach me if there was a problem.

Steve N4IRS



locked Blocking users from a network and common sense.

Steve N4IRS
 

There has been some traffic lately about bridging modes to established Masters (Servers) and Talk Groups. Simply put, DO NOT just drop a bridge on any TG without checking first. I can understand wanting to listen to a active TG on some mode with your ASL node. I've done it for testing dozens of times. The key word here is LISTEN. Make sure there is no way you are transmitting into a active TG. Do not just drop a bridge from ANY mode to a TG without "permission" from the primary user or managing authority. When I'm testing a connection to BM DMR I use my DMRID (3112138) as the TG number. I can then be assured the only person I will bother is me. If you don't use a little simple common sense, it's a good bet you will receive a bunch of ugly e-mail and possible be banned from TG, server or network. THINK! Remember, DVSwitch has but a number of servers for testing. See the stickey on this sub group for login info.

While I'm on the subject of banning, There is a group that has started up a new "Network" That network is TGIF. They are using software from DVSwitch including HBlink to create the new network. I applaud the choice of SW. The interesting thing is I had been monitoring the new network on their Master tgif.network. My primary interest is to listen for problems and see if the problem could be solved withing the DVSwitch SW. I did not really care to talk there. I do not want ANYTHING to do with the politics of why they decided to build their own network. My interest is that I felt it was a good test of the SW in a real world environment.
Well, long story longer, my IP address has been blocked by tgif.network. All I had connected was a single HotSpot running Pi-Star. Some time last weekend the HS could no longer connect. I could not bring up the status page on my browser. I figured they were making changes, it is a new network after all and change is to be expected. On Monday I decided to ask others if they were having a problem connecting to tgif.network. The answer I got back was no problem. After testing from a different IP address I surmised my IP was blocked. Again, I do not want to get into the politics of the new network. I can understand blocking a user that caused problems or a user that did nothing but "bad mouth" a network. I don't think just listening to a TG on a Server applies here. I guarantee, the people running tgif.network know how to reach me if there was something wrong with my node. Since I provided the P25 to DMR bridge for them and they knew how to reach me if there was a problem.

Steve N4IRS


hb_parrot and hb_confbridge

Ed W8VT
 

Started playing with the pieces here to put together our own little network cluster with bridges to the outside world.
Got hb_confbridge working fine to our current BM cluster TG.

Can not get parrot to work with hb_confbridge. Stand alone it works OK. Searching through old posts saw mention of a problem with this. Am I trying to make something work that won't? BTW, this is the HB_Bridge branch.


Parrot and master - bridging using hb_confbridge

Rob MW0CQU
 

Hi All,

Moving forward with just enough knowledge to be dangerous.

On the test bench I now have a working master server with a repeater that attaches, listening on 54000

I also now have a working parrot-master which - if I bind it to 54000, it echoes everything on the repeater.

The last link in the chain is (If I understand the process correctly?) Is to confbridge the two masters together ?

 

and this is where I'm coming unstuck.

 

In MASTER hblink.cfg I have one master (MASTER-1) bound to 54000 and one peer PARROT

in PARROT hblink.cfg (different folder) I have one master bound to 54001

I try to bridge these in hb_confbridge.py with the following bridge statement

BRIDGES = {

    'PARROT': [

            {'SYSTEM': 'MASTER-1',    'TS': 2, 'TGID': 2,    'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON',  'ON': [2,], 'OFF': [9,10], 'RESET': []},

            {'SYSTEM': 'PARROT',    'TS': 2, 'TGID': 2, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON',  'ON': [2,], 'OFF': [9,10], 'RESET': []},

        ]

}

 
When I run Im getting an authentication failure for parrot on master 
Ive checked the passphrase on both (infact I copy/pasted between the two shell windows to make sure there were no typos
I've fixed the logging config bug where both tried to bind to 4321
 
but this last config of the two hblink.cfg files is not gelling in my brain
 
My goal for this stage is to simply get TG2, Slot 2 as a parrot with TG 1 on slot 1 as a standard talkthrough
 
1) Is my approach correct please ?
2) Obviously I need:
       a MASTER-1 stanza in the MASTER hblink.conf
       a PARROT Master in the PARROT hblink.conf
  but do I need to define , in each hblink.cfg, a reciprocal peer please ?
 
Im looking for the high level description of what peer/master/client definitions should go where - I can figure out the minutae as 
long as I'm barking up the right tree.
MTIA & 73
 
Rob  


Re: [Newbie!] Mute Parrot ?

Rob MW0CQU
 

Thanks for the reply Cort.

 

consider this thread closed due to finger trouble. I've recloned from the github and now have a working master, and a separate

working parrot

Still having an issue which I think I ought to start a separate thread on rather than take this thread off topic

 

73 ' de Rob 


locked Re: Zello interface will NOT happen.

Corey Dean N3FE <n3fe@...>
 

As a follow up to this.  The US BM masters owners just talked about this and Zello is NOT to be used on a US BM master .  This is the first and last warning anyone will receive and will be added to the BM wiki in the very near future!

Corey N3FE

On Sat, Oct 20, 2018 at 11:08 AM Steve N4IRS <szingman@...> wrote:
Let me be VERY clear, we are NOT working on Zello in any way, shape or form. That is for someone else to do. NOT US.
Please drop this.

Steve N4IRS

On 10/20/2018 11:05 AM, EA5GVK Joaquin wrote:
Hi. I would like to know if there is any progress to interconnect ZELLO to Analog_Bridge or MMDVM_Bridge, to interconnect a Zello Group with DMR, DSTAR, NXDN, FUSION, P25 etc ...


locked Zello interface will NOT happen.

Steve N4IRS
 

I want to be very clear on this:
We are NOT interested in working on a interface to Zello. Not now, not ever.

Please stop asking for it here.

I will delete any thread on this subject. I will moderate anyone bringing it up.

For DVSwitch

Steve N4IRS


Re: Analog_Bridge Ignore TX

Dylan KI7SBI
 

Calls do come in from other talkers, and audio is outputting to the soundcard. The "Ignore TX" issue is not a blocker for me, although I'm still curious.
I did need Steve's advised latency timer fix for the DV3000 usb.
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

I: 2018-10-20 00:00:08.287 Begin TX: src=3153775 rpt=13153679 dst=8951 slot=2 cc=1

I: 2018-10-20 00:00:26.306 Begin TX: src=3153775 rpt=13153679 dst=310 slot=2 cc=1

I: 2018-10-20 00:00:40.567 Begin TX: src=3144026 rpt=13153679 dst=310 slot=2 cc=1

I: 2018-10-20 00:00:47.779 Begin TX: src=3153775 rpt=13153679 dst=310 slot=2 cc=1

I: 2018-10-20 00:00:55.027 Begin TX: src=3101849 rpt=13153679 dst=310 slot=2 cc=1

I: 2018-10-20 00:01:00.428 Begin TX: src=1139941 rpt=13153679 dst=310 slot=2 cc=1


KI7SBI


Analog_Bridge Ignore TX

Dylan KI7SBI
 

Anyone experienced this Ignore TX condition with Analog_Bridge before? 

I: 2018-10-19 21:43:01.111 Begin TX: src=3153682 rpt=13153679 dst=9 slot=2 cc=1

I: 2018-10-19 21:43:01.611 Ignore TX: src=3153682 rpt=13153679 dst=9 slot=2 cc=1 (2)

I: 2018-10-19 21:43:02.111 Ignore TX: src=3153682 rpt=13153679 dst=9 slot=2 cc=1 (2)

I: 2018-10-19 21:43:02.611 Ignore TX: src=3153682 rpt=13153679 dst=9 slot=2 cc=1 (2)


Analog_Bridge <=> HB_Bridge client1 <=> HB_Bridge master
HT <=> pistar connects to the same <=> HB_Bridge master

Above, is Analog_Bridge output of a call from the HT. The rpt id is the pistar hotspot. The src id is the HT. I've attempted changing the pistar's id, without success.

Thanks.

KI7SBI


Re: IPSC Peers not Registering with each other

Cort N0MJS <n0mjs@...>
 



On Oct 19, 2018, at 11:13 AM, Michael Eckhoff <mreckhof@...> wrote:


I'm attempting to add a second IPSC peer to an existing peer group and finding that when the two peers attempt to register with each other, it's not working.  In addition, after a while, they drop their connection to the master as well.

On one peer, I get the following in the logs:

INFO 2018-10-15 22:25:17,060 (MASTER) Registering with the Master: x.x.x.x:64835
WARNING 2018-10-15 22:25:17,702 (MASTER) Registration response (we requested reg) from the Master: 1315835, x.x.x.x:64835 (1 peers)
INFO 2018-10-15 22:25:22,064 (MASTER), No Peer List - Requesting One From the Master
INFO 2018-10-15 22:25:24,171 (MASTER) Peer List Received from Master: 2 peers in this IPSC
INFO 2018-10-15 22:25:27,063 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:32,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:37,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:42,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:47,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000

And on the other peer, there's no registration attempt after it gets the alert that there's an additional peer from the master.

I can see in the debug logs that both peers are getting a new peer list and that each of the peers is on it.  It's just that the one peer never tries to do the registration with the other, but the second peer does.

It would have been handy to have included full debug log traces from both peers and the master if you want someone to try and figure out what’s going on. Common reasons for registration problems include two peers who have the same registration IP address (ie behind the same NAT), two peers trying to use the same radio ID… I can think of several other things that would tend to mess things up, but you’ve not included remotely adequate debug log output to look for them.

From the DO_NOT_README file, it makes it clear that all peers try to register with each other, and that process is part of the reason as to how the pinholes get setup in the NATs/FWs.  But if one of the peers doesn't try, then the pinholes never get setup, which is I assume why the peer that is trying to register isn't actually able to do it.

1.  Why wouldn't one of the two peers be attempting to reach out to the other, but one does?  Is there some kind of election by highest/lowest ID or something that dictates who goes first or should they both always blinding just reach out to each other?

First off, thanks for reading it. I renamed it DO_NOT_README in the hopes people would actually read it if I said not to. Trying to get folks to read it before asking for help turned out to not work at all :) :)

They both reach out to each other. Each peer has to register with each other…. you registering with me doesn’t mean I registered with you. We both have to actively register with each other. IPSC is very straightforward in this way.

2.  Why does the master drop the connection to both peers because the two peers can't talk to each other?  I would expect the master to stay connected and the peers just end up being islands.  Note:  I don't see anything in the logs when the master does this, however, I can see on the C-Bridge that they've been disconnected.

Both peers have the same radio ID, both peers coming from the same IP address. Port conflicts. The master will drop them if it doesn’t seen master keep-alive requests for a matter of time. Watch the debug logs to see if the peers are still sending master keep alives and the master to see if it’s receiving them.

3.  I only have a configuration for the MASTER.  I have no configuration setup for PEERS, as it appears to be getting that info from the master.  Do I need a peer configuration?

NO. If you manually had to configure every peer in the IPSC, there’d be no need for the master. That’s its only special role -- to maintain a list of registered peers to allow new systems to bootstrap – that’s what the peer list is all about. You can glean most of that from the MOTOTRBO system planner, BTW._._,_._,_


0x49 DE N0MJS

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






IPSC Peers not Registering with each other

Michael Eckhoff (K5MRE)
 


I'm attempting to add a second IPSC peer to an existing peer group and finding that when the two peers attempt to register with each other, it's not working.  In addition, after a while, they drop their connection to the master as well.

On one peer, I get the following in the logs:

INFO 2018-10-15 22:25:17,060 (MASTER) Registering with the Master: x.x.x.x:64835
WARNING 2018-10-15 22:25:17,702 (MASTER) Registration response (we requested reg) from the Master: 1315835, x.x.x.x:64835 (1 peers)
INFO 2018-10-15 22:25:22,064 (MASTER), No Peer List - Requesting One From the Master
INFO 2018-10-15 22:25:24,171 (MASTER) Peer List Received from Master: 2 peers in this IPSC
INFO 2018-10-15 22:25:27,063 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:32,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:37,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:42,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:47,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000

And on the other peer, there's no registration attempt after it gets the alert that there's an additional peer from the master.

I can see in the debug logs that both peers are getting a new peer list and that each of the peers is on it.  It's just that the one peer never tries to do the registration with the other, but the second peer does.

From the DO_NOT_README file, it makes it clear that all peers try to register with each other, and that process is part of the reason as to how the pinholes get setup in the NATs/FWs.  But if one of the peers doesn't try, then the pinholes never get setup, which is I assume why the peer that is trying to register isn't actually able to do it.

1.  Why wouldn't one of the two peers be attempting to reach out to the other, but one does?  Is there some kind of election by highest/lowest ID or something that dictates who goes first or should they both always blinding just reach out to each other?
2.  Why does the master drop the connection to both peers because the two peers can't talk to each other?  I would expect the master to stay connected and the peers just end up being islands.  Note:  I don't see anything in the logs when the master does this, however, I can see on the C-Bridge that they've been disconnected.
3.  I only have a configuration for the MASTER.  I have no configuration setup for PEERS, as it appears to be getting that info from the master.  Do I need a peer configuration?

I've tried this with both the branches and get the same result - and it's always the same peer that tries to reach out to the other.

Thanks!


Re: Newbie Problem

K4VL
 

Success I just talked to a friend in England. He was on DMR and I was on an analog handheld.

Thanks for everything you guys do making this successful


On Thu, Oct 18, 2018 at 8:07 AM Steve N4IRS <szingman@...> wrote:
Russell is correct. You should use this as your template <https://dvswitch.groups.io/g/allstarlink/wiki/home>
The howto document is pointed to in <https://dvswitch.groups.io/g/allstarlink/topic/first_draft_of_asl_dmr/21794260?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,21794260>

Steve N4IRS

On 10/18/2018 9:04 AM, Russell, KV4S wrote:
you may need to turn off your node telemetry, I had some issues with this as well. I'll see if i can find the guide i got... i think i got it from this group.

On Wed, Oct 17, 2018 at 10:33 AM AA4II <aa4ii@...> wrote:
For what it's worth hoseline is working again also.

On Wed, Oct 17, 2018 at 8:35 AM Corey Dean N3FE <n3fe@...> wrote:
Hoseline is a totally separate service and is not part of a master server.  The masters only send the audio to hoseline.  Hoseline is managed overseas and the master owners do not have access to it.
Corey

On Wed, Oct 17, 2018 at 9:29 AM AA4II <aa4ii@...> wrote:
It just came back up but I cannot hear my audio coming through hoseline anymore

On Wed, Oct 17, 2018 at 8:26 AM <jeff@...> wrote:
3108 has been off line all night, as as of one hour ago as well....


Re: Newbie Problem

K4VL
 

OK thanks for the howto. I just went through it and made changes to reflect the howto. Unfortunately I just ordered a DMR radio and can't test it out my self. I will have to wait for some of my friends to get home from work.

Thanks and 73
AA4II
Allstar 47424 (Not bridge)
DMR  tlkgrp 310286

On Thu, Oct 18, 2018 at 8:07 AM Steve N4IRS <szingman@...> wrote:
Russell is correct. You should use this as your template <https://dvswitch.groups.io/g/allstarlink/wiki/home>
The howto document is pointed to in <https://dvswitch.groups.io/g/allstarlink/topic/first_draft_of_asl_dmr/21794260?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,21794260>

Steve N4IRS

On 10/18/2018 9:04 AM, Russell, KV4S wrote:
you may need to turn off your node telemetry, I had some issues with this as well. I'll see if i can find the guide i got... i think i got it from this group.

On Wed, Oct 17, 2018 at 10:33 AM AA4II <aa4ii@...> wrote:
For what it's worth hoseline is working again also.

On Wed, Oct 17, 2018 at 8:35 AM Corey Dean N3FE <n3fe@...> wrote:
Hoseline is a totally separate service and is not part of a master server.  The masters only send the audio to hoseline.  Hoseline is managed overseas and the master owners do not have access to it.
Corey

On Wed, Oct 17, 2018 at 9:29 AM AA4II <aa4ii@...> wrote:
It just came back up but I cannot hear my audio coming through hoseline anymore

On Wed, Oct 17, 2018 at 8:26 AM <jeff@...> wrote:
3108 has been off line all night, as as of one hour ago as well....


Re: Why no working 2 instancies different MMDVM_Bridge in one machine?

EA5GVK Joaquin
 

Many thx. always grateful

On Thu, Oct 18, 2018 at 05:47 AM, Steve N4IRS wrote:
Glad to hear it is fixed. We will leave Zello to someone else to implement.


Re: Newbie Problem

Meinke, Rich
 

The telemetry should be off. Its is set when you are setting up the Private node (Node 1999, in the example documents)

[1999]

rxchannel = USRP/127.0.0.1:34001:32001  ; Use the USRP channel driver. Must be enabled in modules.conf

                                       ; 127.0.0.1 = IP of the target application

                                       ; 34001 = UDP port the target application is listening on

                                       ; 32001 = UDP port ASL is listening on


duplex = 0                              ; 0 = Half duplex with no telemetry tones or hang time. Ah, but Allison STILL talks!


hangtime = 0                            ; squelch tail hang time 0

althangtime = 0                         ; longer squelch tail hang time 0


holdofftelem = 1                        ; Hold off all telemetry when signal is present on receiver or from connected nodes

                                       ; except when an ID needs to be done and there is a signal coming from a connected node.


telemdefault = 0                        ; 0 = telemetry output off. Don't send Allison to DMR !!!!!!!!!!!!!!!!! Trust me.


telemdynamic = 0                        ; 0 = disallow users to change the local telemetry setting with a COP command,


linktolink = no                         ; disables forcing physical half-duplex operation of main repeater while

                                       ; still keeping half-duplex semantics (optional)


nounkeyct = 1                           ; Set to a 1 to eliminate courtesy tones and associated delays.


totime = 180000                         ; transmit time-out time (in ms) (optional, default 3 minutes 180000 ms)


idrecording = |ie                       ; id recording or morse string see http://ohnosec.org/drupal/node/87

idtalkover = |ie                        ; Talkover ID (optional) default is none see http://ohnosec.org/drupal/node/129

 

7421 - 7440 of 9753