FoNet – register imod FoNet igennem en Carrier-grade NAT pool

Forum Fora Udbydere FoNet – register imod FoNet igennem en Carrier-grade NAT pool

Dette emne indeholder 7 svar, har 3 stemmer og blev senest opdateret af  pefu 3 år, 5 måneder siden.

  • Forfatter
    Indlæg
  • #31802

    pefu
    Deltager

    Sidst på året 2013 fik jeg portet 2 ISDN2 numre til FoNet.
    Det var der sådan set ingen ben i … for så vidt angår FoNets indsats :-)

    Det kørte hurtigt fint med dial in og out … lige indtil den public IPv4 som FoNet så som source for trafikken, den skiftede.

    Nåh, det er jo flinke mennesker hos FoNet, så en mail afsted til supporten … og så kørte det igen … lige indtil den public IPv4 som FoNet så som source for trafikken den skiftede igen.

    Arrr … jeg har haft trafikken lukket ned i et ½ døgn i retning FoNet, fordi der måske lige hang en REGISTER i FoNets ende med én eller anden lidt fodslæbende TIMEOUT.

    Næh-nej det hjalp heller ikke :-(

    Når det ikke kører, så kaster Asterisk op med noget i retning af: Forbidden – wrong password on authentication …

    Jeg kan ikke lige gennemskue medicinen her ud fra patientens symptomer: det kører max … så skifter IP’en … så kører det ikke … ½ døgns “pustepause” hjælper ikke … FoNet drejer på et håndsving … så kører det max igen … IP’en skifter … så kører det ikke … ½ døgns “pustepause” hjælper ikke …

    FoNet kan jo ikke blive ved med at skulle hidkaldes til at skrue og dreje på håndsving, hver gang IP’en skifter, så hvad gør man her.

    Det pudsige det er, at jeg har en anden account hos FoNet bestykket med ét af FoNets egne numre … den spiller max ligesom opkoblinger imod Musimi og Unotel uden brug af drejen og skruen på håndsving hos FoNet …

    Jeg kører aktuelt VoIP’en igennem en Telia LTE opkobling. Telia fedter med en Carrier-grade NAT pool, så hver gang et eller andet reboot’er / reopkobler … egen CPE, modem, Telia routers osv … så får man mere som reglen end som undtagelsen routed trafikken igennem i en anden Telia NAT-dåse.

    Hos TDC er det i øvrigt på samme vis med LTE/3G opkoblinger, der også stryger igennem en Carrier-grade NAT pool … så det er lige så morsomt imod FoNet som igennem Telia.

    Så kan man så handle IP access hos selskabet 3 … her kan man få en public IPv4 ind på CPE’en … og man kan betale sig til at få en static lease … det lyder jo besnærende … det giver også som ofte problemer i retning FoNet … bare ikke i retning Musimi og Unotel … når 3 … 1 X i døgnet smider netværksforbindelsen (hvad så end grunden til at de gør det er) … derudover er latency hos 3 lige 4 – 5 X så stor som igennem Telia … selv om det er samme mast en spytklat herfra og 100% fuld skrue på signalet …

    BTW: Jeg giver 19 øre / minut på min mobilos … så det er jo ikke fordi der er meget at spare ved at fedte med VoIP, men der trods alt stadig lidt anvendelig hed og sport i det … så det … hvis ellers det virker … ;-)

  • #31803

    Hej pefu

    Vi vil gerne se på sagen hvis du kontakter os på Supporten.

    Vi har flere kunder på Telias LTE de bruger dog ikke en PBX men ‘kun’ enkelt(e) IP-telefon(er).

    Du har nok fat i den lange ende af sagen det er muligvis noget LTE nettet i kombination med SIP.

    /Sven

    • #31804

      pefu
      Deltager

      Hej Sven / FoNet Support,

      Tak for interessen / svaret :-)

      Jeg har haft en fin dialog med Martin.

      Udfordringen synes (i første runde) at være relateret til FoNets fokus på dynamic versus static IP som SRC for kundens trafik.

      Supporter Martin skruede & drejede på nogle håndsving hos FoNet og så kørte den indgående trafik eksemplarisk.

      Inden for det seneste døgn bøvlede jeg lidt med at sætte den udgående VoIP trafik op i retning FoNet på kontoen med de portede numre …. herunder var jeg inde på FoNets selfcare interface og justere valg af udgående linier …

      Og ja … så er vi lige vidt igen … hverken indgående eller udgående linier lader sig inspirere til at virke efter hensigten, ift. kontoen med de portede numre – anden konto med et af FoNets tildelte numre virker derimod fint både i med- og modvind og har gjort det stort set fra dag 1 … både igennem 3’s og Telias net … og for så vidt også igennem TDC’s LTE net (her har jeg blot ikke fuld RF signalstyrke, så den route kommer længere nede i prioriteten)

      Dvs. løsningen ligger formodentlig i forskelle imellem de to konto opsætninger hos FoNet og/eller i Asterisk her i min ende … et af stederne eller begge steder er der en drillenisse, der laver al balladen ;-/

      Der er givet flere parametre i spil i den forbindelse, som jeg ikke umiddelbart kan gennemskue, fordi jeg ikke har handson på FoNets system … og det hele bliver derfor noget tidsrøvende & langhåret at rode med …

      Jeg gætter på, at FoNet har en GW / PROXY stående til at favne den indgående trafik / register fra kunden, som så sendes videre til én eller flere BackEnd(s), og meget kan fejle / hænge et eller andet sted i kæden.

      1) Asterisk kan være et bøvlehoved ift. at registrere flere samtidige kontoer op imod den samme IP / GW (har jeg set meldinger om på nettet)

      2) der er NAT / Carrier-grade NAT problematikker (herunder TIMEOUTs i NAT grej)

      3) der kan være VoIP register TIMEOUT problematikker

      4) der kan være uoverensstemmelser imellem register mv. på GW og BackEnd … evt. temporært som en register hangover eller andet.

      5) der kan være kontoen for: “diverse sjove oplevelser” uden at det er indlysende, hvad der er i spil … osv …

      Telias og TDC’s Carrier-grade NAT stunt er noget “specielt” konstrueret, idet man tildeler kunde CPE’en et RFC 1918 IP i området 10.x.x.x … frem for det Shared Transition Space for IPv4 Address Extension [1], der netop er særligt allokeret til sådanne formål.

      Det i sig selv /kan/ under særlige omstændigheder give kunden nogle “sjove oplevelser” :-)

      Dernæst kan en provider NAT / Carrier-grade NAT i sig selv give kunden nogle særlige udfordringer, ud over de udfordringer, der kan være ift. en “almindelig” CPE NAT.

      Ift. specifikt LTE i en stationær position med et langt eller static public IP lease, tænker jeg ikke, at der i princippet burde være andre problemer ift. VoIP, end der i øvrigt kan være ifm. andre net-typer.

      Problemet med LTE / 3G er typisk Carrier-grade NAT pool’en herunder IP skift ifm. mobilitet, signaludfald osv. som også deles med 3G nettet.

      Endelig er der jo det lusk med: netneutralitet eller det modsatte.

      Jeg er bekendt med, at der på et tidspunkt har været en offentlig udmelding fra visse providers om deres “fantasier” på VoIP området. Og humlen her, det er, at VoIP generelt “ødelægger forretningsmodellen” for providerens alm. “tele abonnementer”, hvorfor der kan være en vis forretningsmæssig interesse i, på forskellig vis, at obstruere flow’et af fx. VoIP trafik, fx enten ved at nedprioritere eller blokere trafikken.

      Aktuelt er det “vist” en mere teoretisk diskussion … sagt uden at jeg har konkret viden om, hvad der faktisk praktiseres ift. fx at reducere båndbredden for fx VoIP trafik.

      Men altså … jeg tænker slet IKKE, at det sidste her aktuelt er omdrejningspunktet i mit konkrete bøvl i retning den éne konto hos FoNet … for den anden virker eksemplarisk.

      [1] NetRange 100.64.0.0 – 100.127.255.255
      CIDR 100.64.0.0/10
      Name SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED

      Network record availabe at: http://whois.arin.net/rest/net/NET-100-64-0-0-1

      See also: http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/

      eller: http://tools.ietf.org/search/rfc6598

  • #31805

    pefu
    Deltager

    Opdatering:

    Under de givne omstændigheder (Asterisk, NAT og FoNet), kan jeg få de enkelte telefonnumre til at virke OK ind-ud hver for sig … bare ikke dem alle på samme tid …

    Givet:

    Konto#1, Lokalnr.1: 12345, telefonnr.: 12345678
    Konto#1, Lokalnr.2: benyttes ikke

    Konto#2, Lokalnr.1: 23456, telefonnr.1: 23456789
    Konto#2, Lokalnr.2: 23456*1, telefornr.2: 33333333

    Da konto#2 m. tilhørende numre er den portede (og den vigtigste), har jeg valgt at koncentrere mig om netop den konto.

    Hvis jeg fx 1) opsætter en aktiv register for hvert nummer under konto#2, så vil en tilringning til det ene nr., fx 33333333, typisk fejle (her med en viderestilling til følge) … p.t. virker det dog med tilringning til begge numre og 2) udringning virker kun via det ene (lokal)nummer, det andet (lokal)nummer giver flg. fejl:

    chan_sip.c: Forbidden – wrong password on authentication for INVITE to ‘”SIP-blahblah” <sip:23456*1@gw1.fonet.dk>;tag=xxxxyyyyzzzz’

    Arbejdskonklusionen er, at et setup ala:

    [Asterisk]———[NAT]——-[FoNet GW1]

    med flere samtidige SIP registreringer imod FoNet GW1 inducerer fejl i registreringerne.

    Hvis en given linie/lokalnummer ER registreret og Asterisk forsøger at (gen)registrere en ny linie/lokalnummer ved udringning, så falder hammeren nemlig prompte hos FoNet GW1 med en:

    SIP/2.0 401 Unauthorized

    Dvs. FoNet GW1 gider tilsyneladende på det foreliggende ikke flere registreringer fra samme IP:5060.

    REGISTER 13 headers, 0 lines

    Reliably Transmitting (NAT) to 213.83.164.141:5060:
    REGISTER sip:gw1.fonet.dk SIP/2.0
    Via: SIP/2.0/UDP 10.1.2.3:5060;branch=blahblahxyz2

    <– SIP read from 213.83.164.141:5060:
    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP:5060;branch=blahblahXX;received=1.2.3.4;rport=5060

    I øvrigt: IP: 10.1.2.3 NAT’es i CPE’en til IP: 1.2.3.4 …

    Jeg har ikke helt gennemskuet, om det er i min Asterisk ende eller FoNet GW / BackEnd enden, at man evt. kan skrue og dreje på et eller andet, så det kommer til at virke … men det ser umiddelbart ret magert ud i min Asterisk ende.

    BTW: Der fx ingen problemer med at sende og modtage trafik i retning Musimi med en håndfuld numre under samme konto, spørgsmålet er derfor, hvorfor det skal bøwle så meget i retning FoNet … og det kan formodentlig kun være et forskellig setup hos de to VoIP providers, der er forklaringen.

    PS: Er det korrekt observeret, at A-nummeret ikke overføres ved viderestilling fra et FoNet nummer til et nummer uden for FoNets butik?

  • #31806

    Vi bliver nødtil at tage fejlfindingen ud af dette forum og over i FONET “Butikken” .
    Så kan vi når vi har en løsning/forklaring lægge det her i tråden.

    Vi har indtil flere bud på ting der kan gå galt. Og det vil nok kræve WireShark-trace. Hvis ikke vore “gæt” løser problemet.

    Vi håber du kan tage dig tid til dette, da det kan være vi i fælleskab kan hjælpe andre der oplever mystik omkring LTE til VoIP

    /Sven

  • #31807

    pefu
    Deltager

    Det gør vi bare :-)

    *GENERELT* er det min opfattelse, at “mystik omkring LTE til VoIP” ikke har / bør have afsæt i det specifikke bæremedie.

    LTE har dog den udfordring, at der er failover til 3G. Hvilket typisk er koblet på fald i signalstyrken, fx fordi bruger-enheden er mobil (det kunne være en smartphone, herunder med et dvale-setup).

    Når der sker sker en failover/handover imellem LTE og 3G, kan der være et kort drop i forbindelsen … hvis det drop forlænges og der evt. også skiftes IP på terminalen, da vil det givet på forskellig vis kunne drille et VoIP scenario med udfald til følge.

    I et stationært setup med fuld skrue på signalet, burde der ikke ske skift imellem LTE og 3G pga. signal udfald og dermed.

    Kommer der også en Carrier-grade NAT pool med mange-til-én translation i spil (hvad der typisk gør ift. produkter på “konsumer-markedet”), løber man ind i endnu en udfordring, herunder fx ift. TIMEOUT i NAT tabellen og en passende ballance ift. KEEPALIVE (KA) trafik.

    Reboot’er IAP’en fx sin NAT enhed, så ser VoIP provideren måske en ny IP og/eller Port. Og binder VoIP provideren fx trafikken på IP eller port niveau (evt. med en TIMEOUT), vil kunden kunne opleve et drop i VoIP scenarioet.

    Endelig kan der være transparente “data trafik proxyer” med fx DPI hos IAP’en eller længere ude i backbone, der kan lave et eller andet sjov i trafikken.

    Selskabet 3 kører fx DPI på trafikken (det var oppe at vende i starten af 2012 ifm. en kendelse om blokering af trafik i retning Grooveshark).

    Der er i øvrigt her: http://www.youtube.com/watch?v=9nOc-35Xti4 en lille interessant video, der viser et hos kunden: multi homed scenario med lynhurtig WAN failover med en VoIP demo i spil :-)

    I demoen køres failover imellem WAN-WAN og WAN-WWAN (LTE).

    BTW: Den VoIP standard man forestiller sig benyttet på LTE-smartphones kaldes i øvrigt: Voice over LTE (VoLTE).

  • #31809

    3106
    Deltager

    Hvis det glipper med at få den NAT’ede løsning til at virke så kig evt. i retning af Telenor. Det er samme radioudstyr – og dermed samme dækning – som Telia, men det bagvedliggende setup er forskelligt. Hos Telenor får du din egen offentlige IP der ikke skifter så længe du holder tilslutningen, og der bør ikke ske nogen automatisk daglig disconnect som du har oplevet hos 3 :)
    IP-skift burde dermed kunne begrænses til når du oplever strømafbrydelse i hjemmet, eller hvis Telenor en sjælden gang en nat laver planlagt arbejde.

  • #31811

    pefu
    Deltager

    Tak for infoen :-)

    Hvis man så i tilgift kunne abonnere på et static lease af en public IPv4 på deres LTE abo’er, så havde det været helt perfekt … men det kan jeg ikke lige finde noget om inde på TeleNors site, så det er nok ikke noget de gør sig i …

    BTW: Jeg har eksperimenteret lidt videre med udfordringen, og noget kunne tyde på, at det kunne handle om, at Asterisk PBX’en prioriterer IP over UserName.

    Holder jeg mig til kontoen med de portede numre, kan jeg få begge INDGÅENDE numre til at virke, men kun ét af numrene til at virke som UDGÅENDE.

    Ved at bytte om på register rækkefølgen (eller udlade det ene) kan jeg får henholdsvis det ene eller det andet nummer til at virke som udgående.

    Det er i sip.conf der foregår:

    ; FoNet
    register => local_user#1:passwd#1@gw1.fonet.dk/12345
    register => local_user#2:passwd#2@gw1.fonet.dk/23456

    Hvis jeg så aktiverer ekstra kontoen … er det kun den der virker … og igen har det sikkert noget med register rækkefølgen at gøre og dermed at Asterisk under givne omstændigheder tolker forkert på UID og derved formodentlig sender noget UID/PW mismatch til FoNet.

    Det jeg forstiller mig, der kunne være behov for (set fra Asterisk’s synsvinkel), det er, at én registrering på en account er nok til at et lokalnummer under den account kan bruge et hvilket som helst public nummer tilknyttet den account som udgående nummer.

    Og overførsel af B-nr. ved tilringning (hvilket FoNet har aktiveret) og så ellers smide alle 3 public numre ind under én account.

    Vi må se, om Sven med sin WireShark-trace kan komme med andre bud.

Du skal være logget ind for at svare på dette indlæg.