Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - westel

Pages: [1]
1
Hej,

Är intresserad av "Commercial Radio"-versionen av RRC.

Kan man få ta del av specifikationen för optokopplargränssnittet?

m.v.h.
Magnus

2
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.

3
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

4
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

5
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

6
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

7

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

8
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 

9
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


 

10
Configuration, RRC 1258 / Re: LOCK-UP of RRC-1258
« on: 2011-06-08, 10:45:08 »
I have a similar experience.

After setting SIP-port to 10000 Web-GUI was still fully responsive but no new changes "took". Factory reset solved the issue.

/Magnus

11
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

12
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

Pages: [1]