Witam, Jeśli klient jest podpięty z pooli dhcp (jeden IP) to jest łatwo limitować pasmo.
A jak radzicie sobie jesli klient ma podsieć?? np 192.168.100.0/29 Robicie specjalne poole dla każdego klienta i w nich dodajecie tyle komputerów ile ma IP??
Jest to gdzieś opisane?? Jak to inaczej/lepiej zrobic??
Dobre pytanie, przyłączam się? z tym, że nie znalazłem rozwiązania by przydzielić klientowi sieć, można tylko komputer
W dniu 27 listopada 2015 10:24 użytkownik Arturz arturz@kl.net.pl napisał:
Witam, Jeśli klient jest podpięty z pooli dhcp (jeden IP) to jest łatwo limitować pasmo.
A jak radzicie sobie jesli klient ma podsieć?? np 192.168.100.0/29 Robicie specjalne poole dla każdego klienta i w nich dodajecie tyle komputerów ile ma IP??
Jest to gdzieś opisane?? Jak to inaczej/lepiej zrobic??
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Mogę przygotować proste przypisywanie klientów do sieci - też tego potrzebujemy. Zwykłe dodanie kolumny customerid do tabeli networks pewnie by wystarczyło. Pytanie czy listować takie podsieci w komputerach klienta czy zrobić osoby box?
W dniu 27 listopada 2015 11:53 użytkownik Marcin marcin@nicram.net napisał:
Dobre pytanie, przyłączam się? z tym, że nie znalazłem rozwiązania by przydzielić klientowi sieć, można tylko komputer
W dniu 27 listopada 2015 10:24 użytkownik Arturz arturz@kl.net.pl napisał:
Witam, Jeśli klient jest podpięty z pooli dhcp (jeden IP) to jest łatwo limitować pasmo.
A jak radzicie sobie jesli klient ma podsieć?? np 192.168.100.0/29 Robicie specjalne poole dla każdego klienta i w nich dodajecie tyle komputerów ile ma IP??
Jest to gdzieś opisane?? Jak to inaczej/lepiej zrobic??
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 27.11.2015 12:43, Skiba Marek napisał(a):
Mogę przygotować proste przypisywanie klientów do sieci - też tego potrzebujemy. Zwykłe dodanie kolumny customerid do tabeli networks pewnie by wystarczyło. Pytanie czy listować takie podsieci w komputerach klienta czy zrobić osoby box?
Chyba lepiej w osobnym boksie, bo będzie to wtedy łatwiej modyfikowalne z wtyczek. Z drugiej strony nie wiem czy nie lepiej wykorzystać tabelę nodes i dać możliwość wpisania pustego adresu, a przecież pole netid już jest. Warto brać pod uwagę, że sporo atrybutów z nodes brane jest pod uwagę przy raportach do UKE i przy konfigurowaniu urządzeń. Możliwe, że ipaddr = NULL przy i tak netid IS NOT NULL mogłoby oznaczać przypisanie sieci.
W dniu 27.11.2015 12:50, Tomasz Chiliński napisał(a):
W dniu 27.11.2015 12:43, Skiba Marek napisał(a):
Mogę przygotować proste przypisywanie klientów do sieci - też tego potrzebujemy. Zwykłe dodanie kolumny customerid do tabeli networks pewnie by wystarczyło. Pytanie czy listować takie podsieci w komputerach klienta czy zrobić osoby box?
Chyba lepiej w osobnym boksie, bo będzie to wtedy łatwiej modyfikowalne z wtyczek. Z drugiej strony nie wiem czy nie lepiej wykorzystać tabelę nodes i dać możliwość wpisania pustego adresu, a przecież pole netid już jest. Warto brać pod uwagę, że sporo atrybutów z nodes brane jest pod uwagę przy raportach do UKE i przy konfigurowaniu urządzeń. Możliwe, że ipaddr = NULL przy i tak netid IS NOT NULL mogłoby oznaczać przypisanie sieci.
Właściwie, żeby nie ruszać w ogóle schematu bazy danych to trzeba byłoby założyć, że nodes przechowuje przypisanie sieci do klienta, gdy ipaddr = 0 i ipaddr_pub = 0.
W dniu 27 listopada 2015 12:53 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 27.11.2015 12:50, Tomasz Chiliński napisał(a):
Chyba lepiej w osobnym boksie, bo będzie to wtedy łatwiej modyfikowalne z wtyczek. Z drugiej strony nie wiem czy nie lepiej wykorzystać tabelę nodes i dać możliwość wpisania pustego adresu, a przecież pole netid już jest. Warto brać pod uwagę, że sporo atrybutów z nodes brane jest pod uwagę przy raportach do UKE i przy konfigurowaniu urządzeń. Możliwe, że ipaddr = NULL przy i tak netid IS NOT NULL mogłoby oznaczać przypisanie sieci.
Właściwie, żeby nie ruszać w ogóle schematu bazy danych to trzeba byłoby założyć, że nodes przechowuje przypisanie sieci do klienta, gdy ipaddr = 0 i ipaddr_pub = 0.
No to rozwiązanie ma tą zaletę, że faktycznie nie modyfikuje schematu bazy ale spowoduje trochę więcej konfliktów z poprzednimi zapytaniami. Przygotuję coś w ten deseń co piszesz i podeślę.
W dniu 2015-11-27 o 13:12, Skiba Marek pisze:
W dniu 27 listopada 2015 12:53 użytkownik Tomasz Chiliński <tomasz.chilinski@chilan.com mailto:tomasz.chilinski@chilan.com> napisał:
W dniu 27.11.2015 12:50, Tomasz Chiliński napisał(a): Chyba lepiej w osobnym boksie, bo będzie to wtedy łatwiej modyfikowalne z wtyczek. Z drugiej strony nie wiem czy nie lepiej wykorzystać tabelę nodes i dać możliwość wpisania pustego adresu, a przecież pole netid już jest. Warto brać pod uwagę, że sporo atrybutów z nodes brane jest pod uwagę przy raportach do UKE i przy konfigurowaniu urządzeń. Możliwe, że ipaddr = NULL przy i tak netid IS NOT NULL mogłoby oznaczać przypisanie sieci. Właściwie, żeby nie ruszać w ogóle schematu bazy danych to trzeba byłoby założyć, że nodes przechowuje przypisanie sieci do klienta, gdy ipaddr = 0 i ipaddr_pub = 0.No to rozwiązanie ma tą zaletę, że faktycznie nie modyfikuje schematu bazy ale spowoduje trochę więcej konfliktów z poprzednimi zapytaniami. Przygotuję coś w ten deseń co piszesz i podeślę.
Ja miałem taki pomysł aby wpisywać w ipaddr adres networka wtedy.
W dniu 27.11.2015 13:24, Waldemar Dymkiewicz napisał(a):
W dniu 2015-11-27 o 13:12, Skiba Marek pisze:
W dniu 27 listopada 2015 12:53 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał: W dniu 27.11.2015 12:50, Tomasz Chiliński napisał(a): Chyba lepiej w osobnym boksie, bo będzie to wtedy łatwiej modyfikowalne z wtyczek. Z drugiej strony nie wiem czy nie lepiej wykorzystać tabelę nodes i dać możliwość wpisania pustego adresu, a przecież pole netid już jest. Warto brać pod uwagę, że sporo atrybutów z nodes brane jest pod uwagę przy raportach do UKE i przy konfigurowaniu urządzeń. Możliwe, że ipaddr = NULL przy i tak netid IS NOT NULL mogłoby oznaczać przypisanie sieci.
Właściwie, żeby nie ruszać w ogóle schematu bazy danych to trzeba byłoby założyć, że nodes przechowuje przypisanie sieci do klienta, gdy ipaddr = 0 i ipaddr_pub = 0.
No to rozwiązanie ma tą zaletę, że faktycznie nie modyfikuje schematu bazy ale spowoduje trochę więcej konfliktów z poprzednimi zapytaniami. Przygotuję coś w ten deseń co piszesz i podeślę.
Ja miałem taki pomysł aby wpisywać w ipaddr adres networka wtedy.
Tak to było dobre rozwiązanie przed wprowadzeniem pola netid w nodes - też tak kiedyś tymczasowo robiłem. Od kiedy jest pole netid już nie ma problemu z przypisaniem sieci do komputera - przynajmniej teoretycznie na poziomie DB.
W dniu 2015-11-27 o 13:30, Tomasz Chiliński pisze:
W dniu 27.11.2015 13:24, Waldemar Dymkiewicz napisał(a):
W dniu 2015-11-27 o 13:12, Skiba Marek pisze:
W dniu 27 listopada 2015 12:53 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał: W dniu 27.11.2015 12:50, Tomasz Chiliński napisał(a): Chyba lepiej w osobnym boksie, bo będzie to wtedy łatwiej modyfikowalne z wtyczek. Z drugiej strony nie wiem czy nie lepiej wykorzystać tabelę nodes i dać możliwość wpisania pustego adresu, a przecież pole netid już jest. Warto brać pod uwagę, że sporo atrybutów z nodes brane jest pod uwagę przy raportach do UKE i przy konfigurowaniu urządzeń. Możliwe, że ipaddr = NULL przy i tak netid IS NOT NULL mogłoby oznaczać przypisanie sieci.
Właściwie, żeby nie ruszać w ogóle schematu bazy danych to trzeba byłoby założyć, że nodes przechowuje przypisanie sieci do klienta, gdy ipaddr = 0 i ipaddr_pub = 0.
No to rozwiązanie ma tą zaletę, że faktycznie nie modyfikuje schematu bazy ale spowoduje trochę więcej konfliktów z poprzednimi zapytaniami. Przygotuję coś w ten deseń co piszesz i podeślę.
Ja miałem taki pomysł aby wpisywać w ipaddr adres networka wtedy.
Tak to było dobre rozwiązanie przed wprowadzeniem pola netid w nodes - też tak kiedyś tymczasowo robiłem. Od kiedy jest pole netid już nie ma problemu z przypisaniem sieci do komputera - przynajmniej teoretycznie na poziomie DB.
A ile mnie to będzie kosztowało??
W dniu 27.11.2015 13:12, Skiba Marek napisał(a):
W dniu 27 listopada 2015 12:53 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
W dniu 27.11.2015 12:50, Tomasz Chiliński napisał(a):
Chyba lepiej w osobnym boksie, bo będzie to wtedy łatwiej modyfikowalne z wtyczek. Z drugiej strony nie wiem czy nie lepiej wykorzystać tabelę nodes i dać możliwość wpisania pustego adresu, a przecież pole netid już jest. Warto brać pod uwagę, że sporo atrybutów z nodes brane jest pod uwagę przy raportach do UKE i przy konfigurowaniu urządzeń. Możliwe, że ipaddr = NULL przy i tak netid IS NOT NULL mogłoby oznaczać przypisanie sieci.
Właściwie, żeby nie ruszać w ogóle schematu bazy danych to trzeba byłoby założyć, że nodes przechowuje przypisanie sieci do klienta, gdy ipaddr = 0 i ipaddr_pub = 0.
No to rozwiązanie ma tą zaletę, że faktycznie nie modyfikuje schematu bazy ale spowoduje trochę więcej konfliktów z poprzednimi zapytaniami. Przygotuję coś w ten deseń co piszesz i podeślę.
Pewnie i tak pomogę, gdzieś w obszarach kodu o których łatwo będzie zapomnieć. Póki co przy dodawaniu lub edycji komputera można dodać specjalny ptaszek w stylu "cała sieć", którego zaznaczenie będzie powodować zablokowanie pól edycji/wyboru adresu ip (pierwszy etap). Potem prezentacja tego w odpowiedni sposób na liście komputerów (globalnie i boksach - drugi etap). Potem wszelkie prezentacje map danej sieci...
Przewidujesz od razu sprawdzanie, jak wybierze się przypisanie sieci, czy daną sieć można w ogóle przypisać (pewnie nie mogą być do takiej sieci żadne indywidualne komputery przypisane).
W dniu 27 listopada 2015 13:29 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Przewidujesz od razu sprawdzanie, jak wybierze się przypisanie sieci, czy daną sieć można w ogóle przypisać (pewnie nie mogą być do takiej sieci żadne indywidualne komputery przypisane).
No właśnie zastanawiam się nad tym głębiej teraz. Bo mamy też przypadki gdzie dana firma ma całą podsieć (VLAN) dla siebie ale komputery są porozwalane geograficznie po całym mieście, więc należałoby pozwalać dodawać komputery do takiej podsieci aby określić np. fizyczną lokalizację komputera.
I jestem trochę w kropce bo powoli nie widzę sensu pakować podsieci do tabeli nodes. Na dobrą sprawę będziemy wykorzystywać tylko pole "ownerid" i możemy zaadaptować też pole "chkmac" (żeby nie sprawdzało MACa dla całej podsieci), bo pozostałe raczej tyczą się komputerów niż mogą jakoś zostać wykorzystane do podsieci a te co mogą zostać wykorzystane do podsieci: name, ip, access jest też w kolumnie networks.
W dniu 2015-11-27 o 14:07, Skiba Marek pisze:
W dniu 27 listopada 2015 13:29 użytkownik Tomasz Chiliński <tomasz.chilinski@chilan.com mailto:tomasz.chilinski@chilan.com> napisał:
Przewidujesz od razu sprawdzanie, jak wybierze się przypisanie sieci, czy daną sieć można w ogóle przypisać (pewnie nie mogą być do takiej sieci żadne indywidualne komputery przypisane).No właśnie zastanawiam się nad tym głębiej teraz. Bo mamy też przypadki gdzie dana firma ma całą podsieć (VLAN) dla siebie ale komputery są porozwalane geograficznie po całym mieście, więc należałoby pozwalać dodawać komputery do takiej podsieci aby określić np. fizyczną lokalizację komputera.
I jestem trochę w kropce bo powoli nie widzę sensu pakować podsieci do tabeli nodes. Na dobrą sprawę będziemy wykorzystywać tylko pole "ownerid" i możemy zaadaptować też pole "chkmac" (żeby nie sprawdzało MACa dla całej podsieci), bo pozostałe raczej tyczą się komputerów niż mogą jakoś zostać wykorzystane do podsieci a te co mogą zostać wykorzystane do podsieci: name, ip, access jest też w kolumnie networks.
A to dodać hurtem komputery ( jakoś to zaznaczyć, ze sieć/poola) i wtedy defaulowo każdy komp ma adres siedziby, a jak kto chce to wchodzi i poprawia pojedyncze.
W dniu 27.11.2015 14:07, Skiba Marek napisał(a):
W dniu 27 listopada 2015 13:29 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Przewidujesz od razu sprawdzanie, jak wybierze się przypisanie sieci, czy daną sieć można w ogóle przypisać (pewnie nie mogą być do takiej sieci żadne indywidualne komputery przypisane).
No właśnie zastanawiam się nad tym głębiej teraz. Bo mamy też przypadki gdzie dana firma ma całą podsieć (VLAN) dla siebie ale komputery są porozwalane geograficznie po całym mieście, więc należałoby pozwalać dodawać komputery do takiej podsieci aby określić np. fizyczną lokalizację komputera.
I jestem trochę w kropce bo powoli nie widzę sensu pakować podsieci do tabeli nodes. Na dobrą sprawę będziemy wykorzystywać tylko pole "ownerid" i możemy zaadaptować też pole "chkmac" (żeby nie sprawdzało MACa dla całej podsieci), bo pozostałe raczej tyczą się komputerów niż mogą jakoś zostać wykorzystane do podsieci a te co mogą zostać wykorzystane do podsieci: name, ip, access jest też w kolumnie networks.
Lokalizacja teryt i gps są istotne jeśli całą sieć przydzielasz firmie w danej lokalizacji.
W dniu 27.11.2015 15:03, Tomasz Chiliński napisał(a):
W dniu 27.11.2015 14:07, Skiba Marek napisał(a):
W dniu 27 listopada 2015 13:29 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Przewidujesz od razu sprawdzanie, jak wybierze się przypisanie sieci, czy daną sieć można w ogóle przypisać (pewnie nie mogą być do takiej sieci żadne indywidualne komputery przypisane).
No właśnie zastanawiam się nad tym głębiej teraz. Bo mamy też przypadki gdzie dana firma ma całą podsieć (VLAN) dla siebie ale komputery są porozwalane geograficznie po całym mieście, więc należałoby pozwalać dodawać komputery do takiej podsieci aby określić np. fizyczną lokalizację komputera.
Jeśli masz taką sytuację jak piszesz to robisz sieć zwykłą i z niej kompy przypisujesz firmie. Pewnie te przypisania bez porządku i tak wynikały z tego, że LMS do tej pory nie pozwalał na przypisywanie całych sieci do klientów.
I jestem trochę w kropce bo powoli nie widzę sensu pakować podsieci do tabeli nodes. Na dobrą sprawę będziemy wykorzystywać tylko pole "ownerid" i możemy zaadaptować też pole "chkmac" (żeby nie sprawdzało MACa dla całej podsieci), bo pozostałe raczej tyczą się komputerów niż mogą jakoś zostać wykorzystane do podsieci a te co mogą zostać wykorzystane do podsieci: name, ip, access jest też w kolumnie networks.
Lokalizacja teryt i gps są istotne jeśli całą sieć przydzielasz firmie w danej lokalizacji.
Witajcie Panowie W dniu 11/27/2015 o 03:05 PM, Tomasz Chiliński pisze:
W dniu 27.11.2015 15:03, Tomasz Chiliński napisał(a):
W dniu 27.11.2015 14:07, Skiba Marek napisał(a):
W dniu 27 listopada 2015 13:29 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Przewidujesz od razu sprawdzanie, jak wybierze się przypisanie sieci, czy daną sieć można w ogóle przypisać (pewnie nie mogą być do takiej sieci żadne indywidualne komputery przypisane).
No właśnie zastanawiam się nad tym głębiej teraz. Bo mamy też przypadki gdzie dana firma ma całą podsieć (VLAN) dla siebie ale komputery są porozwalane geograficznie po całym mieście, więc należałoby pozwalać dodawać komputery do takiej podsieci aby określić np. fizyczną lokalizację komputera.
Jeśli masz taką sytuację jak piszesz to robisz sieć zwykłą i z niej kompy przypisujesz firmie. Pewnie te przypisania bez porządku i tak wynikały z tego, że LMS do tej pory nie pozwalał na przypisywanie całych sieci do klientów.
Rozwazcie jeszcze proszę taki scenariusz jak przypisanie klientowi komputera z adresem IP a.x.y.z jako routera dla jego sieci a.b.c.d/n
I jestem trochę w kropce bo powoli nie widzę sensu pakować podsieci
do tabeli nodes. Na dobrą sprawę będziemy wykorzystywać tylko pole "ownerid" i możemy zaadaptować też pole "chkmac" (żeby nie sprawdzało MACa dla całej podsieci), bo pozostałe raczej tyczą się komputerów niż mogą jakoś zostać wykorzystane do podsieci a te co mogą zostać wykorzystane do podsieci: name, ip, access jest też w kolumnie networks.
Lokalizacja teryt i gps są istotne jeśli całą sieć przydzielasz firmie w danej lokalizacji.
Tomku, widzę że dodajesz możliwość przypisywania sieci do klienta. nie sensowniej byłoby zmienić szablon tabeli networks i dodać tam pole nodeid (jeżeli puste/'0' to siec dostępna na dotychczasowych zasadach)?
Nie przyglądałem się jak to wpłynie na resztę zapytań związanych z tabelą networks. Pozdrawiam
W dniu 11/30/2015 o 11:31 AM, Ernest pisze:
Witajcie Panowie W dniu 11/27/2015 o 03:05 PM, Tomasz Chiliński pisze:
W dniu 27.11.2015 15:03, Tomasz Chiliński napisał(a):
W dniu 27.11.2015 14:07, Skiba Marek napisał(a):
W dniu 27 listopada 2015 13:29 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Przewidujesz od razu sprawdzanie, jak wybierze się przypisanie sieci, czy daną sieć można w ogóle przypisać (pewnie nie mogą być do takiej sieci żadne indywidualne komputery przypisane).
No właśnie zastanawiam się nad tym głębiej teraz. Bo mamy też przypadki gdzie dana firma ma całą podsieć (VLAN) dla siebie ale komputery są porozwalane geograficznie po całym mieście, więc należałoby pozwalać dodawać komputery do takiej podsieci aby określić np. fizyczną lokalizację komputera.
Jeśli masz taką sytuację jak piszesz to robisz sieć zwykłą i z niej kompy przypisujesz firmie. Pewnie te przypisania bez porządku i tak wynikały z tego, że LMS do tej pory nie pozwalał na przypisywanie całych sieci do klientów.
Rozwazcie jeszcze proszę taki scenariusz jak przypisanie klientowi komputera z adresem IP a.x.y.z jako routera dla jego sieci a.b.c.d/n
I jestem trochę w kropce bo powoli nie widzę sensu pakować podsieci
do tabeli nodes. Na dobrą sprawę będziemy wykorzystywać tylko pole "ownerid" i możemy zaadaptować też pole "chkmac" (żeby nie sprawdzało MACa dla całej podsieci), bo pozostałe raczej tyczą się komputerów niż mogą jakoś zostać wykorzystane do podsieci a te co mogą zostać wykorzystane do podsieci: name, ip, access jest też w kolumnie networks.
Lokalizacja teryt i gps są istotne jeśli całą sieć przydzielasz firmie w danej lokalizacji.
W dniu 22.12.2015 13:14, Ernest napisał(a):
Tomku, widzę że dodajesz możliwość przypisywania sieci do klienta. nie sensowniej byłoby zmienić szablon tabeli networks i dodać tam pole nodeid (jeżeli puste/'0' to siec dostępna na dotychczasowych zasadach)?
To robił po dyskusji z nami pjona. Moim zdaniem jest dobrze zrobione, bo przypisanie sieci do klienta odbywa się poprzez rekord w nodes z ipaddr = 0 i ipaddr_pub = 0, a rekordy w nodes mają już możliwość ustalania lokalizacji gps, zgodnej z teryt, etc.
Nie przyglądałem się jak to wpłynie na resztę zapytań związanych z tabelą networks. Pozdrawiam
W dniu 11/30/2015 o 11:31 AM, Ernest pisze:
Witajcie Panowie W dniu 11/27/2015 o 03:05 PM, Tomasz Chiliński pisze:
W dniu 27.11.2015 15:03, Tomasz Chiliński napisał(a):
W dniu 27.11.2015 14:07, Skiba Marek napisał(a):
W dniu 27 listopada 2015 13:29 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Przewidujesz od razu sprawdzanie, jak wybierze się przypisanie sieci, czy daną sieć można w ogóle przypisać (pewnie nie mogą być do takiej sieci żadne indywidualne komputery przypisane).
No właśnie zastanawiam się nad tym głębiej teraz. Bo mamy też przypadki gdzie dana firma ma całą podsieć (VLAN) dla siebie ale komputery są porozwalane geograficznie po całym mieście, więc należałoby pozwalać dodawać komputery do takiej podsieci aby określić np. fizyczną lokalizację komputera.
Jeśli masz taką sytuację jak piszesz to robisz sieć zwykłą i z niej kompy przypisujesz firmie. Pewnie te przypisania bez porządku i tak wynikały z tego, że LMS do tej pory nie pozwalał na przypisywanie całych sieci do klientów.
Rozwazcie jeszcze proszę taki scenariusz jak przypisanie klientowi komputera z adresem IP a.x.y.z jako routera dla jego sieci a.b.c.d/n
I jestem trochę w kropce bo powoli nie widzę sensu pakować podsieci
do tabeli nodes. Na dobrą sprawę będziemy wykorzystywać tylko pole "ownerid" i możemy zaadaptować też pole "chkmac" (żeby nie sprawdzało MACa dla całej podsieci), bo pozostałe raczej tyczą się komputerów niż mogą jakoś zostać wykorzystane do podsieci a te co mogą zostać wykorzystane do podsieci: name, ip, access jest też w kolumnie networks.
Lokalizacja teryt i gps są istotne jeśli całą sieć przydzielasz firmie w danej lokalizacji.
W dniu 22 grudnia 2015 13:14 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Tomku, widzę że dodajesz możliwość przypisywania sieci do klienta. nie sensowniej byłoby zmienić szablon tabeli networks i dodać tam pole nodeid (jeżeli puste/'0' to siec dostępna na dotychczasowych zasadach)?
Dla ułatwienia powstał widok vnetworks gdzie masz same sieci przypisane do Klientów.
W dniu 12/22/2015 o 01:31 PM, Skiba Marek pisze:
W dniu 22 grudnia 2015 13:14 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:
Tomku, widzę że dodajesz możliwość przypisywania sieci do klienta. nie sensowniej byłoby zmienić szablon tabeli networks i dodać tam pole nodeid (jeżeli puste/'0' to siec dostępna na dotychczasowych zasadach)?Dla ułatwienia powstał widok vnetworks gdzie masz same sieci przypisane do Klientów.
To może dlatego nie wyświetla mi przypisanej sieci. Gdzieś umknęła zmiana schemy i nie zrobił się widok. Co ciekawe po cofnięciu dbversion do 2015120201 zrobił ładnie update. Przeglądnąłem instalacyjną schemę i wygląda na to, że przy robieniu widoku mysql nie zna jeszcze funkcji mask2prefix.
Pozdrawiam
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
To może dlatego nie wyświetla mi przypisanej sieci. Gdzieś umknęła zmiana schemy i nie zrobił się widok. Co ciekawe po cofnięciu dbversion do 2015120201 zrobił ładnie update. Przeglądnąłem instalacyjną schemę i wygląda na to, że przy robieniu widoku mysql nie zna jeszcze funkcji mask2prefix.
Tak jak mówisz, zaraz wrzucę poprawkę.
Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ??
wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec)
bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci.
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie).
Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy.
Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port
W dniu 12/22/2015 o 01:59 PM, Skiba Marek pisze:
To może dlatego nie wyświetla mi przypisanej sieci. Gdzieś umknęła zmiana schemy i nie zrobił się widok. Co ciekawe po cofnięciu dbversion do 2015120201 <tel:2015120201> zrobił ładnie update. Przeglądnąłem instalacyjną schemę i wygląda na to, że przy robieniu widoku mysql nie zna jeszcze funkcji mask2prefix.Tak jak mówisz, zaraz wrzucę poprawkę.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 22 grudnia 2015 14:15 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ??
wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec)
bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci.
ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 a my robimy do niego link L3 10.0.11.11 - 10.0.11.10.
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie).
Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy.
Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port
W dniu 12/22/2015 o 01:59 PM, Skiba Marek pisze:
To może dlatego nie wyświetla mi przypisanej sieci.
Gdzieś umknęła zmiana schemy i nie zrobił się widok. Co ciekawe po cofnięciu dbversion do 2015120201 zrobił ładnie update. Przeglądnąłem instalacyjną schemę i wygląda na to, że przy robieniu widoku mysql nie zna jeszcze funkcji mask2prefix.
Tak jak mówisz, zaraz wrzucę poprawkę.
lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 22.12.2015 14:19, Marcin napisał(a):
W dniu 22 grudnia 2015 14:15 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ??
wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec)
bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci.
ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 [2] a my robimy do niego link L3 10.0.11.11 - 10.0.11.10.
Btw. a po co do sieci peeringowej /30. Lepiej dać /31.
W dniu 22 grudnia 2015 14:21 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 22.12.2015 14:19, Marcin napisał(a):
W dniu 22 grudnia 2015 14:15 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Marku, a dałoby się powiązać to jakoś z konkretnym komputerem
??
wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec)
bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci.
ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 [2] a my robimy do niego link L3 10.0.11.11 - 10.0.11.10.
Btw. a po co do sieci peeringowej /30. Lepiej dać /31.
Pewnie, że lepiej dać /31, czyli to jest nic innego jak P2P :) z tym, że nie wszystkie urządzenia przyjmują /31 więc trzeba elastycznie
-- Pozdrawiam Tomasz Chiliński, Chilan _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
właśnie o taki układ mi chodzi (nie licząc tej podsieci połączeniowej /30) bo jednak spora część providerów używa systemu mieszanego (jeśli klient chce podsieć do dostaje).
W dniu 12/22/2015 o 02:19 PM, Marcin pisze:
W dniu 22 grudnia 2015 14:15 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:
Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ?? wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec) bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci.ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 http://2.2.2.1/28 a my robimy do niego link L3 10.0.11.11 - 10.0.11.10.
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie). Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy. Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port W dniu 12/22/2015 o 01:59 PM, Skiba Marek pisze:To może dlatego nie wyświetla mi przypisanej sieci. Gdzieś umknęła zmiana schemy i nie zrobił się widok. Co ciekawe po cofnięciu dbversion do 2015120201 <tel:2015120201> zrobił ładnie update. Przeglądnąłem instalacyjną schemę i wygląda na to, że przy robieniu widoku mysql nie zna jeszcze funkcji mask2prefix. Tak jak mówisz, zaraz wrzucę poprawkę. _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms-- Pozdrawiam Michał Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 22 grudnia 2015 14:23 użytkownik Ernest ernest@poczta.tarman.pl napisał:
właśnie o taki układ mi chodzi (nie licząc tej podsieci połączeniowej /30) bo jednak spora część providerów używa systemu mieszanego (jeśli klient chce podsieć do dostaje).
ale czy używa mieszanego czy statystycznego to i tak należałoby podać trase routingu do tej sieci czy to będzie P2P czy coś innego z PPPoE.
W dniu 12/22/2015 o 02:19 PM, Marcin pisze:
W dniu 22 grudnia 2015 14:15 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ??
wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec)
bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci.
ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 a my robimy do niego link L3 10.0.11.11 - 10.0.11.10.
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie).
Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy.
Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port
W dniu 12/22/2015 o 01:59 PM, Skiba Marek pisze:
To może dlatego nie wyświetla mi przypisanej sieci.
Gdzieś umknęła zmiana schemy i nie zrobił się widok. Co ciekawe po cofnięciu dbversion do 2015120201 zrobił ładnie update. Przeglądnąłem instalacyjną schemę i wygląda na to, że przy robieniu widoku mysql nie zna jeszcze funkcji mask2prefix.
Tak jak mówisz, zaraz wrzucę poprawkę.
lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Marcin / nicraM
lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 12/22/2015 o 02:25 PM, Marcin pisze:
W dniu 22 grudnia 2015 14:23 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:
właśnie o taki układ mi chodzi (nie licząc tej podsieci połączeniowej /30) bo jednak spora część providerów używa systemu mieszanego (jeśli klient chce podsieć do dostaje).ale czy używa mieszanego czy statystycznego to i tak należałoby podać trase routingu do tej sieci czy to będzie P2P czy coś innego z PPPoE.
Dlatego potrzebne powiązanie z konkretnym nodem (jako WAN dla sieci)
W dniu 12/22/2015 o 02:19 PM, Marcin pisze:W dniu 22 grudnia 2015 14:15 użytkownik Ernest <ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>> napisał: Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ?? wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec) bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci. ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 <http://2.2.2.1/28> a my robimy do niego link L3 10.0.11.11 - 10.0.11.10. Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie). Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy. Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port W dniu 12/22/2015 o 01:59 PM, Skiba Marek pisze:To może dlatego nie wyświetla mi przypisanej sieci. Gdzieś umknęła zmiana schemy i nie zrobił się widok. Co ciekawe po cofnięciu dbversion do 2015120201 <tel:2015120201> zrobił ładnie update. Przeglądnąłem instalacyjną schemę i wygląda na to, że przy robieniu widoku mysql nie zna jeszcze funkcji mask2prefix. Tak jak mówisz, zaraz wrzucę poprawkę. _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms-- Pozdrawiam Michał Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms -- Pozdrawiam Marcin / nicraM _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms-- Pozdrawiam Michał Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 2015-12-22 o 14:27, Ernest pisze:
W dniu 12/22/2015 o 02:25 PM, Marcin pisze:
W dniu 22 grudnia 2015 14:23 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:
właśnie o taki układ mi chodzi (nie licząc tej podsieci połączeniowej /30) bo jednak spora część providerów używa systemu mieszanego (jeśli klient chce podsieć do dostaje).ale czy używa mieszanego czy statystycznego to i tak należałoby podać trase routingu do tej sieci czy to będzie P2P czy coś innego z PPPoE.
Dlatego potrzebne powiązanie z konkretnym nodem (jako WAN dla sieci)
W dniu 12/22/2015 o 02:19 PM, Marcin pisze:W dniu 22 grudnia 2015 14:15 użytkownik Ernest <ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>> napisał: Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ?? wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec) bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci. ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 <http://2.2.2.1/28> a my robimy do niego link L3 10.0.11.11 - 10.0.11.10.
A co jak klient ma wydzielony vlan TYLKO dla niego?? I na tym vlanie/ na routerze ma podsieć /29??
W dniu 22 grudnia 2015 17:36 użytkownik Arturz arturz@kl.net.pl napisał:
W dniu 2015-12-22 o 14:27, Ernest pisze:
W dniu 12/22/2015 o 02:25 PM, Marcin pisze:
W dniu 22 grudnia 2015 14:23 użytkownik Ernest < ernest@poczta.tarman.pl ernest@poczta.tarman.pl> napisał:
właśnie o taki układ mi chodzi (nie licząc tej podsieci połączeniowej /30) bo jednak spora część providerów używa systemu mieszanego (jeśli klient chce podsieć do dostaje).
ale czy używa mieszanego czy statystycznego to i tak należałoby podać trase routingu do tej sieci czy to będzie P2P czy coś innego z PPPoE.
Dlatego potrzebne powiązanie z konkretnym nodem (jako WAN dla sieci)
W dniu 12/22/2015 o 02:19 PM, Marcin pisze:
W dniu 22 grudnia 2015 14:15 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ??
wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec)
bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci.
ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 a my robimy do niego link L3 10.0.11.11 - 10.0.11.10.
A co jak klient ma wydzielony vlan TYLKO dla niego?? I na tym vlanie/ na
routerze ma podsieć /29??
Jest to analogiczna sytuacja jak piszemy wcześniej. Robisz sieć na interfejsie vlan, przypisujesz adresy. robisz sieć dla klienta, później ją mu przypisujesz i w adresie routingowym wskazujesz przyznany adres klienta.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 12/22/2015 o 05:40 PM, Marcin pisze:
W dniu 22 grudnia 2015 17:36 użytkownik Arturz <arturz@kl.net.pl mailto:arturz@kl.net.pl> napisał:
W dniu 2015-12-22 o 14:27, Ernest pisze:W dniu 12/22/2015 o 02:25 PM, Marcin pisze:W dniu 22 grudnia 2015 14:23 użytkownik Ernest <ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>> napisał: właśnie o taki układ mi chodzi (nie licząc tej podsieci połączeniowej /30) bo jednak spora część providerów używa systemu mieszanego (jeśli klient chce podsieć do dostaje). ale czy używa mieszanego czy statystycznego to i tak należałoby podać trase routingu do tej sieci czy to będzie P2P czy coś innego z PPPoE.Dlatego potrzebne powiązanie z konkretnym nodem (jako WAN dla sieci)W dniu 12/22/2015 o 02:19 PM, Marcin pisze:W dniu 22 grudnia 2015 14:15 użytkownik Ernest <ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>> napisał: Marku, a dałoby się powiązać to jakoś z konkretnym komputerem ?? wg schematu router_głowny ==> (IP_WAN_komp_klienta) router_klienta (przydzielona_podsiec) bo w tej chwili wiadomo tylko, że dana podsieć jest przydzielona klientowi jeżeli będzie on miał kilka komputerów to nie wiadomo, który jest odpowiedzialny za dalszy routing tej sieci. ja bym poszedł krok dalej. klientowi przypisujemy sieć, spoko niech używa jak chce, ale my do niego delegujemy jakieś adresy P2P (wykorzystujemy jedynie dwa IPKI) albo /30 by zapewnić routing, czyli np. klient ma sieć 2.2.2.1/28 <http://2.2.2.1/28> a my robimy do niego link L3 10.0.11.11 - 10.0.11.10.A co jak klient ma wydzielony vlan TYLKO dla niego?? I na tym vlanie/ na routerze ma podsieć /29??Jest to analogiczna sytuacja jak piszemy wcześniej. Robisz sieć na interfejsie vlan, przypisujesz adresy. robisz sieć dla klienta, później ją mu przypisujesz i w adresie routingowym wskazujesz przyznany adres klienta.
A gdyby tak dodać 2 kolumny do tabeli networks (nodeid-1, customerid-2) przy założeniach: 1==0 && 2 ==0 --sieć na dotychczasowych zasadach; (1==id && 2==0) --sieć klienta routowana via nodeid; (1==0 && 2==customerid) --sieć klienta routowana bezpośrednio na iface routera;
_______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Ernest napisał:
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie).
Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy.
Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port
Jednej centrali czy kilka centralek można mieć? tylko voip czy też nie powinno być checkbox voip/PSTN?
Czy CDR będziesz kiedyś sciągał do LMS??
Witaj
Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska
Co do CDRów kwestia zastanowienia(może osobna wtyczka)? ;)
Można się pokusić o dodanie gotowej wyceny opartej o istniejącą bazę z CDR-ami (zapewne do userpanel - czyli podsuma na bieżąco).
Więc najprościej import danych z programu billingowego.
Lub pełne rozliczenia rekordów czyli program billingowy ( to już napewno osobna wtyczka i dodatki do importu danych). Teraz pytanie czy tylko rozliczenie klienta, czy tez nas jako operatora, czy oba. (Różne stawki, różne przedziały czasowe dla stawek, abonamenty, etc.) I zaczyna się robić już spory projekcik ;)
W dniu 12/22/2015 o 02:54 PM, Arturz pisze:
Ernest napisał:
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie).
Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy.
Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port
Jednej centrali czy kilka centralek można mieć? tylko voip czy też nie powinno być checkbox voip/PSTN?
Czy CDR będziesz kiedyś sciągał do LMS??
W dniu 2015-12-22 o 15:35, Ernest pisze:
Witaj
Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska
Co do CDRów kwestia zastanowienia(może osobna wtyczka)? ;)
Można się pokusić o dodanie gotowej wyceny opartej o istniejącą bazę z CDR-ami (zapewne do userpanel - czyli podsuma na bieżąco).
Więc najprościej import danych z programu billingowego.
Lub pełne rozliczenia rekordów czyli program billingowy ( to już napewno osobna wtyczka i dodatki do importu danych).
Po namyśle cdr z systemu bilingowego lub bezpośrednio z central to MUSI BYĆ osobna wtyczka. Nie każdemu to potrzebne a pracy jest trochę. Jeśli import z systemów telekomunikacyjnych to trzeba przewidzieć 4 typy importu: sql z pliku lub "zdalnie" text z pliku lub ftp binarnie dostarczasz plik zakodowany, a każdy może napisać sobie (lub zamówić) dekoder do cdr. webserwis - każdy może napisać sobie (lub zamówić)
Teraz pytanie czy tylko rozliczenie klienta, czy tez nas jako operatora, czy oba. (Różne stawki, różne przedziały czasowe dla stawek, abonamenty, etc.) I zaczyna się robić już spory projekcik ;)
Rozliczenie operatora zrobiłbym w osobnej wtyczce. Nie każdy potrzebuje. A wymagania operatorów co do raportów / rozliczeń są ...... różne ;-P I czasami wymagane jest pobranie raportu od operatora i porównanie z naszym.
W dniu 12/22/2015 o 02:54 PM, Arturz pisze:
Ernest napisał:
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie).
Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy.
Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port
Jednej centrali czy kilka centralek można mieć? tylko voip czy też nie powinno być checkbox voip/PSTN?
Czy CDR będziesz kiedyś sciągał do LMS??
W dniu 12/22/2015 o 05:48 PM, Arturz pisze:
W dniu 2015-12-22 o 15:35, Ernest pisze:
Witaj
Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska
Co do CDRów kwestia zastanowienia(może osobna wtyczka)? ;)
Można się pokusić o dodanie gotowej wyceny opartej o istniejącą bazę z CDR-ami (zapewne do userpanel - czyli podsuma na bieżąco).
Więc najprościej import danych z programu billingowego.
Lub pełne rozliczenia rekordów czyli program billingowy ( to już napewno osobna wtyczka i dodatki do importu danych).
Po namyśle cdr z systemu bilingowego lub bezpośrednio z central to MUSI BYĆ osobna wtyczka. Nie każdemu to potrzebne a pracy jest trochę.
Mając surowe CDRy musisz je jakoś wycenić w zależności od tego jakie parametry ma ustawiony klient(cena danego typu połączeń, minuty abonamentowe, ....) i ewentualnie musisz zrobić drugą wycenę tego samego rekordu do rozliczenia operatorskiego. ;)
Jeśli import z systemów telekomunikacyjnych to trzeba przewidzieć 4 typy importu: sql z pliku lub "zdalnie" text z pliku lub ftp binarnie dostarczasz plik zakodowany, a każdy może napisać sobie (lub zamówić) dekoder do cdr. webserwis - każdy może napisać sobie (lub zamówić)
To załatwia TYLKO system importu danych ;) Nie bardzo tylko rozumiem "binarnie", chodzi o wewnętrzny format CDR centrali??
Teraz pytanie czy tylko rozliczenie klienta, czy tez nas jako operatora, czy oba. (Różne stawki, różne przedziały czasowe dla stawek, abonamenty, etc.) I zaczyna się robić już spory projekcik ;)
Rozliczenie operatora zrobiłbym w osobnej wtyczce. Nie każdy potrzebuje. A wymagania operatorów co do raportów / rozliczeń są ...... różne ;-P I czasami wymagane jest pobranie raportu od operatora i porównanie z naszym.
Zwykle raport robią 2 strony. Stare umowy z TPSA wymagały 2 raportów i jeżeli różnica w kategorii połączeń była większa niż bodajże 1% to stosowane było 2 stronne dochodzenie dlaczego i uzgodnienie wersji, jeżeli różnice były mniejsze niż 1% (bo zawsze wychodzą) to obie strony wystawiały sobie FA ze średniej.
W dniu 12/22/2015 o 02:54 PM, Arturz pisze:
Ernest napisał:
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie).
Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy.
Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port
Jednej centrali czy kilka centralek można mieć? tylko voip czy też nie powinno być checkbox voip/PSTN?
Czy CDR będziesz kiedyś sciągał do LMS??
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Witajcie
Do podglądnięcia i zasugerowania co jeszcze należy uwzględnić. Jak na razie to tylko szkic (prawie same szablony) .
http://lmstest.hades.tarman.pl 'demo', 'Demo1234'
W dniu 12/23/2015 o 08:20 AM, Ernest pisze:
W dniu 12/22/2015 o 05:48 PM, Arturz pisze:
W dniu 2015-12-22 o 15:35, Ernest pisze:
Witaj
Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska
Co do CDRów kwestia zastanowienia(może osobna wtyczka)? ;)
Można się pokusić o dodanie gotowej wyceny opartej o istniejącą bazę z CDR-ami (zapewne do userpanel - czyli podsuma na bieżąco).
Więc najprościej import danych z programu billingowego.
Lub pełne rozliczenia rekordów czyli program billingowy ( to już napewno osobna wtyczka i dodatki do importu danych).
Po namyśle cdr z systemu bilingowego lub bezpośrednio z central to MUSI BYĆ osobna wtyczka. Nie każdemu to potrzebne a pracy jest trochę.
Mając surowe CDRy musisz je jakoś wycenić w zależności od tego jakie parametry ma ustawiony klient(cena danego typu połączeń, minuty abonamentowe, ....) i ewentualnie musisz zrobić drugą wycenę tego samego rekordu do rozliczenia operatorskiego. ;)
Jeśli import z systemów telekomunikacyjnych to trzeba przewidzieć 4 typy importu: sql z pliku lub "zdalnie" text z pliku lub ftp binarnie dostarczasz plik zakodowany, a każdy może napisać sobie (lub zamówić) dekoder do cdr. webserwis - każdy może napisać sobie (lub zamówić)
To załatwia TYLKO system importu danych ;) Nie bardzo tylko rozumiem "binarnie", chodzi o wewnętrzny format CDR centrali??
Teraz pytanie czy tylko rozliczenie klienta, czy tez nas jako operatora, czy oba. (Różne stawki, różne przedziały czasowe dla stawek, abonamenty, etc.) I zaczyna się robić już spory projekcik ;)
Rozliczenie operatora zrobiłbym w osobnej wtyczce. Nie każdy potrzebuje. A wymagania operatorów co do raportów / rozliczeń są ...... różne ;-P I czasami wymagane jest pobranie raportu od operatora i porównanie z naszym.
Zwykle raport robią 2 strony. Stare umowy z TPSA wymagały 2 raportów i jeżeli różnica w kategorii połączeń była większa niż bodajże 1% to stosowane było 2 stronne dochodzenie dlaczego i uzgodnienie wersji, jeżeli różnice były mniejsze niż 1% (bo zawsze wychodzą) to obie strony wystawiały sobie FA ze średniej.
W dniu 12/22/2015 o 02:54 PM, Arturz pisze:
Ernest napisał:
Dopisuje sobie teraz wtyczkę do voipa i pytanie czy ktoś jest chętny (chodzi o zrobienie czegoś bardziej uniwersalnego niż tylko dla mnie).
Nie wiem jak jest rozwiązywane wiązanie voip jako resseler (hiperus, t-mobile) ale oni chyba daja swoje pluginy.
Wstępnie przewiduję dowiązanie do tabeli voipaccounts centrali, ilości DDI(przy SIP trunkach), voice`a(jesli ktoś używa cisco), netdev_id, devtev_port
Jednej centrali czy kilka centralek można mieć? tylko voip czy też nie powinno być checkbox voip/PSTN?
Czy CDR będziesz kiedyś sciągał do LMS??
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Witam w Nowym Roku ;)
Brak uwag, czy brak chętnych na wtyczkę ?? ;(
W dniu 12/28/2015 o 11:28 AM, Ernest pisze:
Witajcie
Do podglądnięcia i zasugerowania co jeszcze należy uwzględnić. Jak na razie to tylko szkic (prawie same szablony) .
http://lmstest.hades.tarman.pl 'demo', 'Demo1234'
W dniu 12/23/2015 o 08:20 AM, Ernest pisze:
W dniu 12/22/2015 o 05:48 PM, Arturz pisze:
W dniu 2015-12-22 o 15:35, Ernest pisze:
Witaj
Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska
Witam
Na tym demie masz to ogarnięte już z Asteriskiem czy dajmy na to SIPy póki co lecą po prostu do/z bazy?
W dniu 11 stycznia 2016 11:31 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Witam w Nowym Roku ;)
Brak uwag, czy brak chętnych na wtyczkę ?? ;(
W dniu 12/28/2015 o 11:28 AM, Ernest pisze:
Witajcie
Do podglądnięcia i zasugerowania co jeszcze należy uwzględnić. Jak na razie to tylko szkic (prawie same szablony) .
http://lmstest.hades.tarman.pl 'demo', 'Demo1234'
W dniu 12/23/2015 o 08:20 AM, Ernest pisze:
W dniu 12/22/2015 o 05:48 PM, Arturz pisze:
W dniu 2015-12-22 o 15:35, Ernest pisze:
Witaj
Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 01/14/2016 o 08:34 AM, Rafał Z. pisze:
Witam
Na tym demie masz to ogarnięte już z Asteriskiem czy dajmy na to SIPy póki co lecą po prostu do/z bazy?
Aktualnie leci po prostu do bazy (i tylko w takim wymiarze danych jakie widać) ale nic nie stoi na przeszkodzie żeby ich ożenić ;).
U siebie mam to rozdzielone. Baza asteriska jest synchronizowana skryptem w cronie. Chcąc zachować spójność LMS`a (chciałem żeby po wyłączeniu pluginu podstawowe dane kont voipowych były nadal widoczne w LMS), plugin musi korzystać z LMS`owej tabeli voipaccounts. Zresztą inne wtyczki też będą/są dostosowane do podstawowej struktury bazy LMS.
Jedyna możliwość ich połączenia(w sensie synchronizacji ) to eksport danych do osobnej tabeli/bazy samej centrali (* ma też swoje wymagania co do struktury tabel) na zasadzie kontrolki przeładuj ustawienia.
Jeżeli jesteś zainteresowany takim mariażem to daj znać ;).
Zastanawiam się nad napisaniem billingowania pod LMS tylko nie wiem jakie byłoby zainteresowanie ;)
W dniu 11 stycznia 2016 11:31 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:
Witam w Nowym Roku ;) Brak uwag, czy brak chętnych na wtyczkę ?? ;( W dniu 12/28/2015 o 11:28 AM, Ernest pisze: Witajcie Do podglądnięcia i zasugerowania co jeszcze należy uwzględnić. Jak na razie to tylko szkic (prawie same szablony) . http://lmstest.hades.tarman.pl 'demo', 'Demo1234' W dniu 12/23/2015 o 08:20 AM, Ernest pisze: W dniu 12/22/2015 o 05:48 PM, Arturz pisze: W dniu 2015-12-22 o 15:35, Ernest pisze: Witaj Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska -- Pozdrawiam Michał Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Może nie jedyny - zawsze można jeszcze w prosty sposób generować pliki konfiguracyjne, tworzyć własne cdrki np per user itd. Co myślisz/myślicie o takim pomyśle?
W dniu 14 stycznia 2016 09:54 użytkownik Ernest ernest@poczta.tarman.pl napisał:
W dniu 01/14/2016 o 08:34 AM, Rafał Z. pisze:
Witam
Na tym demie masz to ogarnięte już z Asteriskiem czy dajmy na to SIPy póki co lecą po prostu do/z bazy?
Aktualnie leci po prostu do bazy (i tylko w takim wymiarze danych jakie widać) ale nic nie stoi na przeszkodzie żeby ich ożenić ;).
U siebie mam to rozdzielone. Baza asteriska jest synchronizowana skryptem w cronie. Chcąc zachować spójność LMS`a (chciałem żeby po wyłączeniu pluginu podstawowe dane kont voipowych były nadal widoczne w LMS), plugin musi korzystać z LMS`owej tabeli voipaccounts. Zresztą inne wtyczki też będą/są dostosowane do podstawowej struktury bazy LMS.
Jedyna możliwość ich połączenia(w sensie synchronizacji ) to eksport danych do osobnej tabeli/bazy samej centrali (* ma też swoje wymagania co do struktury tabel) na zasadzie kontrolki przeładuj ustawienia.
Jeżeli jesteś zainteresowany takim mariażem to daj znać ;).
Zastanawiam się nad napisaniem billingowania pod LMS tylko nie wiem jakie byłoby zainteresowanie ;)
W dniu 11 stycznia 2016 11:31 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Witam w Nowym Roku ;)
Brak uwag, czy brak chętnych na wtyczkę ?? ;(
W dniu 12/28/2015 o 11:28 AM, Ernest pisze:
Witajcie
Do podglądnięcia i zasugerowania co jeszcze należy uwzględnić. Jak na razie to tylko szkic (prawie same szablony) .
http://lmstest.hades.tarman.pl 'demo', 'Demo1234'
W dniu 12/23/2015 o 08:20 AM, Ernest pisze:
W dniu 12/22/2015 o 05:48 PM, Arturz pisze:
W dniu 2015-12-22 o 15:35, Ernest pisze:
Witaj
Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 01/14/2016 o 10:13 PM, Rafał Z. pisze:
Może nie jedyny - zawsze można jeszcze w prosty sposób generować pliki konfiguracyjne, tworzyć własne cdrki np per user itd. Co myślisz/myślicie o takim pomyśle?
Konfiguracja statyczna vs realtime(z bazy)? Każdy szyje system tak jak lubi/potrafi ;) ja jednak stawiam na konfigurację mieszaną (użytkownicy z bazy, dialplan statyczny) ze względu na brak przeładowań bazy użytkowników. Asterisk co prawda pozwala również na konfigurację dialplanów w bazie, ale mechanizm wybierania rekordów do dialplanu jest tam strasznie pogmatwany (jakieś dziwne skoki po priorytetach) .
Co do CDRów to pakując je do bazy nie musisz się bawić w rozdzielanie ich per user bo może ci to załatwić dialplan(w sensie dodatkowych znacznikówrekordu) i/lub odpowiednie zapytanie SQL. Rozdzielenie CDRów na pliki per user tylko komplikuje taryfikację.
W dniu 14 stycznia 2016 09:54 użytkownik Ernest <ernest@poczta.tarman.pl mailto:ernest@poczta.tarman.pl> napisał:
W dniu 01/14/2016 o 08:34 AM, Rafał Z. pisze:Witam Na tym demie masz to ogarnięte już z Asteriskiem czy dajmy na to SIPy póki co lecą po prostu do/z bazy?Aktualnie leci po prostu do bazy (i tylko w takim wymiarze danych jakie widać) ale nic nie stoi na przeszkodzie żeby ich ożenić ;). U siebie mam to rozdzielone. Baza asteriska jest synchronizowana skryptem w cronie. Chcąc zachować spójność LMS`a (chciałem żeby po wyłączeniu pluginu podstawowe dane kont voipowych były nadal widoczne w LMS), plugin musi korzystać z LMS`owej tabeli voipaccounts. Zresztą inne wtyczki też będą/są dostosowane do podstawowej struktury bazy LMS. Jedyna możliwość ich połączenia(w sensie synchronizacji ) to eksport danych do osobnej tabeli/bazy samej centrali (* ma też swoje wymagania co do struktury tabel) na zasadzie kontrolki przeładuj ustawienia. Jeżeli jesteś zainteresowany takim mariażem to daj znać ;). Zastanawiam się nad napisaniem billingowania pod LMS tylko nie wiem jakie byłoby zainteresowanie ;)W dniu 11 stycznia 2016 11:31 użytkownik Ernest <ernest@poczta.tarman.pl <mailto:ernest@poczta.tarman.pl>> napisał: Witam w Nowym Roku ;) Brak uwag, czy brak chętnych na wtyczkę ?? ;( W dniu 12/28/2015 o 11:28 AM, Ernest pisze: Witajcie Do podglądnięcia i zasugerowania co jeszcze należy uwzględnić. Jak na razie to tylko szkic (prawie same szablony) . http://lmstest.hades.tarman.pl 'demo', 'Demo1234' W dniu 12/23/2015 o 08:20 AM, Ernest pisze: W dniu 12/22/2015 o 05:48 PM, Arturz pisze: W dniu 2015-12-22 o 15:35, Ernest pisze: Witaj Właśnie po to ten wątek ;) w założeniu: -kilka (co najmniej jedna) central ;) -technologia mieszana voip/pstn --VOIP -statyczni klienci cisco(gatekeeper) i asteriska -- Pozdrawiam Michał Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms-- Pozdrawiam Michał Szmigielski /ernesttar/ _______________________________________________ lms mailing list lms@lists.lms.org.pl <mailto:lms@lists.lms.org.pl> http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 2016-01-15 o 08:19, Ernest pisze:
W dniu 01/14/2016 o 10:13 PM, Rafał Z. pisze:
Może nie jedyny - zawsze można jeszcze w prosty sposób generować pliki konfiguracyjne, tworzyć własne cdrki np per user itd. Co myślisz/myślicie o takim pomyśle?
Konfiguracja statyczna vs realtime(z bazy)? Każdy szyje system tak jak lubi/potrafi ;) ja jednak stawiam na konfigurację mieszaną (użytkownicy z bazy, dialplan statyczny) ze względu na brak przeładowań bazy użytkowników. Asterisk co prawda pozwala również na konfigurację dialplanów w bazie, ale mechanizm wybierania rekordów do dialplanu jest tam strasznie pogmatwany (jakieś dziwne skoki po priorytetach) .
Możesz podrzucić jakiś link na ten temat??
Co do CDRów to pakując je do bazy nie musisz się bawić w rozdzielanie ich per user bo może ci to załatwić dialplan(w sensie dodatkowych znacznikówrekordu) i/lub odpowiednie zapytanie SQL. Rozdzielenie CDRów na pliki per user tylko komplikuje taryfikację.
Ernes tma rację. Lepiej dodać pole do bazy <numer_klienta> i to pole wypełniać podczas preanalizy. Potem możesz pracować na takim zestawie.
Nie sprawdzałem, ale czy CDR mają pola/rekordy łacze wejściowe / wyjsciowe ?? Potem jakby ktoś chciał dorobić raporty między operatorskie będzie jak znalazł.
W dniu 01/15/2016 o 08:51 AM, Arturz pisze:
W dniu 2016-01-15 o 08:19, Ernest pisze:
W dniu 01/14/2016 o 10:13 PM, Rafał Z. pisze:
Może nie jedyny - zawsze można jeszcze w prosty sposób generować pliki konfiguracyjne, tworzyć własne cdrki np per user itd. Co myślisz/myślicie o takim pomyśle?
Konfiguracja statyczna vs realtime(z bazy)? Każdy szyje system tak jak lubi/potrafi ;) ja jednak stawiam na konfigurację mieszaną (użytkownicy z bazy, dialplan statyczny) ze względu na brak przeładowań bazy użytkowników. Asterisk co prawda pozwala również na konfigurację dialplanów w bazie, ale mechanizm wybierania rekordów do dialplanu jest tam strasznie pogmatwany (jakieś dziwne skoki po priorytetach) .
Możesz podrzucić jakiś link na ten temat??
Nie pamiętam już jak to było z tymi skokami po bazie, ale generalnie asterisk na dzień dobry próbuje znaleźć rekord dokładnie pasujący do wybieranego numeru a potem kombinuje http://www.voip-info.org/wiki/view/Asterisk+RealTime+Extensions Przy niewielkiej liczbie często zmieniających się wpisów może być to opłacalne, ale jeśli mamy kilka-set/tyś wpisów to już nie jest tak różowo (każde zapytanie to połączenie z baza i wykonanie sql`a == spory narzut czasowy)
IMHO lepiej zrobić "inteligentny" statyczny dialplan oparty o konta w bazie i w dodatkowych makrach sprawdzać np. uprawnienia klienta dopisać mu jakieś zmienne. Mój "core" dialplanu ma raptem 4 wpisy i chyba z 10 makr
Co do CDRów to pakując je do bazy nie musisz się bawić w rozdzielanie ich per user bo może ci to załatwić dialplan(w sensie dodatkowych znacznikówrekordu) i/lub odpowiednie zapytanie SQL. Rozdzielenie CDRów na pliki per user tylko komplikuje taryfikację.
Ernes tma rację. Lepiej dodać pole do bazy <numer_klienta> i to pole wypełniać podczas preanalizy. Potem możesz pracować na takim zestawie.
Nie sprawdzałem, ale czy CDR mają pola/rekordy łacze wejściowe / wyjsciowe ?? Potem jakby ktoś chciał dorobić raporty między operatorskie będzie jak znalazł.
CDRy możesz składować w kilku rożnych miejscach (pliki, baza1, baza2) równolegle i nie ma to jakiegoś szczególnego narzutu na wydajność. U siebie mam składowanie w plikach /tak na zapas ;)/ + sqlite ( cdr-mysql wtedy jeszcze raczkował ) i jakoś nie bardzo mam chęci przerabiać cały system na MySQL tylko dla siebie ;)
Co do łączy WE/WY to trzeba sobie to samemu ogarnąć. Asterisk zapisuje tylko pola AcctId, clid, src, dst, dcontext, channel, dstchannel, lastapp, lastdata, start, answer, end, duration, billsec, disposition, amaflags, accountcode, uniqueid, userfield Ja robię to zapisując accountcode w postaci src_klient_id:dst_klient_id w przypadku wiązek "zewnętrznych" podstawiając wirtualnego klienta zależnego od wiązki wejściowej. Można też samemu przejąć zapisywanie CDRów( zmienne są dostępne z poziomu dialplanu) i wtedy można zapisać wszystko co się wymyśli ;).
-- Art
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Witajcie.
Została lokalizacja do zrobienia i wybieranie numeru tel z listy. I ewentualnie jakieś dodatkowe specyficzne rzeczy np dla asteriska. Chyba, że dorobić jeszcze jakieś czary dla samych kont sipowych (np call-limit, dyskryminator) dajcie znać co jeszcze może się przydać.
http://lmstest.hades.tarman.pl 'demo', 'Demo1234'
"Asterisk co prawda pozwala również na konfigurację dialplanów w bazie, ale mechanizm wybierania rekordów do dialplanu jest tam strasznie pogmatwany (jakieś dziwne skoki po priorytetach)."
Właśnie to było głównym powodem tego że postanowiłem darować sobie bazy.
A możesz powiedzieć jak to wygląda w przypadku ładowania logów/cdrek do tabel? Na plikach jest to realizowane na bieżąco. Czy w przypadku bazy nie jest generowane jakieś znaczące obciążenie z tego tytułu?
W dniu 15 stycznia 2016 08:19 użytkownik Ernest ernest@poczta.tarman.pl napisał:
W dniu 01/14/2016 o 10:13 PM, Rafał Z. pisze:
Może nie jedyny - zawsze można jeszcze w prosty sposób generować pliki konfiguracyjne, tworzyć własne cdrki np per user itd. Co myślisz/myślicie o takim pomyśle?
Konfiguracja statyczna vs realtime(z bazy)? Każdy szyje system tak jak lubi/potrafi ;) ja jednak stawiam na konfigurację mieszaną (użytkownicy z bazy, dialplan statyczny) ze względu na brak przeładowań bazy użytkowników. Asterisk co prawda pozwala również na konfigurację dialplanów w bazie, ale mechanizm wybierania rekordów do dialplanu jest tam strasznie pogmatwany (jakieś dziwne skoki po priorytetach) .
Co do CDRów to pakując je do bazy nie musisz się bawić w rozdzielanie ich per user bo może ci to załatwić dialplan(w sensie dodatkowych znacznikówrekordu) i/lub odpowiednie zapytanie SQL. Rozdzielenie CDRów na pliki per user tylko komplikuje taryfikację.
W dniu 14 stycznia 2016 09:54 użytkownik Ernest ernest@poczta.tarman.pl napisał:
W dniu 01/14/2016 o 08:34 AM, Rafał Z. pisze:
Witam
Na tym demie masz to ogarnięte już z Asteriskiem czy dajmy na to SIPy póki co lecą po prostu do/z bazy?
Aktualnie leci po prostu do bazy (i tylko w takim wymiarze danych jakie widać) ale nic nie stoi na przeszkodzie żeby ich ożenić ;).
U siebie mam to rozdzielone. Baza asteriska jest synchronizowana skryptem w cronie. Chcąc zachować spójność LMS`a (chciałem żeby po wyłączeniu pluginu podstawowe dane kont voipowych były nadal widoczne w LMS), plugin musi korzystać z LMS`owej tabeli voipaccounts. Zresztą inne wtyczki też będą/są dostosowane do podstawowej struktury bazy LMS.
Jedyna możliwość ich połączenia(w sensie synchronizacji ) to eksport danych do osobnej tabeli/bazy samej centrali (* ma też swoje wymagania co do struktury tabel) na zasadzie kontrolki przeładuj ustawienia.
Jeżeli jesteś zainteresowany takim mariażem to daj znać ;).
Zastanawiam się nad napisaniem billingowania pod LMS tylko nie wiem jakie byłoby zainteresowanie ;)
W dniu 11 stycznia 2016 11:31 użytkownik Ernest ernest@poczta.tarman.pl napisał:
Witam w Nowym Roku ;)
Brak uwag, czy brak chętnych na wtyczkę ?? ;(
W dniu 12/28/2015 o 11:28 AM, Ernest pisze:
Witajcie
Do podglądnięcia i zasugerowania co jeszcze należy uwzględnić. Jak na razie to tylko szkic (prawie same szablony) .
http://lmstest.hades.tarman.pl 'demo', 'Demo1234'
W dniu 12/23/2015 o 08:20 AM, Ernest pisze:
W dniu 12/22/2015 o 05:48 PM, Arturz pisze:
W dniu 2015-12-22 o 15:35, Ernest pisze:
> Witaj > > Właśnie po to ten wątek ;) > w założeniu: > -kilka (co najmniej jedna) central ;) > -technologia mieszana voip/pstn > --VOIP -statyczni klienci cisco(gatekeeper) i asteriska > >
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing listlms@lists.lms.org.plhttp://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Michał Szmigielski /ernesttar/
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
uczestnicy (7)
-
Arturz -
Ernest -
Marcin -
Rafał Z. -
Skiba Marek -
Tomasz Chiliński -
Waldemar Dymkiewicz