Remote Rig
RRC 1258 Support på Svenska => Konfiguration av RRC 1258 => Topic started by: westel on 2011-06-08, 09:46:17
-
Förbindelsen förblir bruten tills omstart sker av Controllsidan.
Kör med Continuous Tx på Radiosidan men inte på Controllsidan. Statiska portmappningar på radiosida, vanlig nat-router utan speciella inställningar på Controllsidan.
Version: 2.34
Brandväggsfenomen eller egenskap hos RRC? Några förslag till work-around?
Kompleterar gärna med kompletta konfar eller andra uppgifter.
Tack på förhand.
Magnus
-
Hur ser din uppkoppling ut och vilken "program mode" använder du?
-
Givetvis relevant.
Program mode: 4
Auto connect: 1 (controll, saknas på radiosidan vad jag kan se)
Radiosida: ADSL med statisk ip ---- NAT router med port forwarding (Linux DNAT) --- RRC
Controllsida: ADSL dynamiskt ip --- NAT router, inga särskillda inställnigar --- RRC
/Magnus
-
Kan du testa att använda DHCP i Kontrollsidan? (Konfiga routern att ge den samma IP så du lättare hittar den)
-
Nu förstår jag inte riktigt vad du är ute efter.
Ip-tilldelningen på kontrollsidan är via DHCP. På radiosidan är allt statiskt.
(Kontrollsidan är i en kunds nät. Jag har inte direkt tillgång RRCns GUI. Radiosidan är i vårt serverrum.)
Det jag observerar är att den konstanta utgående strömmen på ca. 80 kbit/s försvinner och RRCen på radiosidan går över i SIP-läge "idle" efter att det varit ett avbrott på vår (Radiosidans) internetförbindelse.
Jag gissar, men vet inte säkert, att RRCn på Kontrollsidan inte uppfattar att samtalet avbrutits utan ligger kvar och väntar på mer RTP eller SIP från andra ändan som inget hänt.
Är detta en rimlig teori? Gå det i så fall att ändra beteendet på något sätt? (En timeout på utebliven RTP som bryter samtalet till exempel.)
Vänligen
Magnus
-
Jag var ute efter en grej som en annan kund säger sig uppleva som liknade det du ursprungligen beskrev. För honom funkar det med DHCP påslaget i Kontrolländen, annars inte. Fast han får avbrott i Kontrolländens ADSL-förbindelse. Använder du värdnamn som SIP-kontakt i Kontrolländen? Om du gör det och Radioändens IP ändras så kan du få den effekt du beskriver pga att Kontrolländen cachar IP-adressen till Radioänden vid första DNS-uppslag efter omstart. Detta är något som vi är medvetna om och har tänkt kika på vid tillfälle.
-
Aha, då förstår jag.
Jo, jag använder värdnamn. Men ip på radiosidan ar fast så eventuell cachning bör inte vara något problem.
/Magnus
-
Just det, du skrev ju att det är fast IP på radiosidan ;)
Bägge "ändorna" har RTP/SIP-timeout. Så även Kontrolländen ska märka av ett avbrott i RTP-strömmen. Men lite svårt att veta vad den änden uppfattar sker när man inte kommer åt dess webbsida. Det går inte att ordna åtkomst till den?
-
Nja. RRCn är i skarp drift hos kunden så det är inte riktigt läge att be om fjärråtkomst för att "labba". Har du en checklista eller liknande på vad som kan vara bra att kolla när den har tappat förbindelsen? I så fall kan jag ge den till kundens (klart kompetente) IT-kille så att han har något att gå efter när/om vi hamnar i den situationen igen.
Du säger att det finns en RTP-timeout. Hur hänger den ihop med Continuous Tx inställningen? Jag tänkte inte på det när jag satte upp det men ni kanske inte menade att man skulle köra osymetrisk som jag gör?
I SIP behöver det ju inte vara några paket under pågående samtal så jag förmodar ni kör någon sorts keep alive. Eller?
/Magnus
-
Jag skulle inte vilja kalla det "labba" när man tittar på status-webbsidan, med du gör det, hehe? Jag föreslår att den kompetente IT-killen att ta en skärmdump på "Status"-sidan när kontakten är borta, ja gärna en när det funkar också för den delen.
Med "Continuous Tx" menas exakt som det låter, dvs att Tx-ljudet strömmas kontinuerligt i full fart oavsett om sändning sker från aktuell enhet eller inte. Om "Continuous Tx" är avslagen så skickas bara ett ljudpaket då och då när mottagning pågår, för att hålla uppe ev. brandväggar etc. RTP-timeouten finns i bägge fallen och är så mycket längre att den inte ska triggas annat än då det verkligen blivit avbrott.
SIP kräver inget som åker fram och åter så dess timeout åker så att säga snålskjuts på RTP-timeouten, men med en längre timeout-tid.
-
Jag kallar det att labba om man ber om tillfällig access och sedan provocerar fram fel. En permanent okrypterad väg in i nätet skulle jag inte ge någon annan och därför inte heller be om. Men detta är ju inte ett forum för nätverksadministration så vi lämnar väl det där hän. Jag ber honom om innehållet i statussidan nu och vid eventuellt fel. (Skulle jag vilja fortsätta denna tråd så skulle jag fråga var det kompletta CLIet över SSH på RRCerna finns ;-) )
Ok. Har jag förstått dig rätt?
"Continuous Tx av" (som vad jag vet brukar kallas Silence Suppression i den vanliga SIP-världen) skickar alltså paket då och då. Hur ofta?
Även vid "Continuous Tx av" finns en RTP timeout som när den löser ut bryter ner samtalet. (Och, förmodar jag, startar ett nytt om "Auto connect" är aktiverat.)
Någon keep-alive skickas inte på SIP-kanalen. (I min erfarenhet är annars SIP INFO paket eller bara tomma paket på samma portar vanliga.)
Ni hade inga invändningar mot att man kör "Continuous Tx" bara på ett håll.
Jag har konfarna för båda RRCerna som jag gärna sanerar och skickar över om det hjälper er. Att köpa in ett extra RRC-par bara för tester kan jag nog inte försvara. Men är ni villiga att låna ut så kan jag nog ta några timmar för att försöka återskapa problemet i labbmiljö.
/Magnus
-
Jag kallar det att labba om man ber om tillfällig access och sedan provocerar fram fel. En permanent okrypterad väg in i nätet skulle jag inte ge någon annan och därför inte heller be om. Men detta är ju inte ett forum för nätverksadministration så vi lämnar väl det där hän. Jag ber honom om innehållet i statussidan nu och vid eventuellt fel. (Skulle jag vilja fortsätta denna tråd så skulle jag fråga var det kompletta CLIet över SSH på RRCerna finns ;-) )
Så din kund är av typ miltär/bank-status då? Verkar så om man inte ens kan tillåta att webbserverporten till den är åtkomlig utifrån ;) RRCn är som du förstår en begränsad inbyggd enhet så att få in allt som t.ex SSH i den tar på redan ansträngda resurser.
Ok. Har jag förstått dig rätt?
"Continuous Tx av" (som vad jag vet brukar kallas Silence Suppression i den vanliga SIP-världen) skickar alltså paket då och då. Hur ofta?
Även vid "Continuous Tx av" finns en RTP timeout som när den löser ut bryter ner samtalet. (Och, förmodar jag, startar ett nytt om "Auto connect" är aktiverat.)
Någon keep-alive skickas inte på SIP-kanalen. (I min erfarenhet är annars SIP INFO paket eller bara tomma paket på samma portar vanliga.)
Du har lite invändningar mot vår vokabulär verkar det som? ;) Det är iofs roligt med kunnigt folk, men det tar onekligen mer av våra resurser att besvara frågor på detaljnivå, dessutom om en exakt korrekt vokabulär är kravet, haha!
En gång per sekund skickas RTP om "Continuous Tx" är avslaget och mottagning pågår.
Strikt sett så kan det ske keep-alive-liknande-trafik på SIP-kanalen också, beror dock lite på konfigar etc.
Ni hade inga invändningar mot att man kör "Continuous Tx" bara på ett håll.
Jag har konfarna för båda RRCerna som jag gärna sanerar och skickar över om det hjälper er. Att köpa in ett extra RRC-par bara för tester kan jag nog inte försvara. Men är ni villiga att låna ut så kan jag nog ta några timmar för att försöka återskapa problemet i labbmiljö.
/Magnus
Kan inte se att det skulle vara ett problem med Continues Tx på bara ena enheten.
Konfigarna kan såklart vara till hjälp ja.
-
Verkar som vi får ta diskussioner både om nätverkssäkerhet och mjukvaru-/hårdvarudesign över några öl någon gång. ;-)
"Terminologikommentaren" var inte menad som kritik utan var mer riktad till andra som läser tråden och har hållit på med SIP i vanlig telefoni förut.
Skickar konfarna direkt till dig efter helgen.
Med vänlig hälsning.
Magnus
-
Verkar som vi får ta diskussioner både om nätverkssäkerhet och mjukvaru-/hårdvarudesign över några öl någon gång. ;-)
Haha, nu blev det egentligen ännu roligare då jag råkar vara en av de få som inte använder dylika drycker ;-) Förstår dock vad du avser :-)
"Terminologikommentaren" var inte menad som kritik utan var mer riktad till andra som läser tråden och har hållit på med SIP i vanlig telefoni förut.
Inte kändes det som kritik på det viset, bara bra med synpunkter från alla håll och av alla kunskapsnivåer, för det bidrar till att man kan få ut information av sådan art att det passar så många som möjligt. Som parentes kan jag tillägga att för de som vet noll om SIP så är redan det faktum att ordet "SIP" förekommer bland inställningar förvirrande. Det är ju egentligen t.ex "Remote side IP/host name" man avser. Att de sen råkar vara SIP som används för uppkopplingen är ju oftast ointressant.
Skickar konfarna direkt till dig efter helgen.
Med vänlig hälsning.
Magnus
Fint!
-
Efter ett avbrott på ca. 5 min idag har jag lite mer info. (Efter ett avbrott på ca. 2 min igår uppstod inte problemet.)
Controll RRC:
Har SIP status Unknown(1) och Last SIP error None på statussidan.
Parametern SIP Timeout räknar ner från 5 till 3 och startar sedan om på 5. (Verkar vara sekunder.)
Omstart via Webgränssnitt löser inte problemet. Spänningsreset gör det.
Radio RRC:
Har SIP status Error och Last SIP error SIP Error.
Går efter återstart över till SIP status Idle och Last SIP error None.
Skickar kompletta statussidor direkt till Jan.
/Magnus
-
SIP Status 1 betyder att den är i "outbound call", dock utan att få svar på "INVITE". Efter 5 sek blir det timeout. Så onekligen så funkar inte åtminstone den delen av nätverkskommunikationen.
Att kontrollsidan inte "går till sig" mha omstart via webbgränssnittet verkar märkligt. Du kollade Uptime-räknaren för att se att den blir nollad?(=då har den verkligen resetat)
Skulle du kunna koppla in en serieterminal till COM1 på kontroll-RRCn? Mha den skulle du kunna testa att göra ett DNS-uppslag och se om även det fallerar? Meny "s" -> "7" isf.
Kräver även radiosidan spänningsreset?
-
Äsch.. Kom på att kontrollen är i "bank-valv".. Hmm.. Klart svårare då...
-
SIP Status 1 betyder att den är i "outbound call", dock utan att få svar på "INVITE". Efter 5 sek blir det timeout. Så onekligen så funkar inte åtminstone den delen av nätverkskommunikationen.
Jaha, och det förklarar att SIP-timeouten rullar. Vad jag kunde se gick den bara ned till 3 inte till 0 innan den startade om. Men det är kanske bara en artefakt i gränssnittet.
Att kontrollsidan inte "går till sig" mha omstart via webbgränssnittet verkar märkligt. Du kollade Uptime-räknaren för att se att den blir nollad?(=då har den verkligen resetat)
Nej, tänkte inte på det. Men reagerade på att det gick snabbt att starta om. Möjligt att omstarten inte "tog".
Kräver även radiosidan spänningsreset?
Nej. Det vill säga förbindelsen går upp igen efter enbart spänningsreset på Controll-sidan.
Vid reset via GUI på Radio-sidan går SIP-status från Error till Idle så något händer (ser jag i de sparade statussidorna). Gick lika fort och såg likadant ut som reseten på Controll-sidan.
/Magnus
-
Vid senare feltillfällen var beteendet lite annorlunda. Control RRCn står i läget Connected/transfering och Radio RRCn i läge Idle efter avbrottet. Disconnect/connect i webbgränssnittet får igång det igen.
Jan kom fram till att i fall SIP-paketen går fram men inte RTPn så triggar inte Control-ändans timeout och återinloggning. RRCn är nöjd med att det finns ett pågående samtal fast det inte finns någon ljudström från andra sidan. Om däremot RTP startar för att sedan brytas fungerar det som det skall. Detta är en bug som skall vara fixad från och med 2.44.