Routing bezpośredni usług Azure Communication Services: szczegóły protokołu SIP
W tym artykule opisano, jak routing bezpośredni implementuje protokół inicjowania sesji (SIP), aby zapewnić prawidłowe trasy ruchu między kontrolerem granicznym sesji (SBC) i serwerem proxy SIP. Podkreśla również znaczenie niektórych parametrów SIP, które wymagają określonych wartości. Ten artykuł jest przeznaczony dla administratorów głosowych, którzy są odpowiedzialni za konfigurowanie połączenia między SBC i usługą serwera proxy SIP.
Przetwarzanie żądania przychodzącego: znajdowanie zasobu usług komunikacyjnych
Uwaga
W usłudze Azure Communication Services opcje routingu bezpośredniego SIP są domyślnie włączone i nie można ich wyłączyć. Protokół SBC musi najpierw zainicjować wymianę OPTIONS, ponieważ serwer proxy SIP czeka na uruchomienie wymiany przez SBC.
Przed przetworzeniem połączenia przychodzącego lub wychodzącego komunikaty OPTIONS są wymieniane między serwerem proxy SIP a SBC. Te komunikaty OPTIONS umożliwiają serwerowi proxy SIP zapewnienie dozwolonych funkcji SBC. Ważne jest, aby negocjacje OPTIONS zakończyły się powodzeniem (200 OK odpowiedzi), co pozwala na dalszą komunikację między serwerem proxy SBC i SIP w celu nawiązania połączeń. Nagłówki SIP w komunikatach OPTIONS do serwera proxy SIP są udostępniane jako przykład:
| Nazwa parametru | Przykład wartości |
|---|---|
| Identyfikator URI żądania | OPCJE sip:sip.pstnhub.microsoft.com:5061 SIP /2.0 |
| Za pośrednictwem nagłówka | Za pośrednictwem: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978 |
| Nagłówek Max-Forwards | Max-Forwards:68 |
| Z nagłówka | Z nagłówka od: sip:sbc1.contoso.com:5061 |
| Do nagłówka | Do: sip:sip.pstnhub.microsoft.com:5061 |
| Nagłówek CSeq | CSeq: 1 ZAPROSZENIE |
| Nagłówek kontaktu | Kontakt: sip:sbc1.contoso.com:5061; transport=tls |
Uwaga
Nagłówki SIP nie zawierają informacji o użytkowniku w używanym identyfikatorze URI SIP. Zgodnie z RFC 3261, sekcja 19.1.1, część userinfo identyfikatora URI jest opcjonalna i może być nieobecna, gdy host docelowy nie ma pojęcia użytkowników lub gdy sam host jest identyfikowany zasób. Jeśli znak @ jest obecny w identyfikatorze URI SIP, pole użytkownika nie może być puste. Należy pamiętać, że identyfikator URI SIPS nie powinien być używany z routingiem bezpośrednim, ponieważ nie jest obsługiwany. Sprawdź konfigurację kontrolera obramowania sesji i upewnij się, że nie używasz nagłówków "Replaces" w żądaniach SIP. Routing bezpośredni odrzuci żądania SIP, które mają zdefiniowane nagłówki Replaces.
Podczas połączenia przychodzącego serwer proxy SIP musi znaleźć zasób usługi Azure Communication, do którego jest kierowane wywołanie. W tej sekcji opisano, jak serwer proxy SIP znajduje zasób i wykonuje uwierzytelnianie SBC na połączeniu przychodzącym.
Przykład komunikatu SIP Invite na wywołaniu przychodzącym:
| Nazwa parametru | Przykład wartości |
|---|---|
| Identyfikator URI żądania | ZAPROŚ sip:+54321@sip.pstnhub.microsoft.com SIP /2.0 |
| Za pośrednictwem nagłówka | Za pośrednictwem: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978 |
| Nagłówek Max-Forwards | Max-Forwards:68 |
| Z nagłówka | Od nagłówka od: <sip:+12345@sbc1.contoso.com; transport=udp; tag=1c68821811 |
| Do nagłówka | Do: sip:+54321@sbc1.contoso.com |
| Nagłówek CSeq | CSeq: 1 ZAPROSZENIE |
| Nagłówek kontaktu | Kontakt: sip:+12345@sbc1.contoso.com:5061; transport=tls |
Po otrzymaniu zaproszenia serwer proxy SIP wykonuje następujące kroki:
Sprawdź certyfikat. Na początkowym połączeniu usługa routingu bezpośredniego przyjmuje nazwę FQDN przedstawioną w nagłówku Kontakt i dopasuje ją do nazwy pospolitej lub alternatywnej nazwy podmiotu przedstawionego certyfikatu. Nazwa SBC musi być zgodna z jedną z następujących opcji:
Sposób 1. Pełna nazwa FQDN przedstawiona w nagłówku Kontakt musi być zgodna z alternatywną nazwą pospolitą/alternatywną nazwą podmiotu przedstawionego certyfikatu.
Sposób 2. Część domeny nazwy FQDN przedstawionej w nagłówku Kontakt (na przykład contoso.com nazwy FQDN sbc1.contoso.com) musi być zgodna z wartością wieloznacznymi w polu Nazwa pospolita/Alternatywna nazwa podmiotu (na przykład *.contoso.com).
Spróbuj znaleźć dzierżawę platformy Microsoft 365 przy użyciu pełnej nazwy FQDN przedstawionej w nagłówku Kontakt.
Sprawdź, czy nazwa FQDN z nagłówka Kontakt (sbc1.contoso.com) jest zarejestrowana jako nazwa DNS w dowolnej organizacji usługi Microsoft 365 lub Office 365. Jeśli zostanie znaleziona, wyszukiwanie użytkownika jest wykonywane w dzierżawie, która ma nazwę FQDN SBC zarejestrowaną jako nazwa domeny. Jeśli nie znaleziono, krok 3 ma zastosowanie.
Spróbuj znaleźć zasób usługi Azure Communication przy użyciu pełnej nazwy FQDN przedstawionej w nagłówku Kontakt.
Sprawdź, czy nazwa FQDN z nagłówka Kontakt (sbc1.contoso.com) jest zarejestrowana jako nazwa FQDN SBC w dowolnym zasobie usługi Azure Communication. W przypadku znalezienia wywołanie jest wysyłane do tego zasobu. Jeśli nie zostanie znaleziony, zostanie zastosowany krok 4.
Krok 4 ma zastosowanie tylko wtedy, gdy kroki 2 i 3 nie powiodły się.
Usuń część hosta z nazwy FQDN przedstawionej w nagłówku Kontakt (nazwa FQDN: sbc1.contoso.com, po usunięciu części hosta: contoso.com) i sprawdź, czy ta nazwa jest zarejestrowana jako nazwa DNS w dowolnej organizacji platformy Microsoft 365 lub Office 365. Jeśli zostanie znaleziona, wyszukiwanie użytkownika jest wykonywane w tej dzierżawie. Jeśli nie zostanie znaleziona, wywołanie zakończy się niepowodzeniem.
Krok 5 ma zastosowanie tylko wtedy, gdy kroki 2, 3 i 4 zakończyły się niepowodzeniem.
Usuń część hosta z nazwy FQDN przedstawionej w nagłówku Kontakt (nazwa FQDN: sbc1.contoso.com, po usunięciu części hosta: contoso.com) i sprawdź, czy ta nazwa jest zarejestrowana jako nazwa FQDN SBC w dowolnym zasobie usługi Azure Communication. W przypadku znalezienia wywołanie jest wysyłane do tego zasobu. Jeśli nie zostanie znaleziona, wywołanie zakończy się niepowodzeniem.
Jeśli zasób ma skojarzone wdrożenie dynamics Omnichannel, wykonaj wyszukiwanie numeru telefonu przedstawionego w identyfikatorze Request-URI. Dopasuj przedstawiony numer telefonu do użytkownika Omnichannel (kolejki) znalezionego w poprzednim kroku.
Krok 7 ma zastosowanie tylko wtedy, gdy kroki 6 nie powiodły się.
Jeśli dla zasobu komunikacji nie istnieje żadne wdrożenie wielokanałowe lub numer w identyfikatorze Request-URI nie jest zgodny z żadnym skonfigurowanym numerem omnichannel, wyślij wywołanie do usługi Event Grid.
Krok 8 ma zastosowanie tylko wtedy, gdy kroki 7 nie powiodły się.
Jeśli usługa Event Grid nie jest skonfigurowana lub nie ma reguł zarządzania wywołaniem przychodzącym, wywołanie zostanie porzucone.
Szczegółowe wymagania dotyczące nagłówka kontaktów i identyfikatora URI żądania
Nagłówek kontaktu
W przypadku wszystkich przychodzących komunikatów SIP (OPTIONS, INVITE) do serwera proxy MICROSOFT SIP nagłówek Kontakt musi mieć sparowaną nazwę FQDN SBC w nazwie hosta identyfikatora URI w następujący sposób:
Składnia: Kontakt: <sip:phone lub sip address@FQDN SBC; transport=tls>
Zgodnie z RFC 3261, sekcja 11.1, pole nagłówka Kontakt może być obecne w komunikacie OPTIONS. W routingu bezpośrednim wymagany jest nagłówek kontaktu. Jeśli chodzi o komunikaty OPTIONS, informacje o użytkowniku można wykluczyć z identyfikatora URI SIP i można wysłać tylko nazwę FQDN w następującym formacie:
Składnia: Kontakt: <sip:FQDN SBC; transport=tls>
Ta nazwa (FQDN) musi również znajdować się w polach Nazwa pospolita lub Alternatywna nazwa podmiotu przedstawionego certyfikatu. Firma Microsoft obsługuje używanie symboli wieloznacznych nazw w polach Nazwa pospolita lub Alternatywna nazwa podmiotu certyfikatu. Obsługa symboli wieloznacznych została opisana w artykule RFC 2818, sekcja 3.1. Szczególnie:
"Nazwy mogą zawierać symbol wieloznaczny *, który jest uważany za zgodny z dowolnym składnikiem lub fragmentem pojedynczej nazwy domeny. Na przykład *.a.com pasuje do foo.a.com, ale nie bar.foo.a.com. f*.com pasuje foo.com, ale nie bar.com.
Jeśli więcej niż jedna wartość w nagłówku Kontakt przedstawiony w komunikacie SIP przez SBC, używana jest tylko część FQDN pierwszej wartości nagłówka Kontakt. Jako reguła kciuka dla routingu bezpośredniego ważne jest, aby nazwa FQDN była używana do wypełniania identyfikatora URI SIP zamiast adresu IP. Przychodzący komunikat INVITE lub OPTIONS do serwera proxy SIP z nagłówkiem Kontakt, gdzie nazwa hosta jest reprezentowana przez adres IP, a nie FQDN, połączenie jest odrzucane z 403 Zabronione.
Identyfikator URI żądania
W przypadku wszystkich wywołań przychodzących identyfikator URI żądania służy do identyfikowania wywołania. Obecnie numer telefonu musi zawierać znak plus (+), jak pokazano w poniższym przykładzie.
INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0
Z nagłówka
W przypadku wszystkich połączeń przychodzących nagłówek od jest używany do dopasowania numeru telefonu obiektu wywołującego.
Numer telefonu musi zawierać cyfrę +, jak pokazano w poniższym przykładzie.
From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811
Zagadnienia dotyczące nagłówków kontaktów i tras rekordów
Serwer proxy SIP musi obliczyć nazwę FQDN następnego przeskoku dla nowych transakcji klienta w oknie dialogowym (na przykład Bye lub Re-Invite) oraz podczas odpowiadania na OPCJE SIP. Można to zrobić przy użyciu połączenia lub trasy rekordu. Zgodnie z RFC 3261, sekcja 8.1.1.8, nagłówek Kontakt jest wymagany w każdym żądaniu, które może spowodować nowe okno dialogowe. Trasa rekordu jest wymagana tylko wtedy, gdy serwer proxy chce pozostać na ścieżce przyszłych żądań w oknie dialogowym.
Aby obliczyć następny przeskok, serwer proxy SIP używa:
Priorytet 1. Trasa rekordu najwyższego poziomu. Jeśli trasa rekordu najwyższego poziomu zawiera nazwę FQDN, nazwa FQDN jest używana do nawiązywania połączenia wychodzącego w oknie dialogowym.
Priorytet 2. Nagłówek kontaktu. Jeśli usługa Record-Route nie istnieje, serwer proxy SIP wyszukuje wartość nagłówka Contact, aby nawiązać połączenie wychodzące. (Zalecana konfiguracja).
Jeśli są używane zarówno połączenia, jak i trasa rekordu, administrator SBC musi zachować ich wartości identyczne, co powoduje obciążenie administracyjne.
Używanie nazwy FQDN w obszarze Kontakt lub Trasa rekordu
Użycie adresu IP nie jest obsługiwane w usłudze Record-Route lub Contact. Jedyną obsługiwaną opcją jest nazwa FQDN, która musi być zgodna z alternatywną nazwą pospolitą lub alternatywną nazwą podmiotu certyfikatu SBC (obsługiwane są wartości wieloznaczne w certyfikacie).
Jeśli w polu Rekord-route lub Contact zostanie wyświetlony adres IP, sprawdzanie certyfikatu zakończy się niepowodzeniem i wywołanie zakończy się niepowodzeniem.
Jeśli nazwa FQDN nie jest zgodna z wartością wspólnej lub alternatywnej nazwy podmiotu w przedstawionym certyfikacie, wywołanie nie powiedzie się.
Nagłówki kontekstu wywołania
Nagłówki kontekstu wywołań są obecnie dostępne tylko dla zestawu Call Automation SDK. Zestaw SDK usługi Call Automation obsługuje nagłówek User-To-User i maksymalnie pięć niestandardowych nagłówków SIP. Te nagłówki są obsługiwane w metodach INVITE i REFER.
Nagłówek użytkownik-użytkownik
Nagłówek SIP User-To-User (UUI) jest standardem branżowym umożliwiającym przekazywanie informacji kontekstowych podczas procesu konfiguracji wywołania. Maksymalna długość klucza nagłówka interfejsu użytkownika to 64 znaki. Maksymalna długość wartości nagłówka interfejsu użytkownika to 256 znaków. Wartość nagłówka interfejsu użytkownika może składać się z znaków alfanumerycznych i kilku wybranych symboli, w tym =, !*;+.-%_~.
Nagłówek niestandardowy
Usługi Azure Communication Services obsługują również maksymalnie pięć niestandardowych nagłówków SIP. Niestandardowy klucz nagłówka SIP musi zaczynać się od obowiązkowego X-MS-Custom- prefiksu. Maksymalna długość klucza nagłówka SIP wynosi 64 znaki, w tym X-MS-Custom- prefiks. Klucz nagłówka SIP może składać się z znaków alfanumerycznych i kilku wybranych symboli, w tym ., , !, +*%_~. - Maksymalna długość wartości nagłówka SIP wynosi 256 znaków. Wartość nagłówka SIP może składać się z znaków alfanumerycznych i kilku wybranych symboli, w tym =, !+. -~;.%*_
Aby uzyskać szczegółowe informacje o implementacji, zobacz Jak przekazywać dane kontekstowe między wywołaniami.
Wywołanie przychodzące: opis okna dialogowego SIP
Poniżej przedstawiono szczegółowe informacje na temat przetwarzania wywołań przychodzących przez serwer proxy SIP.
| Nazwa parametru | Wartość |
|---|---|
| Kandydaci do mediów w 183 i 200 wiadomości pochodzących z | Procesory multimediów |
| Liczba 183 komunikatów SBC może odbierać | Jeden na sesję |
| Połączenie może być z tymczasową odpowiedzią (183) | Tak |
| Połączenie może być bez tymczasowej odpowiedzi (183) | Tak |
Tożsamość usług Azure Communication Services może być używana w wielu punktach końcowych (aplikacjach) jednocześnie. Na przykład aplikacja internetowa, aplikacja i Telefon i aplikacja dla systemu Android. Każdy punkt końcowy może sygnalizać resztę HTTP w następujący sposób:
Postęp wywołania — przekonwertowany przez serwer proxy SIP na komunikat SIP 180. Po otrzymaniu komunikatu 180 SBC musi wygenerować lokalne dzwonienie.
Odpowiedź mediana — przekonwertowana przez serwer proxy SIP na komunikat 183 z kandydatami do multimediów w protokole SDP (Session Description Protocol). Po otrzymaniu komunikatu 183 SBC oczekuje połączenia z kandydatami do mediów odebranych w wiadomości SDP.
Uwaga
W niektórych przypadkach odpowiedź mediana może nie zostać wygenerowana, a punkt końcowy może odpowiedzieć z komunikatem "Call Accepted" (Zaakceptowane połączenie).
Zaakceptowane wywołanie — przekonwertowane przez serwer proxy SIP na komunikat SIP 200 za pomocą protokołu SDP. Po otrzymaniu wiadomości 200 oczekuje się, że SBC będzie wysyłać i odbierać nośniki do i od dostarczonych kandydatów SDP.
Uwaga
Routing bezpośredni nie obsługuje opóźnionego zapraszania ofert (zaproś bez protokołu SDP).
Wiele punktów końcowych dzwoni z tymczasową odpowiedzią
Po otrzymaniu pierwszego zaproszenia od SBC serwer proxy SIP wysyła komunikat "SIP SIP/2.0 100 Trying" i powiadamia wszystkie punkty końcowe użytkownika końcowego o wywołaniu przychodzącym.
Po powiadomieniu każdy punkt końcowy rozpoczyna dzwonienie i wysyła komunikaty "Postęp wywołania" do serwera proxy SIP. Ponieważ tożsamość usług Azure Communication Services jest używana przez wiele punktów końcowych, serwer proxy SIP może odbierać wiele komunikatów postępu wywołań.
Dla każdego komunikatu o postępie wywołania odebranego z punktów końcowych serwer proxy SIP konwertuje komunikat Postępu wywołań na komunikat SIP "SIP/2.0 180 Dzwonienie". Interwał wysyłania takich komunikatów jest skorelowany z interwałem odbierania komunikatów z kontrolera wywołań. Na poniższym diagramie istnieją dwa 180 komunikatów generowanych przez serwer proxy SIP. Te komunikaty pochodzą z dwóch punktów końcowych zestawu SDK. Punkty końcowe mają unikatowy identyfikator tagu. Każdy komunikat pochodzący z innego punktu końcowego jest oddzielną sesją (parametr "tag" w polu "Do" jest inny). Jednak punkt końcowy może nie wygenerować komunikatu 180 i wysłać komunikat 183 od razu, jak pokazano na poniższym diagramie.
Gdy punkt końcowy wygeneruje komunikat Media Answer z adresami IP kandydatów nośnika punktu końcowego, serwer proxy SIP konwertuje komunikat odebrany na komunikat "SIP 183 Session Progress" z protokołem SDP z punktu końcowego zastąpionym przez protokół SDP z procesora multimediów. Na poniższym diagramie punkt końcowy z rozwidlenia 2 odebrał połączenie. Komunikat SIP 183 jest generowany tylko raz. 183 może pojawić się na istniejącym rozwidleniu lub rozpocząć nowy.
Komunikat akceptacji wywołań jest wysyłany do serwera proxy SIP z ostatnimi kandydatami punktu końcowego, który zaakceptował wywołanie. Komunikat akceptacji połączenia jest konwertowany na komunikat SIP 200.
Wiele punktów końcowych dzwoni bez tymczasowej odpowiedzi
Po otrzymaniu pierwszego zaproszenia od SBC serwer proxy SIP wysyła komunikat "SIP SIP/2.0 100 Trying" i powiadamia wszystkie punkty końcowe użytkownika końcowego o wywołaniu przychodzącym.
Po powiadomieniu każdy punkt końcowy rozpoczyna dzwonienie i wysyła komunikat "Postęp wywołania" do serwera proxy SIP. Ponieważ ta sama tożsamość usług Azure Communication Services może być używana w wielu aplikacjach, serwer proxy SIP może odbierać wiele komunikatów postępu wywołań.
Dla każdego komunikatu o postępie wywołania odebranego z punktów końcowych serwer proxy SIP konwertuje komunikat Postępu wywołań na komunikat SIP "SIP/2.0 180 Dzwonienie". Interwał wysyłania komunikatów jest skorelowany z interwałem odbierania komunikatów z kontrolera wywołań. Na obrazie istnieją dwa 180 komunikatów generowanych przez serwer proxy SIP, co oznacza, że wywołanie jest rozwidlenie do dwóch różnych klientów, a każdy klient wysyła postęp wywołania. Każdy komunikat jest oddzielną sesją (parametr "tag" w polu "Do" jest inny)
Komunikat akceptacji wywołań jest wysyłany do serwera proxy SIP z ostatnimi kandydatami punktu końcowego, który zaakceptował wywołanie. Komunikat akceptacji połączenia jest konwertowany na komunikat SIP 200.
Zamienia opcję
Protokół SBC musi obsługiwać element INVITE z funkcjami Replaces.
Rozmiar zagadnień dotyczących protokołu SDP
Interfejs routingu bezpośredniego może wysyłać komunikat SIP przekraczający 1500 bajtów. Rozmiar protokołu SDP powoduje przede wszystkim takie zachowanie. Jeśli jednak istnieje magistrala UDP za SBC, może odrzucić komunikat, jeśli jest przekazywany z serwera proxy SIP firmy Microsoft do magistrali niezmodyfikowanej. Firma Microsoft zaleca usunięcie niektórych wartości z protokołu SDP na SBC podczas wysyłania komunikatu do magistrali UDP. Na przykład można usunąć kandydatów ICE lub nieużywanych koderów.
Transfer połączeń
Routing bezpośredni obsługuje dwie metody transferu wywołań:
Sposób 1. Procesy serwera proxy SIP odwołują się lokalnie do klienta i działają jako referee zgodnie z opisem w sekcji 7.1 RFC 3892.
Dzięki tej opcji serwer proxy SIP kończy transfer i dodaje nowe zaproszenie.
Sposób 2. Serwer proxy SIP wysyła odwołanie do SBC i działa jako transferor, zgodnie z opisem w sekcji 6 RFC 5589.
Dzięki tej opcji serwer proxy SIP wysyła odwołanie do SBC i oczekuje, że SBC będzie w pełni obsługiwać transfer.
Serwer proxy SIP wybiera metodę na podstawie możliwości zgłoszonych przez SBC. Jeśli SBC wskazuje, że obsługuje metodę "Refer", serwer proxy SIP używa opcji 2 do transferów wywołań. Przykład SBC wysyłający komunikat, że obsługiwana jest metoda Refer:
ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Jeśli protokół SBC nie wskazuje, że opcja Odwołaj się jako obsługiwana metoda, routing bezpośredni używa opcji 1 (serwer proxy SIP działa jako sędzia). SBC musi również zasygnalizować, że obsługuje metodę Notify: Przykład SBC wskazujący, że metoda Refer nie jest obsługiwana:
ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS
Procesy serwera proxy SIP odwołują się lokalnie do klienta i działają jako sędzia
Jeśli SBC wskazał, że metoda Refer nie jest obsługiwana, serwer proxy SIP działa jako sędzia. Żądanie odwołania pochodzące z klienta kończy się na serwerze proxy SIP. Żądanie odwołania od klienta jest wyświetlane jako "Połączenie przeniesienia do Dave" na poniższym diagramie. Aby uzyskać więcej informacji, zobacz sekcję 7.1 RFC 3892.
Serwer proxy SIP wysyła odwołanie do SBC i działa jako transferor
Serwer proxy SIP jako transferor jest preferowaną metodą transferów wywołań.
Normy opisano w sekcji 6 RFC 5589. Powiązane RFC to:
Ta opcja zakłada, że serwer proxy SIP działa jako transferor i wysyła komunikat Refer do SBC. SBC działa jako transfer i obsługuje Refer w celu wygenerowania nowej oferty do przeniesienia. Istnieją dwa możliwe przypadki:
- Połączenie jest przekazywane do zewnętrznego uczestnika PSTN.
- Wywołanie jest przenoszone z jednego punktu końcowego zestawu SDK do innego punktu końcowego zestawu SDK w tym samym zasobie za pośrednictwem protokołu SBC.
Jeśli wywołanie jest przenoszone z jednego punktu końcowego zestawu SDK do innego punktu końcowego zestawu SDK za pośrednictwem SBC, oczekuje się, że SBC wyda nowe zaproszenie (uruchom nowe okno dialogowe) dla celu transferu przy użyciu informacji odebranych w komunikacie Odwołaj. Aby wypełnić pola To/Transferor dla transakcji żądania wewnętrznie, serwer proxy SIP musi przekazać te informacje wewnątrz nagłówków REFER-TO/REFER-BY. Serwer proxy SIP tworzy identyfikator REFER-TO jako identyfikator URI SIP składający się z nazwy FQDN serwera proxy SIP i albo:
Numer telefonu E.164 w części nazwy użytkownika identyfikatora URI w przypadku, gdy element docelowy transferu jest numerem telefonu lub
Parametry x-m i x-t kodujące odpowiednio pełny docelowy identyfikator mrI transferu i identyfikator zasobu komunikacji.
Nagłówek REFERRED-BY ma identyfikator URI SIP z identyfikatorem URI transferatora zakodowanym w nim i identyfikatorem zasobu transferatora oraz innymi parametrami kontekstu transferu, jak pokazano w poniższej tabeli:
| Parametr | Wartość | Opis |
|---|---|---|
| x-m | MRI | Pełne mrI obiektu docelowego transferu/transferu wypełniane przez CC |
| x-t | Identyfikator dzierżawy | Identyfikator zasobu x-t Opcjonalny identyfikator zasobu wypełniony przez dw |
| x-ti | Identyfikator korelacji transferora | Identyfikator korelacji wywołania elementu transferatora |
| x-tt | Transfer identyfikatora URI wywołania docelowego | Zakodowany identyfikator URI zastępczego wywołania |
W tym przypadku rozmiar nagłówka odwołania może mieć maksymalnie 400 symboli. SBC musi obsługiwać obsługę komunikatów odwołań o rozmiarze do 400 symboli.
Przekazywanie połączeń
Zestaw SDK usługi Azure Communication Services Call Automation może przekierowywać połączenia przychodzące do innego numeru lub punktu końcowego zestawu SDK/usługi Teams, dzwonić równolegle do innego użytkownika lub użytkowników (jednoczesny pierścień) lub dzwonić do grupy użytkowników lub numerów. Kwestie do rozważenia:
Identyfikator URI żądania w żądaniu INVITE z serwera proxy SIP do użytkownika C zawiera parametr przyczynowy.
Nagłówek Informacje o historii jest wypełniany.
Gdy użytkownik A jest innym użytkownikiem PSTN, serwer proxy SIP generuje tymczasowe odpowiedzi "SIP SIP/2.0 181 Call is forwarded" tymczasowej odpowiedzi na użytkownika A.
Jeśli użytkownik A i Użytkownik C są użytkownikami PSTN, serwer proxy SIP zachowuje tymczasowe odpowiedzi "SIP SIP/2.0 181 Call is forwarded" (Wywołanie SIP/2.0 181 jest przekazywane).
Nagłówek Informacje o historii powinien być używany do zapobiegania pętli.
Czasomierz sesji
Serwer proxy SIP obsługuje (zawsze oferuje) czasomierz sesji. Użycie czasomierza sesji przez SBC nie jest obowiązkowe.
Użycie parametru Request-URI user=phone
Serwer proxy SIP analizuje identyfikator Request-URI, a jeśli parametr user=phone jest obecny, usługa obsługuje identyfikator URI żądania jako numer telefonu, pasując do numeru użytkownika. Jeśli parametr nie jest obecny, serwer proxy SIP stosuje heurystyki w celu określenia typu użytkownika Request-URI (numer telefonu lub adres SIP).
Firma Microsoft zaleca zawsze stosowanie parametru user=phone, aby uprościć proces konfigurowania połączeń.
Nagłówek Informacje o historii
Uwaga
W usłudze Azure Communication Services bezpośredni nagłówek Historia routingu jest domyślnie włączony i nie można go wyłączyć.
Nagłówek Informacje o historii służy do ponownego pobierania żądań SIP i "udostępnia standardowy mechanizm przechwytywania informacji o historii żądań w celu umożliwienia szerokiej gamy usług dla sieci i użytkowników końcowych". Aby uzyskać więcej informacji, zobacz RFC 4244 – Sekcja 1.1. W przypadku routingu bezpośredniego ten nagłówek jest używany w scenariuszach równoczesnego dzwonienia i przekazywania wywołań.
Informacje o historii są włączone w następujący sposób:
Serwer proxy SIP wstawia parametr zawierający skojarzony numer telefonu w poszczególnych wpisach Informacje o historii, które składają się na nagłówek Informacje o historii wysyłane do kontrolera PSTN. Używając tylko wpisów, które mają parametr numeru telefonu, kontroler PSTN ponownie kompiluje nowy nagłówek Informacje o historii i przekazuje go do dostawcy magistrali SIP za pośrednictwem serwera proxy SIP.
Nagłówek Informacji historycznych jest dodawany do równoczesnych przypadków dzwonienia i przekazywania połączeń.
Nagłówek Informacji historycznych nie jest dodawany w przypadku przypadków transferu wywołań.
Pojedynczy wpis historii w zrekonstruowanym nagłówku Informacje o historii zawiera parametr numeru telefonu podany w połączeniu z nazwą FQDN routingu bezpośredniego (sip.pstnhub.microsoft.com) ustawioną jako część hosta identyfikatora URI. Parametr "user=phone" dodany jako część identyfikatora URI SIP. Wszystkie inne parametry skojarzone z oryginalnym nagłówkiem Informacje o historii, z wyjątkiem parametrów kontekstu telefonu, przekazywane w zrekonstruowanym nagłówku Informacje o historii.
Uwaga
Wpisy, które są prywatne (określone przez mechanizmy zdefiniowane w sekcji 3.3 RFC 4244) przekazywane jako, ponieważ dostawca magistrali SIP jest zaufanym elementem równorzędnym.
Informacje o historii ruchu przychodzącego są zachowywane w celu zapobiegania pętli.
Poniżej znajduje się format nagłówka Informacje o historii wysyłanego przez serwer proxy SIP:
<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2
Jeśli wywołanie zostało przekierowane kilka razy, informacje o każdym przekierowaniu są dołączone do odpowiedniej przyczyny w kolejności chronologicznej, na liście rozdzielanej przecinkami.
Przykład nagłówka:
History-Info:
<sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
<sip:+113579@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1
Identyfikator URI SIP w nagłówku Informacje o historii jest sformatowany zgodnie z sekcją 25 RFC 3261 (zobacz definicję addr-spec). W poprzednim przykładzie oryginalny tekst nagłówka Reason identyfikatora URI to SIP;cause=496;text="User Busy", który pobiera znaki ;, "i = , odpowiednio do wartości %3Bszesnastku ASCII , %22i 3D.
Informacje o historii są chronione przez obowiązkowy mechanizm TLS.
Połączenie SBC z mechanizmem routingu bezpośredniego i trybu failover
Zobacz sekcję Mechanizm trybu failover na potrzeby sygnalizowania SIP w temacie Wymagania dotyczące infrastruktury routingu bezpośredniego.
Ponów próbę po
Jeśli centrum danych routingu bezpośredniego jest zajęte, usługa może wysłać komunikat Po ponowieniu próby z jednosekundowym interwałem do SBC. Gdy SBC odbiera komunikat 503 z nagłówkiem Po ponowieniu próby w odpowiedzi na zaproszenie, SBC musi przerwać to połączenie i spróbować następnego dostępnego centrum danych firmy Microsoft.
Obsługa ponownych prób (odpowiedź 603)
Jeśli użytkownik końcowy obserwuje kilka nieodebranych wywołań jednego wywołania po spadku połączenia przychodzącego, oznacza to, że mechanizm ponawiania prób dostawcy SBC lub PSTN jest nieprawidłowo skonfigurowany. Należy ponownie skonfigurować SBC, aby zatrzymać działania ponawiania próby w odpowiedzi 603.