Sveiki, norėčiau užsiprenumeruoti jūsų telefono sistemą ir norėčiau pasitikslinti, ar ji palaiko integraciją su trečiosios šalies SIP trumpojo ryšio (SIP trunk) tiekėju.
Ačiū,
1 patinka
Sveiki, @Odyssey,
Taip, palaiko. Turėsite paprašyti mūsų ją įjungti, nes pagal numatytuosius nustatymus ji neaktyvi.
Daugiau informacijos čia:
Puiku, ačiū už paaiškinimą!
Norėčiau pasitikslinti:
-
Ar jūsų telefono sistemos licencija yra apmokestinama už vartotoją ir (arba) už įrenginį?
-
Kiek įrenginių gali būti naudojama vienu metu su viena vartotojo paskyra?
Lauksiu jūsų atsakymo!
1 patinka
Ji yra skaičiuojama už kiekvieną telefono sistemos egzempliorių – taigi galite pridėti kelis „naudotojus“
Yra 30 įrenginių minkštoji riba, tačiau jei jums reikia daugiau, galite mums pranešti.
Turime du numerius (iš trečiosios šalies) – vieną biurui ir vieną atstovui, kuris yra kitoje šalyje ir dažnai keliauja. Norėčiau sužinoti, ar įmanoma šiuos du numerius prijungti prie jūsų telefono sistemos, kiekvieną numerį priskiriant atitinkamam naudotojui, kaip aprašyta.
Be to, norėčiau pasitikslinti, ar mums reikėtų dviejų atskirų SIP trąsų, po vieną kiekvienam numeriui?
Taip pat noriu įsitikinti, kad šių dviejų naudotojų konfigūracija bus atskira ir kad jų skambučiai neskambės pakaitomis ir nesukels jokių konfliktų.
Dėkoju už pagalbą. Laukiu jūsų atsakymo.
1 patinka
Taip, tai galima lengvai padaryti naudojant telefono sistemą. Galite sukurti atskirą SIP paskyrą kiekvienam ir turėti nepriklausomą maršruto nustatymą kiekvienam.
Taip pat galite sukurti kelis darbo srities skirtukus, kad logika būtų visiškai atskirta.
Sveiki,
jau esu susikonfigūravęs telefono sistemą. Ar galėtumėte man įjungti Trunk funkciją?
Iš anksto dėkoju!
Sveiki,
Aš jau sukonfigūravau įeinantį (Inbound) kamieną. Ar galėtumėte patvirtinti, ar man taip pat reikia sukurti skambučių srautą (Call Flow), kad gaučiau skambučius iš SIP kamieno? Pridėjau telefono numerį ir sukūriau Call Flow, tačiau kai bandau skambinti numeriu iš kamieno tiekėjo pusės, sakoma, kad numeris nepasiekiamas. Kokia galėtų būti problema?
Sukonfigūravęs Inbound kamieną, pastebėjau, kad SIP kamieno būsena mano kamieno tiekėjo portale trumpam parodoma kaip „Online“, bet po to pasikeičia į „Offline“ ir nuo tada man nepavyksta jos vėl įjungti. Turiu ištrinti kamieną ir pridėti jį iš naujo, kad jis vėl taptų „Online“, tačiau bijau, kad jis vėl taps „Offline“. Ar galėtumėte padėti man tai ištirti?
Suprantu, kad kamienas turi išlikti nuolat „online“, kad būtų galima siųsti ir gauti skambučių signalus. Ar ši problema galėtų būti susijusi su serverio galiojimo laiku, registracijos intervalu ar atnaujinimo (refresh) nustatymais? Jei taip, ar galėtumėte pateikti instrukcijas arba rekomenduojamas reikšmes šiems nustatymams, kad kamienas išliktų užregistruotas ir stabilus?
Be to, aš pridėjau telefono numerį iš kamieno tiekėjo į PBX ir sukūriau išeinantį (Outbound) kamieną. Tačiau numeris nepasirodo kaip galimas pasirinkimas mano softphone programėlėje. Ar reikia atlikti papildomą žingsnį, kad numeris ar vidinis numeris (extension) būtų susietas su softphone?
Iš anksto dėkoju už jūsų pagalbą.
Dėkojame už išsamią informaciją apie jūsų kamieninės (trunk) sąrankos problemas. Dėl jūsų situacijos pasikonsultavau su mūsų technine komanda.
Mūsų komanda ištyrė ir nustatė, kad įeinančiam trunk su jūsų domenu nepasiekia jokie INVITE signalai. Tai rodo, kad skambučiai iš 61290982328 nėra tinkamai nukreipiami į jūsų trunk galinį tašką (XXXX.in.phone.systems) arba gali būti konfigūracijos klaida.
Štai keli rekomenduojami žingsniai problemai išspręsti:
- Patikrinkite savo DID tiekėjo konfigūraciją:
- Ar galite pasidalyti ekrano nuotraukomis, kaip sukonfigūravote trunk tiekėjo pusėje?
- Konkrečiai, patikrinkite, ar jie naudoja tik IP autentifikaciją
- Registracijos nustatymai:
- Pabandykite nustatyti registracijos laikmatį į 3600 sekundžių (standartinė reikšmė)
- Jei jūsų tiekėjas palaiko tik IP autentifikaciją, gali tekti pašalinti registraciją iš dabartinio Inbound trunk phone.systems sistemoje ir sukonfigūruoti trunk tiekėjo pusėje taip, kad jis siųstų INVITE į sukonfigūruotą SIP URI
- Dėl jūsų išėjimo numerio problemos:
- Jūsų trečiosios šalies numeris turėtų būti pridėtas Phone Number skiltyje
- Tada pasirinkite jį kaip CLI išėjantiems skambučiams skiltyje Contact Methods
- Tai galite rasti čia: Contact Methods Documentation
- Ypač žiūrėkite skiltį „Outbound calls → Enable external outbound calls“ prie Caller IDs dalies
Gali būti verta paprašyti savo DID tiekėjo pcap (paketų fiksavimo) failo, kai inicijuojamas skambutis į jūsų DID ir tada nukreipiamas į nurodytą SIP URI. Tai padėtų tiksliai nustatyti, kur nutrūksta ryšys.
Praneškite, jei jums reikia paaiškinimų ir (arba) jei problema išlieka.
Sveiki,
Ankstesnėje žinutėje minėjau, kad susiduriu su problema naudojant SIP registracijos režimą, todėl perjungiau į IP autentifikavimo režimą, kuris, atrodo, veikia. Tačiau IP autentifikavimo režime neturiu naudotojo vardo ir slaptažodžio, kad galėčiau registruoti Termination Gateway (išorinį kamieną / Outbound Trunk).
Nors galiu vykdyti išeinančius skambučius naudodamas trečiosios šalies numerį, šie skambučiai nepasirodo trečiosios šalies išeinančių skambučių ataskaitose. Panašu, kad gali būti neteisinga konfigūracija arba Outbound Trunk nustatymuose, arba Outbound Rules.
Ar galėtumėte mane pakonsultuoti, kaip teisingai sukonfigūruoti Outbound Trunk arba Outbound Rules, kad skambučiai būtų tinkamai registruojami?
Ačiū,
IP Authentication režimu paprastai nereikia naudotojo vardo / slaptažodžio kredencialų Termination Gateway konfigūracijoje. Vietoj to jūsų trunk tiekėjas autentifikuoja pagal jūsų IP adresą. Termination Gateway nustatymuose galite palikti Username ir Password laukus tuščius ir tiesiog sukonfigūruoti:
- Host: jūsų tiekėjo SIP serveris
- Port: paprastai 5060 arba 5061
- Network Protocol: UDP arba TCP (kaip reikalauja jūsų tiekėjas)
Ši problema greičiausiai susijusi su CLI (Caller ID), kuris siunčiamas jūsų tiekėjui. Patikrinkite savo Termination Route konfigūraciją:
- Termination Route Settings: įsitikinkite, kad jūsų maršrutas tinkamai sukonfigūruotas ir priskirtas teisingas Gateway
- CLI Rules: savo Termination Route patikrinkite SRC Rewrite Rule. Gali reikėti užtikrinti, kad siunčiamas šaltinio numeris atitiktų formatą, kurio tikisi jūsų tiekėjas jūsų priskirtam numeriui
- Number Format: patikrinkite, ar siunčiamas CLI tiksliai atitinka tą, kurį jums priskyrė tiekėjas (su arba be šalies kodų / prefiksų)
Jei jūsų tiekėjas tikisi, kad skambučiai bus inicijuojami iš konkretaus numerio formato, gali reikėti nustatyti SRC Rewrite Rule savo Termination Route, kad būtų užtikrinta, jog siunčiamas teisingas CLI.
Ar galite patikrinti, koks CLI / šaltinio numeris siunčiamas jūsų išvykstantiems skambučiams, ir patvirtinti, kad jis sutampa su tuo, kurį trečiosios šalies tiekėjas turi jūsų paskyroje?
Sveiki,
Rašau dėl anksčiau iškelto klausimo, susijusio su ryšiu su trečiosios šalies SIP tranku. Kaip prašėte, anksčiau jums išsiunčiau el. laišką su PCAP failais tiek iš trečiosios šalies pusės, tiek iš mūsų pusės.
Tačiau kol kas dar negavau jokio atsakymo. Ar galėtumėte pranešti, ar šiuo metu dirbate su šiuo atveju? Mums reikia atnaujintos informacijos, kad galėtume tęsti tyrimą ir iš savo pusės.
Tai mums yra skubus klausimas, nes tai yra mūsų perėjimo nuo Skype dalis, o jo galiojimas netrukus baigsis.
Trumpas atnaujinimas: dabar galiu vykdyti išeinančius skambučius naudodamas trečiosios šalies numerį per tinkamą trečiosios šalies tranką. Jų ataskaitoje matau išeinančių skambučių žurnalus, kas patvirtina, kad skambučiai eina per jų sistemą. Tačiau taip pat pastebėjau, kad tie patys išeinantys skambučiai rodomi ir jūsų Call Analytics ataskaitose.
Ar galėtumėte patvirtinti, ar jūsų Call Analytics registruoja visus išeinančius skambučius, net ir tuos, kurie nukreipiami per trečiųjų šalių paslaugų teikėjus? Noriu tik įsitikinti, kad mano išeinančių skambučių taisyklėse nėra neteisingų konfiguracijų, dėl kurių už tuos pačius skambučius mums galėtų būti pateiktos sąskaitos ir iš jūsų, ir iš trečiosios šalies paslaugų teikėjo.
Lauksiu jūsų atsakymo.
Ačiū,
Atsiprašome už vėlavimą, @Odyssey, netrukus atsiųsime jums el. laišką šiuo klausimu.