Teams Phone: Direct Routing, Operator Connect ve Calling Plan Seçimi

Teams Phone’a geçişte arıza genellikle istemcide değil, PSTN bağlantısında çıkar: SBC’nin sertifikası Microsoft tarafından reddedilir, dış arama yanlış rotaya düşer, acil çağrı hiç test edilmeden canlıya geçilir. Teams istemcisi kurumsal telefona kolayca dönüşür; kamu telefon şebekesine (PSTN) nasıl bağlanacağı ise ayrı bir mimari karardır. Bu karar kimin hangi bileşeni işleteceğini, numara taşımanın nasıl yapılacağını ve mevcut santralle geçiş döneminin ne kadar esnek kalacağını belirler. Aşağıda üç bağlantı modelini karşılaştırıyor, Direct Routing’in teknik gereksinimlerini ve sahadaki kontrol sırasını veriyoruz.

Teams Phone hangi parçalardan oluşur

Teams Phone tek bir ürün değil; birlikte çalışan beş parçadır. Birini eksik bırakırsanız çağrı kurulmaz:

• Teams Phone lisansı: Kullanıcıya çağrı denetimi, bekletme, aktarma, sesli posta ve PBX işlevlerini açar. Bazı Enterprise paketlerde dahildir, diğerlerinde eklenti olarak alınır. Kapsam dönem dönem değiştiği için Microsoft 365 lisans seçimi sırasında Teams Phone ihtiyacını ayrıca değerlendirin.
• PSTN bağlantısı: Calling Plan, Operator Connect veya Direct Routing.
• Numara: Kullanıcıya veya kaynak hesabına (resource account) atanan E.164 biçimli telefon numarası.
• Ses uygulamaları: Otomatik operatör (auto attendant) ve çağrı kuyruğu (call queue); kaynak hesaplarıyla çalışır.
• Cihazlar: Teams sertifikalı masa telefonları, konferans cihazları ve SBC arkasındaki analog uçlar.

PSTN bağlantı seçenekleri ve karşılaştırma

Calling Plan ve Operator Connect’in hangi ülkede, hangi operatörle sunulduğu değişkendir; karar vermeden önce Microsoft’un güncel ülke ve operatör listelerine bakın. Türkiye’deki projelerde yerel operatör SIP trunk’ı ile Direct Routing sık karşılaşılan seçenektir. Bunu kural olarak değil, operatör seçenekleri doğrulandıktan sonra verilen bir karar olarak ele alın.

Karar kriterleri

• Santral, kapı diyafonu, faks veya asansör hattı gibi analog uçlar uzun süre kalacaksa Direct Routing esneklik verir.
• Telefonu tamamen hizmet olarak almak ve SBC işletmemek istiyorsanız, ülkede hizmet veren bir Operator Connect operatörü varsa o tercih edilir.
• Şube sayısı fazlaysa ve WAN kesintisinde yerel arama sürmeliyse Direct Routing ile Survivable Branch Appliance (SBA) değerlendirilir.
• Modeller karma kullanılabilir: aynı tenant’ta bir ülkede Calling Plan, diğerinde Direct Routing çalışabilir.

Direct Routing mimarisi: SBC, SIP trunk ve sertifikalar

Direct Routing’de kurumun Session Border Controller’ı (SBC) bir bacağıyla operatörün SIP trunk’ına, diğer bacağıyla Microsoft’un SIP proxy’sine bağlanır. Bu iki bacak arasında ses, sinyal ve numara dönüşümü SBC’nin sorumluluğundadır; arızanın yarısı da burada aranır. Gereksinimler:

