PLNOG 13, Kraków, 30 września 2014
● o mnie
● dlaczego ten temat ?
Trudny klient biznesowy – VoIP i modemy
PLNOG 13, Kraków, 30 września 2014
● terminale POS
● zarządzanie centralami
● urządzenia medyczne, raportowanie/serwiso...
PLNOG 13, Kraków, 30 września 2014
Przykładowe urządzenie medyczne
PLNOG 13, Kraków, 30 września 2014
Jak działa klasyczna sieć PSTN/POTS ?
● analog <-> digital
● próbkowanie 8kHz – czyl...
PLNOG 13, Kraków, 30 września 2014
Jak działa klasyczna sieć PSTN/POTS ?
ADC
ADC
PSTN
SWITCH
PSTN
SWITCH
PSTN
E0 ...
PLNOG 13, Kraków, 30 września 2014
SoftSwitch – czyli dlaczego wymóg
„nie VoIP” jest absurdalny
ADC
ADC
IP
E0 – 64k ...
PLNOG 13, Kraków, 30 września 2014
V.29: A one-way (half-duplex) standard that is used mostly for fax machines. Capable o...
PLNOG 13, Kraków, 30 września 2014
V.21 (300 b/s) for the T.30 procedures
V.27ter (4800/2400 b/s) for image transfer
V....
PLNOG 13, Kraków, 30 września 2014
16 QAM
Co się stanie jak zgubimy próbkę ?
PLNOG 13, Kraków, 30 września 2014
O co chodzi z V.90 ?
ADC
E0 – 64k
300-3400Hz BandPass Filter
Analog -> Digital
No...
PLNOG 13, Kraków, 30 września 2014
E1 <-> SIP
E1 <-> SIP
IP
2MHz
G.711/RTP
Codec
G.711/RTP Codec
Dlaczego w VoIP m...
PLNOG 13, Kraków, 30 września 2014
Czy to się da jakoś rozwiązać ? - Synchronizowac !
E1 <-> SIP
E1 <-> SIP
IP
2MHz
...
PLNOG 13, Kraków, 30 września 2014
Jak synchronizować ?
-Bramy VoIP synchronizujące swój zegar z centralą nadrzędną, zsy...
PLNOG 13, Kraków, 30 września 2014
Jak synchronizować ?
-E1 w kierunku klienta przepuścić przez sieć SDH przez co brama ...
PLNOG 13, Kraków, 30 września 2014
Jak synchronizować ?
-„pożyczyć” zegar np. z ISDN BRI
E1 <-> SIP
E1 <-> SIP
IP
G....
PLNOG 13, Kraków, 30 września 2014
Jakieś mądre protokoły ?
-FAXy – T.38
-Modemy – V.150.1 (V.MOIP)
E1 <-> SIP
E1 <->...
PLNOG 13, Kraków, 30 września 2014
A co jak nie zsynchronizujemy ?
-Obniżamy prędkość modemów (komendy AT ;) (ata, atdt2...
PLNOG 13, Kraków, 30 września 2014
Przykład 1
E1 <-> SIP
IP
G.711
PBX
PSTN
E1
E1
E1 <-> SIP
E1 <-> SIP
E1 <-> S...
PLNOG 13, Kraków, 30 września 2014
Przykład 2
IP
G.711
Bamka SIP-FXS
PSTN
E1
E1 <-> SIP
Medical ECG reporting
dev...
PLNOG 13, Kraków, 30 września 2014
Pytania
?
PLNOG 13, Kraków, 30 września 2014
W przypadku pytań:
Marcin Kuczera
E-mail: marcin.kuczera@leon.pl
of 21

PLNOG 13: Marcin Kuczera: Difficult business client – VOIP and modem data transmission

Marcin Kuczera – Short about: Born in 1976 in Rybnik, Poland. In 2004 finished Silesian Technical University in Gliwice, specialization Electronics/Telecommunicaions. Since 2002 – board member in own telecom – Leon Sp. z o.o. (www.leon.pl). In a meantime I conduct telecom trainings (mobile networks infrastructure, mostly for Ericsson) – because I love travelling ;) Happily married, son Jeremi and daughters Łucja and Malwina. Recently I try to learn how to play on piano! Topic of Presentation: Difficult business client – VOIP and modem data transmission Language: Polish Abstract: Alternative telecoms start offering their services on big telecoms market domain, providing services i.e. for hospitals (telephony services). And than – surprise – very important medical equipment that requires modem data transmission for servicing and reporting. And – this MUST work, which in VOIP is not that obvious…
Published on: Mar 4, 2016
Published in: Internet      
Source: www.slideshare.net


