რატომ რეგისტრირდება SIP ზარი VPN-ით, მაგრამ ხმას არ აგზავნის
რეგისტრაცია და ხმა სხვადასხვა გზას მიჰყვება. თვალი ადევნეთ ერთ ზარს გვირაბში, რომ ნახოთ, რომელი მისამართების გამოყენება შეუძლია PBX-ს და სად ჩერდება სინამდვილეში RTP.
წარმატებული რეგისტრაცია ხმის შესახებ თითქმის არაფერს ამბობს. პროგრამულ ტელეფონს შეუძლია საათობით შეინარჩუნოს მოქმედი კავშირი ოფისის PBX-თან და მაინც სიჩუმე გადასცეს. გვირაბი მხოლოდ იმ პაკეტებს ატარებს, რომლებსაც ვინმე განზრახ უგზავნის მასში, ხოლო ზარი იყენებს სამ ცალკე გზას: კავშირს, დიალოგის დაყენებას და RTP ნაკადს. როცა მათ გაყოფთ, ხარვეზი ერთ გზაზე მოდის და არა სიტყვა VPN-ზე.
წარმოიდგინეთ სახლის Wi-Fi-ზე მყოფი ლეპტოპი, რომელიც დამტკიცებული გვირაბით ოფისის შიდა ნომერს აკრეფს. PBX ამოწმებს მომხმარებელს, იღებს REGISTER-ს და შიდა ნომერი ხელმისაწვდომად ჩანს, მაგრამ ზარი ერთი მიმართულებით სრული სიჩუმით უკავშირდება.
რეგისტრაცია აკავშირებს კონტაქტს და არა მედიის გზას
REGISTER მოთხოვნა რეგისტრატორს სთხოვს შეინახოს შესაბამისობა ჩანაწერის მისამართსა და ერთ ან რამდენიმე კონტაქტურ URI-ს შორის. ეს შესაბამისობა პასუხობს ვიწრო კითხვას, სად უნდა გაიგზავნოს ახლა ახალი დიალოგი. ის არაფერს ამბობს იმაზე, სად ეკუთვნის მედია, და მიღებული რეგისტრაცია არ ამტკიცებს, რომ მოგვიანებით INVITE ატარებს მისაწვდომ მედიის მისამართს. რეგისტრაციები ტაიმერით იწურება, ამიტომ ტელეფონი, რომელიც განახლებას წყვეტს, შემავალ ზარებს კარგავს, სანამ მისი გვირაბი ჯერ კიდევ ჯანსაღად გამოიყურება. თვალი ადევნეთ კონტაქტის ვადის გასვლას და არა გვირაბის მდგომარეობას.
როცა პროგრამული ტელეფონი გვირაბის უკანაა, კონტაქტის სათაურს შეიძლება ჰქონდეს კერძო მისამართი. PBX, რომელიც მას სხვა ბოლო წერტილზე გადასცემს, ქმნის დიალოგს, რომელიც მიმართულია ქსელისკენ, სადაც დაძახებული ვერ მოხვდება. PJSIP ბოლო წერტილზე rewrite_contact=yes-ის დაყენება აიძულებს PBX-ს ჩაანაცვლოს დაკვირვებული წყაროს მისამართი, და ეს ხშირად განსხვავებაა ზარის ხმასა და დროის ამოწურვას შორის.
რას გვთავაზობს INVITE და ვის შეუძლია მისი გამოყენება
INVITE SDP სხეულით გვთავაზობს, სად სურს აბონენტს მედიის მიღება: მისამართი, პორტი და კოდეკების სია. დაძახებული პასუხობს თავისი მისამართითა და პორტით, შემდეგ კი თითოეული მხარე RTP-ს აგზავნის იმაზე, რაც მეორემ შესთავაზა. თუ აბონენტმა შესთავაზა 192.168.x.x ტიპის მისამართი, რომელიც მხოლოდ მის სახლის ქსელში არსებობს, დაძახებულს არ აქვს სად გააგზავნოს ხმა, რაც არ უნდა სუფთა იყოს სიგნალიზაცია. ნიღაბი გადაწერს IP სათაურებს, როცა პაკეტები გამომყოფს ტოვებს, მაგრამ არასოდეს გადაწერს ტექსტს SDP სხეულის შიგნით.
ეს უფსკრული ხსნის კლასიკურ ცალმხრივ ზარს: სიგნალიზაცია მუშაობს, რადგან ორივე ბოლო წერტილი აღწევს PBX-ს, ხოლო ხმა ვარდება, რადგან ერთ ბოლო წერტილს უთხრეს, გაეგზავნა იმ მისამართზე, რომელიც მხოლოდ სხვა NAT-ის უკან არსებობს.
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
ვინ ატარებს ხმას, კონფიგურაციის არჩევანია
სიგნალიზაცია და მედია ცალკე როლებია. პროქსის შეუძლია მთელი ზარის განმავლობაში დარჩეს სიგნალიზაციის გზაზე და არასოდეს შეეხოს არც ერთ RTP პაკეტს. გახდება თუ არა PBX მედიის რელე, დამოკიდებულია კონფიგურაციაზე და არა გვირაბის არსებობაზე.
პირდაპირი მედიის შემთხვევაში ბოლო წერტილები თავად ცვლიან RTP-ს, რაც კარგად მუშაობს ერთ LAN-ში და ცუდად მაშინ, როცა ერთი მხარე ვიწრო პორტების დიაპაზონის უკანაა.
direct_media=no-ის დაყენება PBX-ს მედიის გზაზე უბიძგებს, რომ ორივე ფეხი მის მიერ კონტროლირებულ მისამართზე დასრულდეს, გამტარუნარიანობისა და პროცესორის სანაცვლოდ წინასწარ განსაზღვრული მისამართვისთვის. როცა რელეს აკეთებს, PBX მაინც უნდა გამოაცხადოს მისაწვდომი მისამართი. მრავალქსელურ ჰოსტზე pjsip.conf-ში external_media_address და external_signaling_address განსაზღვრავენ, რა გამოჩნდება SDP-ში და Via სათაურებში. თუ დაუყენებელს დატოვებთ, PBX შეიძლება საკუთარი LAN მისამართი შესთავაზოს აბონენტს, რომლის ერთადერთი გზა გვირაბის შორეული მხარეა.
თვალი ადევნეთ თითოეულ მიმართულებას, სანამ პარამეტრებს შეეხებით
დაიწყეთ PBX-ის სოკეტების ცხრილით, სანამ ზარი აქტიურია: ss -uanp | grep -E '5060|10000' აჩვენებს, დაკავშირებულია თუ არა RTP პორტები და რომელ ლოკალურ მისამართს იყენებენ. თუ მედიის დიაპაზონში არაფერია დაკავშირებული, რელე არ მონაწილეობს და ბოლო წერტილები პირდაპირ საუბრობენ. შემდეგ ჩაიწერეთ პროგრამული ტელეფონის მხარეს tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap-ით. გამავალი პაკეტები შემომავალი პაკეტების გარეშე პრობლემას ავიწროებს დაბრუნების გზაზე ან იმ მისამართზე, რომლის გამოყენებაც შორეულ მხარეს უთხრეს, ხოლო ცარიელი ჩანაწერი ნიშნავს, რომ მედია გვირაბის ინტერფეისამდე საერთოდ არ მისულა. sngrep-ით სიგნალიზაციის ჩანაწერი პასუხობს მეორე ნახევარს და აჩვენებს SDP კავშირის ხაზს ისე, როგორც გაიგზავნა.
შეადარეთ ამ კავშირის ხაზში მოცემული მისამართი იმ მისამართს, სადაც შორეულ მხარეს ნამდვილად შეუძლია მარშრუტიზაცია. ეს ერთი შედარება ცალმხრივი ხმის უმეტეს შეტყობინებას უფრო სწრაფად წყვეტს, ვიდრე ნებისმიერი კონფიგურაციის მიმოხილვა.
დაშიფვრა გვირაბის კიდეზე ჩერდება
SIP TLS-ის თავზე იცავს იმ სიგნალიზაციის ნახტომს, რომლისთვისაც დაყენდა, SRTP იცავს მედიას, როცა ორივე მხარე შეთანხმდება, ხოლო გვირაბი იცავს ტრაფიკს მის საკუთარ ბოლო წერტილებს შორის. არც ერთი მათგანი არ აძლევს დანარჩენებს. გვირაბის შიგნით დაშიფრულ ზარს შეუძლია დატოვოს კარიბჭე ღია ტექსტით PBX-ისკენ, და ეს დიზაინის გადაწყვეტილებაა და არა ხარვეზი.
სანამ ბილეთს დახურავთ, რიგრიგობით დაადასტურეთ სამი რამ: რეგისტრაცია ახალია, SDP ატარებს მისამართს, რომელზეც შორეული მხარე მოხვდება, და პაკეტები ორივე მიმართულებით მიედინება მედიის პორტებზე. თუ რომელიმე მათგანი მცდარია, გვირაბი პრობლემის ადგილი არ არის. გაასწორეთ გზა, რომელიც ჩავარდა, შემდეგ კვლავ გაუშვით იგივე ჩანაწერი ცვლილების დასადასტურებლად. წინა და შემდგომი ჩანაწერების შენახვა შემდეგ ცალმხრივ შეტყობინებას მთელი შუადღის ნაცვლად ხუთწუთიან შემოწმებად აქცევს.