• Sertifikalı SBC: Microsoft’un Direct Routing için onayladığı listeden bir donanım veya sanal SBC kullanılmalıdır.
• FQDN ve alan adı: SBC’nin FQDN’i (örneğin sbc1.ornek.com.tr) tenant’ta doğrulanmış bir alan adına ait olmalı; *.onmicrosoft.com kullanılamaz. Microsoft dokümanına göre alan adının etkinleşmesi için bu alan adında lisanslı en az bir kullanıcı bulunmalıdır.
• Genel sertifika: SBC’nin FQDN’ini içeren, Microsoft’un güvendiği bir kök CA’dan alınmış sertifika.
• Genel IP: SBC’ye doğrudan veya 1:1 NAT ile genel bir IP adresi.
• Sinyalleşme: SIP over TLS; Microsoft tarafı sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com ve sip3.pstnhub.microsoft.com adreslerinde 5061 portunu kullanır.
• Medya: SRTP. Microsoft medya işlemcileri tarafında UDP 3478–3481 ve 49152–53247 portları; SBC tarafındaki medya port aralığı SBC’de tanımlanır ve güvenlik duvarında buna göre açılır.

Güvenlik duvarı kurallarını Microsoft’un yayımladığı güncel IP aralıkları ve portlara göre yazın; aralıklar değişebilir. SBC yönetim merkezinde “bağlı değil” görünüyorsa konsolda ilk bakılacak yer TLS el sıkışmasıdır: sertifika zinciri eksik mi, FQDN sertifikadaki adla aynı mı, 5061 dışarıdan gerçekten açık mı. Sertifika zinciri eksikse SBC bağlanmaz.

Medya atlatma (media bypass) açıldığında, kurum içindeki Teams istemcisi ile SBC arasındaki medya doğrudan akar ve Microsoft’un medya işlemcileri devreye girmez. Gecikme azalır; ama istemcilerin SBC’nin medya portlarına erişebilmesi gerekir. İç ağdaki ACL bunu unutursa çağrı kurulur, ses gelmez.

Yapılandırma örneği

SBC tarafındaki ayarlar üreticiye özeldir (AudioCodes, Ribbon gibi üreticiler Teams için yapılandırma kılavuzları yayımlar). Teams tarafı MicrosoftTeams PowerShell modülüyle yapılır:

Connect-MicrosoftTeams

# SBC'yi tenant'a ekleme
New-CsOnlinePSTNGateway -Fqdn sbc1.ornek.com.tr -SipSignalingPort 5061 `
  -MaxConcurrentSessions 60 -Enabled $true

# PSTN kullanımı, rota ve ses yönlendirme ilkesi
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="TR-Tum"}
New-CsOnlineVoiceRoute -Identity "TR-Rota" -NumberPattern "^\+90\d{10}$" `
  -OnlinePstnGatewayList sbc1.ornek.com.tr -Priority 1 -OnlinePstnUsages "TR-Tum"
New-CsOnlineVoiceRoutingPolicy -Identity "TR-Politika" -OnlinePstnUsages "TR-Tum"