Transcripts - PLNOG 13: Marcin Kuczera: Difficult business client – VOIP and modem data transmission

  • 1. PLNOG 13, Kraków, 30 września 2014 ● o mnie ● dlaczego ten temat ? Trudny klient biznesowy – VoIP i modemy
  • 2. PLNOG 13, Kraków, 30 września 2014 ● terminale POS ● zarządzanie centralami ● urządzenia medyczne, raportowanie/serwisowanie ● a w SIWZ stoi wyraźnie – bez użycia technologii VoIP! WYGRYWAMY PRZETARG I CO TERAZ ??? Po czarta im modem ?
  • 3. PLNOG 13, Kraków, 30 września 2014 Przykładowe urządzenie medyczne
  • 4. PLNOG 13, Kraków, 30 września 2014 Jak działa klasyczna sieć PSTN/POTS ? ● analog <-> digital ● próbkowanie 8kHz – czyli max pasmo 0-4kHz Zgodnie z twierdzeniem Kotielnikowa-Shannona Przenoszenie kanałem E0 (timeslot) o przepustowości 64kbit/s ● ograniczenia na filtrach w SLIC 300 - 3400 Hz ● przesyłanie strumienia E0 End-To-End ● SYNCHRONIZACJA !
  • 5. PLNOG 13, Kraków, 30 września 2014 Jak działa klasyczna sieć PSTN/POTS ? ADC ADC PSTN SWITCH PSTN SWITCH PSTN E0 – 64k E0 – 64k 2MHz 300-3400Hz Analog 300-3400Hz Analog SLIC = ADC + A-Law + Filter + Ring + PowerSupply + CallerID + DTMF etc..
  • 6. PLNOG 13, Kraków, 30 września 2014 SoftSwitch – czyli dlaczego wymóg „nie VoIP” jest absurdalny ADC ADC IP E0 – 64k E0 – 64k 2MHz 300-3400Hz Analog 300-3400Hz Analog G.711/RTP Codec G.711/RTP Codec
  • 7. PLNOG 13, Kraków, 30 września 2014 V.29: A one-way (half-duplex) standard that is used mostly for fax machines. Capable of 9600 bit/s. V.32: A full-duplex standard capable of 9600 bit/s at 2400 baud. V.32 modems automatically adjust their transmission speeds based on the quality of the lines. V.32bis: A second version of V.32, it is capable of 14,400 bit/s. It will also fallback onto V.32 if the phone line is impaired. V.32ter: The third version of V.32, capable of 19,200 bit/s. V.34: Capable of 28,000 bit/s or fallback to 24,000 and 19,200 bit/s. This standard is backwards compatible with V.32 and V.32bis. V.34bis: Capable of 33,600 bit/s or fallback to 31,200 bit/s. V.90: The fastest transmissions standard available for analog transmission, it is capable of 56,000 bit/s. V.92: Transmits at the same speed as V.90 but offers a reduced handshake time and an on-hold feature. Kilka standardów modemowych
  • 8. PLNOG 13, Kraków, 30 września 2014 V.21 (300 b/s) for the T.30 procedures V.27ter (4800/2400 b/s) for image transfer V.29 (9600/7200 b/s) V.33 (14400/12000 b/s) V.17 (14400/12000/9600/7200 b/s) FAXy w PSTN/POTS ?
  • 9. PLNOG 13, Kraków, 30 września 2014 16 QAM Co się stanie jak zgubimy próbkę ?
  • 10. PLNOG 13, Kraków, 30 września 2014 O co chodzi z V.90 ? ADC E0 – 64k 300-3400Hz BandPass Filter Analog -> Digital No Filter Digital -> Analog DSP MODEM
  • 11. PLNOG 13, Kraków, 30 września 2014 E1 <-> SIP E1 <-> SIP IP 2MHz G.711/RTP Codec G.711/RTP Codec Dlaczego w VoIP mamy problem ? 2MHz PBX PSTN E1 E1
  • 12. PLNOG 13, Kraków, 30 września 2014 Czy to się da jakoś rozwiązać ? - Synchronizowac ! E1 <-> SIP E1 <-> SIP IP 2MHz G.711/RTP Codec G.711/RTP Codec PBX PSTN E1 E1
  • 13. PLNOG 13, Kraków, 30 września 2014 Jak synchronizować ? -Bramy VoIP synchronizujące swój zegar z centralą nadrzędną, zsynchronizowaną z siecią PSTN – poprzez protokół IP E1 <-> SIP E1 <-> SIP IP G.711/RTP Codec G.711/RTP Codec PBX PSTN E1 E1 Synchronizacja via IP Dziedziczenie zegara
  • 14. PLNOG 13, Kraków, 30 września 2014 Jak synchronizować ? -E1 w kierunku klienta przepuścić przez sieć SDH przez co brama również się zsynchronizuje do sieci SDH E1 <-> SIP E1 <-> SIP IP G.711/RTP Codec G.711/RTP Codec PBX PSTN E1 E1 Dziedziczenie zegara SDH PRC PRC – Primary Refecence Clock
  • 15. PLNOG 13, Kraków, 30 września 2014 Jak synchronizować ? -„pożyczyć” zegar np. z ISDN BRI E1 <-> SIP E1 <-> SIP IP G.711/RTP Codec G.711/RTP Codec PBX PSTN E1 E1 Dziedziczenie zegara ISDN 2B+D Tylko dla zegara !
  • 16. PLNOG 13, Kraków, 30 września 2014 Jakieś mądre protokoły ? -FAXy – T.38 -Modemy – V.150.1 (V.MOIP) E1 <-> SIP E1 <-> SIP IP G.711/RTP Codec G.711/RTP Codec PBX PSTN E1 E1 DSP AUDIO DATA
  • 17. PLNOG 13, Kraków, 30 września 2014 A co jak nie zsynchronizujemy ? -Obniżamy prędkość modemów (komendy AT ;) (ata, atdt202122, ath0, atdp202122) -Wyłączamy kompensacje echa -Uważamy na kompresję ciszy -Liczymy na to że w końcu dane/raport przejdą ;)
  • 18. PLNOG 13, Kraków, 30 września 2014 Przykład 1 E1 <-> SIP IP G.711 PBX PSTN E1 E1 E1 <-> SIP E1 <-> SIP E1 <-> SIP IP G.711 E1 Management Console via modem Management Terminal via modem Dziedziczenie zegara
  • 19. PLNOG 13, Kraków, 30 września 2014 Przykład 2 IP G.711 Bamka SIP-FXS PSTN E1 E1 <-> SIP Medical ECG reporting device Data collection via modem Dziedziczenie zegara
  • 20. PLNOG 13, Kraków, 30 września 2014 Pytania ?
  • 21. PLNOG 13, Kraków, 30 września 2014 W przypadku pytań: Marcin Kuczera E-mail: marcin.kuczera@leon.pl

Related Documents