# Kullanıcıya numara ve ilke atama
Set-CsPhoneNumberAssignment -Identity ayse@ornek.com.tr `
  -PhoneNumber "+902125550101" -PhoneNumberType DirectRouting
Grant-CsOnlineVoiceRoutingPolicy -Identity ayse@ornek.com.tr -PolicyName "TR-Politika"

Bu örnekteki rota deseni yalnız +90 ile başlayan on haneli numaraları kapsar. Uluslararası aramalar ve acil numaralar için ayrı rotalar ve ayrı PSTN kullanımları tanımlamak, kimin nereyi arayabileceğini ilke düzeyinde kısıtlamayı mümkün kılar. Kullanıcıların kısa numara alışkanlıkları (dış hat için 0 çevirme gibi) için Teams’te arama planı (tenant dial plan) normalleştirme kuralları yazılır. Normalleştirme yanlışsa çağrı hiçbir rotaya uymaz ve kullanıcı yalnızca “arama başarısız” görür.

Mevcut santralle geçiş dönemi

Mevcut sistem altyapısı ve santral düzeni içinde tüm kullanıcıları tek gecede taşımak nadiren mümkündür. Sahada işleyen yöntem SBC’yi operatör ile santral arasına yerleştirmektir:

1. Operatör trunk’ı SBC’ye bağlanır; santral SBC’nin arkasına SIP trunk ile bağlanır.
2. SBC, gelen çağrıyı aranan numaraya göre Teams’e veya santrale yönlendirir. Taşınan kullanıcının numarası SBC yönlendirme tablosunda Teams tarafına alınır.
3. Santral dahilileri ile Teams kullanıcıları arasındaki çağrılar da SBC üzerinden akar; kısa dahili numarayla aramayı sürdürmek için arama planında normalleştirme kuralı tanımlanır.
4. Kullanıcılar departman gruplarıyla taşınır; çağrı merkezi, resepsiyon ve analog uçlar en son, ayrı test planıyla geçer.

Operator Connect veya Calling Plan seçildiğinde numaraların yeni operatöre ya da Microsoft’a taşınması (porting) gerekir. Süreç operatöre ve yerel düzenlemeye bağlıdır; kısmi taşımanın mümkün olup olmadığını operatörle önceden netleştirin. Blok tek seferde taşınacaksa o bloktaki tüm kullanıcıların Teams tarafı taşıma tarihinden önce hazır olmalı. Yarım hazırlanmış blok, yarım çalışan santral demektir.

Otomatik operatör, çağrı kuyruğu ve numara planı

Santraldeki karşılama menüsü ve grup çağrıları Teams’te otomatik operatör ve çağrı kuyruğuyla yeniden kurulur. Her biri bir kaynak hesabı kullanır; kaynak hesabına ücretsiz “Teams Phone Resource Account” lisansı atanır ve dış numara gerekiyorsa numara bu hesaba verilir.

• Otomatik operatör: Mesai içi ve dışı menüler, tatil takvimleri, dahili ile arama ve ses tanıma seçenekleri.
• Çağrı kuyruğu: Temsilcileri bir Teams ekibinden veya gruptan alır; dağıtım yöntemi (tüm temsilcileri aynı anda çaldıran attendant routing, sıralı, round robin, en uzun boşta kalan), taşma ve zaman aşımı hedefleri tanımlanır.
• Numara planı: Santraldeki dahili numaraları DID numaralarıyla eşleyen bir tablo hazırlayın. Teams’te her kullanıcı tam E.164 numarayla tanımlanır; DID olmayan dahililer için uzantı (;ext=) kullanılabilir.

Santral menülerinin hiç belgelenmemiş olması sahada en sık gördüğümüz eksiktir. Geçişten önce mevcut çağrı akışlarını test aramalarıyla tek tek çıkarın; Teams tarafında eksik dal kalmaz, “mesai dışında arayan nereye düşüyordu” sorusu canlıda sorulmaz.

Ağ hazırlığı ve ses kalitesi doğrulama

Teams sesi gerçek zamanlıdır; bant genişliğinden çok gecikme, titreşim ve paket kaybı belirler. Microsoft’un ağ hazırlık dokümanı, istemciden Microsoft ağ kenarına kadar tek yön gecikmenin 50 ms, gidiş-dönüş gecikmenin 100 ms ve titreşimin 30 ms altında kalmasını hedefler. Değerleri proje başında güncel dokümandan doğrulayın.

• Yerel internet çıkışı: Teams medyasını merkezi bir proxy veya VPN tüneli üzerinden taşımak gecikmeyi artırır. Microsoft 365 “Optimize” kategorisindeki uç noktalar için doğrudan çıkış ve VPN split tunneling önerilir.
• QoS: Microsoft’un önerdiği port aralıkları ve DSCP değerleri sesi UDP 50000–50019 ile EF (46), videoyu 50020–50039 ile AF41 (34), ekran paylaşımını 50040–50059 ile AF21 (18) olarak işaretlemektir. İşaretleme Windows’ta Group Policy QoS ilkeleriyle yapılır; işaretin anahtar ve WAN boyunca korunması ağ tarafının işidir. Kampüs ağındaki kuyruk tasarımını kurumsal LAN’da QoS rehberi ele alır.
• Ölçüm: Microsoft Teams Network Assessment Tool, şube ağlarından Microsoft’a medya kalitesini ve bağlantıyı test eder; NetworkAssessmentTool.exe /connectivitycheck gerekli uç noktalara erişimi doğrular.
• İzleme: Canlıya geçtikten sonra Call Quality Dashboard’a alt ağ ve bina bilgilerini yükleyin; kalitesiz çağrılar konuma göre gruplanır.

İstemcide işaretlenen paket, yolda bir anahtarın güvenmediği (untrusted) portundan geçerken sıfırlanır. İşaret yolda kaybolursa QoS yoktur.

Geçiş kontrol listesi

• PSTN modeli ülke ve operatör bulunabilirliğiyle doğrulanmış.
• Kullanıcı ve kaynak hesapları için lisanslar atanmış.
• SBC sertifikası, FQDN, genel IP ve güvenlik duvarı kuralları hazır; SBC Teams yönetim merkezinde etkin ve TLS bağlantısı “aktif” görünüyor.
• Numara envanteri, DID eşlemesi ve taşıma tarihi operatörle kesinleşmiş.
• Arama planı normalleştirme kuralları, ses yönlendirme ilkeleri ve uluslararası arama kısıtlamaları test edilmiş.
• Acil çağrı yönlendirmesi test aramasıyla doğrulanmış.
• Otomatik operatör ve çağrı kuyruğu akışları mesai içi, mesai dışı ve tatil senaryolarıyla denenmiş.
• Şubelerde ağ değerlendirmesi yapılmış, QoS işaretleri doğrulanmış.
• Pilot grup en az bir iş haftası kullanmış ve geri bildirim alınmış.

Teams Phone geçişinin bulut tarafı Microsoft 365 operasyonuyla, ağ tarafı altyapı tasarımıyla iç içedir. İkisini birlikte planlamak için Microsoft 365 ve bulut hizmetleri ile altyapı danışmanlığı sayfalarımıza bakabilirsiniz. Microsoft 365 servislerinin kesintiye karşı nasıl planlanacağını Microsoft 365 ve bulut altyapısında süreklilik yazısında ele aldık. Direct Routing gereksinimlerinin güncel hali için Microsoft’un Plan Direct Routing dokümanı esas alınmalıdır.

Sık sorulan sorular

Teams Phone için mutlaka SBC almak gerekir mi?

Hayır. Calling Plan veya Operator Connect kullanıldığında SBC’yi Microsoft ya da operatör işletir. Kendi SBC’nize yalnız Direct Routing seçildiğinde, analog cihaz entegrasyonu gerektiğinde veya santralle uzun süreli birlikte çalışma planlandığında ihtiyaç duyulur.

Direct Routing için hangi sertifika kullanılmalı?

SBC’nin FQDN’ini içeren, Microsoft’un güvendiği bir kök sertifika otoritesinden alınmış genel (public) bir sertifika gerekir. İç CA’dan üretilmiş sertifikayı Microsoft SIP proxy’si kabul etmez. FQDN’in alan adı tenant’ta doğrulanmış olmalıdır.

Mevcut santral ile Teams Phone aynı anda çalışabilir mi?

Evet. SBC hem operatör hattına hem santrale bağlanır ve numara aralıklarına göre çağrıyı Teams’e veya santrale yönlendirir. Kullanıcılar gruplar halinde taşınır; analog cihazlar ve çağrı merkezi kendi takvimiyle geçer.

Ses kalitesi sorunlarında ilk nereye bakılmalı?

Teams yönetim merkezindeki kullanıcı bazlı çağrı analizi ve Call Quality Dashboard ilk adımdır. Ardından istemcinin ağı, kablosuz bağlantı, VPN üzerinden akan medya ve QoS işaretlerinin yol boyunca korunup korunmadığı kontrol edilir.