RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP 2365686 Urząd Patentowy Rzeczypospolitej Polskiej (96) Data i numer zgłoszenia patentu europejskiego: 08.03.2011 11157381.2 (97) O udzieleniu patentu europejskiego ogłoszono: 16.10.2013 Europejski Biuletyn Patentowy 2013/42 EP 2365686 B1 (13) (51) T3 Int.Cl. H04M 3/38 (2006.01) H04M 3/42 (2006.01) H04M 3/46 (2006.01) (54) Tytuł wynalazku: Sposób i urządzenie do przetwarzania wywołań w sieci komunikacyjnej, zawierającej terminale nomadyczne, takie jak terminale telefoniczne typu softphone (30) Pierwszeństwo: 12.03.2010 FR 1051804 (43) Zgłoszenie ogłoszono: 14.09.2011 w Europejskim Biuletynie Patentowym nr 2011/37 (45) O złożeniu tłumaczenia patentu ogłoszono: 31.03.2014 Wiadomości Urzędu Patentowego 2014/03 (73) Uprawniony z patentu: Orange, Paris, FR (72) Twórca(y) wynalazku: PL/EP 2365686 T3 BERTRAND BOUVET, PERROS-GUIREC, FR (74) Pełnomocnik: rzecz. pat. Grażyna Palka JWP RZECZNICY PATENTOWI DOROTA RZĄŻEWSKA SP. J. ul. Żelazna 28/30 Sienna Center 00-833 Warszawa Uwaga: W ciągu dziewięciu miesięcy od publikacji informacji o udzieleniu patentu europejskiego, każda osoba może wnieść do Europejskiego Urzędu Patentowego sprzeciw dotyczący udzielonego patentu europejskiego. Sprzeciw wnosi się w formie uzasadnionego na piśmie oświadczenia. Uważa się go za wniesiony dopiero z chwilą wniesienia opłaty za sprzeciw (Art. 99 (1) Konwencji o udzielaniu patentów europejskich).
18505/13/P-RO/GP EP 2 365 686 Sposób i urządzenie do przetwarzania wywołań w sieci komunikacyjnej, zawierającej terminale nomadyczne, takie jak terminale telefoniczne typu softphone [0001] Wynalazek dotyczy telefonii w sieciach komunikacyjnych typu Internet, zwłaszcza sposobu i urządzenia do przetwarzania wywołań w sieci komunikacyjnej, zawierającej terminale nomadyczne, takie jak terminale telefoniczne typu softphone. [0002] Telefonia przez sieć komunikacyjną typu Internet, na przykład połączenia nazywane VoIP (akronim od Voice over Internet Protocol w terminologii anglosaskiej), nazywane również głosem przesyłanym przez sieć IP (skrót od Internet Protocol w terminologii anglosaskiej), pozwala na przesyłanie głosu przez sieć komunikacyjną w trybie unicast (punkt do punktu), broadcast (jeden nadawca wielu odbiorców) lub multicast (jeden odbiorca i potencjalnie wszyscy odbiorcy). Taki tryb komunikacji VoIP jest oparty zazwyczaj na protokole SIP (akronim od Session Initiation Protocol w terminologii anglo-saksońskiej). [0003] Obsługa głosu w sieci IP jest ogólnie realizowana za pomocą aplikacji nazywanej softphone w terminologii anglosaskiej, wykonywanej przez komputer, na przykład przez komputer typu PC (skrót od Personal Computer w terminologii anglosaskiej), przez palmtop zwany również PDA (skrót od Personal Digital Assistant w terminologii anglosaskiej) lub inteligentny telefon komórkowy, zwanym także smartphone w terminologii anglosaskiej. Używanie połączeń głosowych w sieci IP rozwija się silnie od kilku lat, zwłaszcza jeśli chodzi o oferty połączeń stacjonarnych, zwanych Multiplay, w których użytkownik abonuje ofertę łączącą telefonię i dostęp do Internetu, a także oferty telefonii komórkowej. [0004] Ustanowienie połączenia między terminalem typu softphone i używaną siecią komunikacyjną jest wykonywane poprzez indywidualny punkt dostępu lub skrzynkę połączeniową, na przykład modem ADSL (skrót od Asymmetric Digital Subscriber Line w terminologii anglosaskiej) albo skrzynkę połączeniową kablową lub za pomocą publicznego punktu dostępu, na przykład hotspota dowolnego operatora telekomunikacyjnego. [0005] Jeśli terminale typu softphone są podłączone do sieci za pomocą skrzynki połączeniowej, uważane są za terminale klasyczne, takie jak telefony PTSN (akronim od Public Switched Telephone Network w terminologii anglosaskiej) lub DECT (akronim od DigitalEnhanced Cordless Telephone w terminologii anglosaskiej). W sytuacji nomadyczności terminale typu softphone korzystają ogólnie z ofert ryczałtowych powiązanych ze skrzynkami połączeniowymi użytkowników poprzez sieć odpowiedniego dostawcy usług internetowych. [0006] Przed użyciem aplikacje softphones muszą być pobrane ze strony internetowej, zainstalowane w komputerze lub innym kompatybilnym terminalu, a następnie powinny pobrać plik konfiguracji, umożliwiający używanie usługi VoIP. [0007] Fig. 1 przedstawia schematycznie środowisko telefonii, w którym może być używany terminal typu softphone.
- 2 - [0008] Środowisko telefonii 100 umożliwia tu klasycznemu terminalowi telefonicznemu 105, na przykład terminalowi DECT, podłączonemu do skrzynki połączeniowej 110, ustanowić lub odebrać połączenie z innym terminalem klasycznym telefonicznym 115, podłączonym do skrzynki połączeniowej 120, przy czym skrzynki połączeniowe 110 i 120 są podłączone do sieci 125. Kontrola i zarządzanie wywołaniami są tu realizowane przez serwer CSCF 130 (skrót od Call Session Control Function w terminologii anglosaskiej) podłączony do serwera 135 aplikacji telefonii przez sieć 125. Skrzynka połączeniowa 110 pozwala również terminalowi typu softphone, którym może być na przykład komputer 140, ustanowić lub odbierać rozmowy, zwłaszcza poprzez połączenie typu WiFi, między komputerem 140 i skrzynką połączeniową 110. Terminal 105 i terminal typu softphone użyty w komputerze 140 współdzielą tu taką samą tożsamość publiczną. [0009] Terminal typu softphone, użyty w komputerze 140, może być również używany w oddzielnym punkcie dostępu skrzynki połączeniowej 110, zwłaszcza w punkcie dostępu 145, którym może być na przykład punkt dostępu typu WiFi. W tym kontekście komputer 140 jest oznaczony jako 140'. [0010] Strzałka 150 pokazuje ustanowienie połączenia między terminalem 115 a terminalem powiązanym ze skrzynką połączeniową 110, to znaczy jednym z terminali (105, 140, 140') współdzielących tę samą tożsamość publiczną, powiązaną ze skrzynką połączeniową 110. [0011] Zazwyczaj terminale typu softphone wykorzystują architekturę IMS (skrót od IP Multimedia Subsystem w terminologii anglosaskiej), używającą do identyfikacji terminali następujących tożsamości: tożsamości prywatnej oznaczonej IMPI (skrót od IP Multimedia Private Identity w terminologii anglosaskiej); i, tożsamości publicznej oznaczonej IMPU (skrót od IP Multimedia PUblic Identity w terminologii anglosaskiej). [0012] Tożsamości te są typu URI (skrót od Uniform Resource Identifier w terminologii anglosaskiej). [0013] Terminale typu softphone, uzupełniające w stosunku do terminali fizycznych, połączonych ze skrzynkami połączeniowymi, mogą mieć tę samą tożsamość publiczną (IMPU), jak terminale klasyczne i w zależności od przypadku taką samą tożsamość prywatną (IMPI) lub nie. [0014] Można tu zaobserwować, że współdzielenie tożsamości publicznej między wieloma terminalami pozwala na powiadomienie wszystkich terminali współdzielących tę samą tożsamość publiczną, gdy wykryta zostanie rozmowa przychodząca. Pozwala również zmniejszyć zasoby wykorzystywane przez dostawcę usług, zwłaszcza liczba licencji programowych w ramach architektury IMS, przy czym model ekonomiczny polega typowo na przydzieleniu licencji do adresu publicznego. Ponadto łatwiej wystawić fakturę dla tożsamości publicznej niż dla tożsamości klienta.
- 3 - [0015] Niemniej jednak używanie wielokrotnych tożsamości publicznych dla terminali typu softphone jest pod pewnymi względami bardzo łatwe do realizacji. W rzeczywistości w takim przypadku używany serwer aplikacji może łatwo rozróżnić rozmowy pochodzące z każdego terminala i w rezultacie stosować różne logiki usług. Przypomina się, że serwer aplikacji SIP może znać jedynie tożsamości publiczne, przy czym tożsamości prywatne (IMPI) są używane jedynie do uwierzytelniania terminali. [0016] Uwzględniając, że wybór współdzielenia tej samej tożsamości publicznej (IMPU) jest realizowany dla wszystkich terminali klienta, dostawca usług może ustalić dodatkowe ograniczenia użytkowania dla terminali typu softphone. Ograniczenia są na przykład następujące, gdy terminal typu softphone jest połączony ze skrzynką połączeniową (to znaczy w domu klienta): jedna rozmowa przychodząca/wychodząca jest autoryzowana w danym momencie na fizycznym terminalu telefonicznym lub na terminalu typu softphone, podłączonym do skrzynki połączeniowej. Takie ograniczenie funkcjonalne może być narzucone przez dostawcę usług, aby przyzwyczaić klientów do traktowania terminali typu softphone jak terminali klasycznych. Opcja typu Rozmowy symultaniczne może zostać zaproponowana dla uwierzytelnienia wielu jednoczesnych rozmów przychodzących/wychodzących; i, gdy terminal typu softphone jest wykorzystywany w sytuacji nomadyczności: dostawca usług chce zazwyczaj uwierzytelnić dwie jednoczesne rozmowy (jedną na terminalu klasycznym podłączonym do skrzynki połączeniowej i drugą na terminalu typu softphone w sytuacji nomadyczności) ze względu na przepisy. W rzeczywistości, jeśli terminal typu softphone jest używany w sytuacji nomadyczności dla pierwszej aktywnej rozmowy, osoba pozostająca w domu powinna móc używać swojego terminala klasycznego, aby przywołać służby ratownicze (straż pożarna, policja,...) niezależnie od abonamentu. [0017] W rezultacie, ze względu na wymagane usługi i uwzględniając fakt, że terminale klienta współdzielą tę samą tożsamość publiczną, serwer aplikacji telefonicznej, zliczający rozmowy symultaniczne, powinien dysponować informacją o lokalizacji terminala lub terminali softphone klienta, aby zastosować odpowiednią logikę usług. [0018] Załączone tabele 1 i 2 przedstawiają, jako przykład, możliwości kombinacji rozmów symultanicznych, żądanych przez dostawcę usług, w zależności od konfiguracji połączenia terminala typu softphone, powiązanego ze skrzynką połączeniową, gdy usługa rozmowy oczekującej nie jest wykorzystywana (tabela 1) i gdy jest wykorzystywana (tabela 2). [0019] Jednocześnie należy tu przypomnieć, że informacje dotyczące lokalizacji są zazwyczaj dostarczane w sposób statyczny do serwera aplikacji telefonicznej podczas rejestracji klientów, ponieważ wyposażenie w sprzęt do dynamicznego dostarczania informacji o lokalizacji nie jest dostępne lub jest stosunkowo drogie. Ponadto, w zależności od punktu dostępu terminala typu softphone w sytuacji nomadyczności, nie jest pewne czy dostawca dostępu (na przykład punktu dostępu WiFi) jest w stanie dostarczyć taką informację. Poza tym, nawet jeśli byłaby ona znana, należałoby dysponować wyposażeniem typu punkt
- 4 - wejściowym sieci VoIP, tak aby umieścić tę informację o lokalizacji w protokole SIP P-ANI (skrót od P Access Network Information w terminologii anglosaskiej), co nie jest możliwe w tym przypadku. Ponadto, takie rozwiązanie spowodowałoby problemy z poufnością danych, które mogą być uznane za dane osobiste. [0020] Dokumenty US 2005//282559 oraz WO 2008/2008/074122 opisują architekturę systemu zarządzania usługami telefonii zgodnie ze stanem techniki. [0021] Wynalazek pozwala rozwiązać co najmniej jeden z problemów przedstawionych powyżej, pozwalając zwłaszcza na wykrywanie rozmów wychodzących, pochodzących ze skrzynki połączeniowej i terminali typu softphone, podłączonych do tej skrzynki, a następnie wykrywać, czy terminale typu softphone są podłączone poprzez skrzynkę połączeniową lub są używane w sytuacji nomadyczności. Wspólne tożsamości publiczne są używane dla wszystkich terminali klienta zwłaszcza dla uniknięcia kosztów dodatkowych licencji programowych, a ponadto uproszczenia aspektów związanych z systemami przetwarzania używanych informacji do, na przykład, rejestracji klientów, fakturowania i synchronizacji informacji osobowych, jak również dla uproszenia mechanizmów konfiguracji VoIP terminali (brak konieczności dokładnej identyfikacji każdego z terminali typu softphone). [0022] Celem wynalazku jest więc sposób zarządzania usługami przez serwer aplikacji telefonicznej, podłączony do sieci komunikacyjnej, przy czym co najmniej jedna skrzynka połączeniowa jest podłączona do tej sieci komunikacyjnej, co najmniej jeden terminal nomadyczny, na przykład terminal typu softphone, jest bezpośrednio podłączony do tej sieci komunikacyjnej lub jest podłączony do tej sieci komunikacyjnej za pomocą co najmniej jednej skrzynki połączeniowej, przy czym co najmniej jeden terminal ma tożsamość publiczną, powiązaną z tą co najmniej jedną skrzynką połączeniową i współdzieloną z co najmniej jednym innym terminalem podłączonym do tej co najmniej jednej skrzynki połączeniowej, różnym od tego co najmniej jednego terminala nazywanego pierwszym terminalem, a ten sposób obejmuje następujące etapy, odbiór co najmniej jednego żądania usługi z tego pierwszego terminala, przy czym to żądanie usługi obejmuje wskazanie lokalizacji względnej pierwszego terminala; analiza co najmniej jednego żądania usługi zgodnie ze wstępnie określoną logiką, a ta wstępnie określona logika jest funkcją wskazania lokalizacji względnej; i, w odpowiedzi na ten etap analizy, odrzucenie lub realizacja co najmniej jednej żądanej usługi. [0023] Sposób według wynalazku pozwala tak zarządzać żądaniami usług pochodzącymi z terminali podłączonych do skrzynki połączeniowej i współdzielących tożsamość publiczną z innymi terminalami podłączonymi z tą skrzynką, w zależności od lokalizacji terminali wywołujących te usługi i od oferty dostępu tych usług. Jak wskazano poprzednio, używanie wspólnych tożsamości publicznych pozwala uniknąć kosztów dodatkowych licencji programowych, uprościć aspekty związane z systemami przetwarzania informacji używanymi do, na przykład, rejestracji klientów, fakturowania i synchronizacji informacji osobowych, jak również uprościć mechanizmy konfiguracji terminali.
- 5 - [0024] Według szczególnego przykładu wykonania, co najmniej jedno żądanie usługi jest komunikatem sygnalizacji rozmowy, przy czym etap analizy obejmuje etap porównania liczby rozmów w trakcie, powiązanych z co najmniej jedną skrzynką połączeniową przy maksymalnej dozwolonej liczbie rozmów zgodnie z co najmniej jednym wskazaniem lokalizacji względnej. Sposób według wynalazku pozwala przez to na łatwe zarządzanie dostępem do usług w zależności od warunków powiązanych z maksymalną dozwoloną liczbą rozmów i powiązanych z ofertami abonowanymi przez użytkowników. [0025] Korzystnie komunikat sygnalizacji jest komunikatem zgodnym z protokołem SIP, przy czym wskazanie lokalizacji względnej jest przesyłane w polu dedykowanym tego komunikatu. Sposób według wynalazku pozwala przez to uzyskać prostą informację o lokalizacji terminala na początku zapytania o dostęp do usługi. [0026] Według szczególnego przykładu wykonania wynalazku, sposób obejmuje ponadto etap wczytywania profilu usług, przy czym profil jest powiązany z użytkownikiem pierwszego terminala i wskazaniem lokalizacji względnej. Sposób według wynalazku umożliwia tak łatwe zarządzanie usługami zgodnie z warunkami przypisanymi do użytkowników, w zależności od ich lokalizacji. [0027] Według szczególnego przykładu wykonania wynalazku, sposób obejmuje ponadto etap przesyłania co najmniej jednej informacji o konfiguracji pierwszego terminala, przed etapem odbioru co najmniej jednego żądania usługi, przy czym co najmniej jedna informacja o konfiguracji jest przesyłana w odpowiedzi na żądanie aktywacji pierwszego terminala, a informacja o konfiguracji jest reprezentatywna dla wskazania lokalizacji względnej, przy czym odbiór żądania aktywacji i etap przesyłania co najmniej jednej informacji o konfiguracji pierwszego terminala są realizowane przez serwer konfiguracji. [0028] Wskazanie lokalizacji względnej jest korzystnie określone zgodnie z adresem źródłowym, zawartym w żądaniu aktywacji. [0029] Według szczególnego przykładu wykonania wynalazku, sposób obejmuje ponadto etap aktywacji wstępnej pierwszego terminala, przy czym pierwszy terminal jest podłączony do co najmniej jednej skrzynki połączeniowej, a etap konfiguracji obejmuje utworzenie i przesłanie do pierwszego terminala pliku cookie sesji, zawierającego identyfikację tego pierwszego terminala, pozwalającą na późniejszą identyfikację terminala, unikając przez to nowego żądania wprowadzania parametrów identyfikacji i/lub uwierzytelniania terminala podczas jego uruchomienia. [0030] Sposób obejmuje ponadto korzystnie etap odbioru pliku cookie sesji i etap identyfikacji pierwszego terminala na podstawie odebranego pliku cookie sesji. [0031] Celem wynalazku jest również program komputerowy, zawierający instrukcje przystosowane do realizacji każdego z etapów sposobu opisanych poprzednio, gdy program ten jest wykonywany przez komputer, serwer aplikacji telefonicznej, zawierający środki przystosowane do realizacji każdego z etapów sposobu opisanego powyżej, jak również urządzenie zawierające co najmniej jeden serwer aplikacji telefonicznej i co najmniej jeden
- 6 - serwer konfiguracji, przy czym urządzenie zawiera środki przystosowane do realizacji każdego z etapów sposobu opisanego powyżej. [0032] Zalety, które zapewnia program komputerowy, serwer aplikacji telefonicznej i urządzenie są podobne, jak wspomniane powyżej. [0033] Inne zalety, cele i cechy wynalazku wynikają ze szczegółowego opisu poniżej, podanego jako przykład niewyczerpujący wszystkich możliwości, zgodnie z dołączonymi rysunkami, na których: fig. 1 przedstawia schematycznie środowisko telefonii, w którym może być używany terminal typu softphone; fig. 2 przedstawia schematycznie niektóre etapy konfiguracji terminala typu softphone podczas jego pierwszej aktywacji; fig. 3 przedstawia schematycznie niektóre etapy zarządzania rozmowami nadawanymi przez terminal typu softphone, gdy jest on podłączony do skrzynki połączeniowej; fig. 4 przedstawia schematycznie niektóre etapy konfiguracji terminala typu softphone podczas jego aktywacji w sytuacji nomadyczności; fig. 5, zawierająca fig. 5a i 5b, przedstawia niektóre etapy realizacji przez serwer aplikacji, dla przetwarzania rozmów według wynalazku; i, fig. 6 przedstawia przykład urządzenia pozwalającego zrealizować przynajmniej częściowo wynalazek. [0034] Ogólnie celem wynalazku jest mechanizm zarządzania rozmowami, aby powiązać logikę usług w zależności informacji o lokalizacji względnej. Informacje są przesyłane przez terminale nomadyczne, na przykład terminale typu softphone, do serwera aplikacji, w komunikacie sygnalizacji rozmowy, przy czym tożsamość publiczna terminala jest współdzielona z innymi terminalami podłączonymi do tej samej skrzynki połączeniowej. Informacje o lokalizacji względnej mają na celu głównie sposób połączenia terminala, aby określić czy jest połączony za pomocą skrzynki połączeniowej czy oddzielnego punktu dostępu. Może on przyjąć wartości stacjonarny lub nomadyzm. Może być również używana przez serwer aplikacji, który zarządza licznikiem rozmów, aby kontrolować sygnalizowane rozmowy, przychodzące i wychodzące, aby je ustawić lub nie zgodnie ze wstępnie określoną logiką i poziomem abonamentu. [0035] Według szczególnego przykładu wykonania wynalazku, wynalazek jest realizowany z użyciem protokołu SIP. W szczególnym polu, nazywanym tu SIP User Agent, wartość jest podnoszona na poziomie stosu SIP. Zawiera on informację o lokalizacji względnej terminala typu softphone pozwalającego serwerowi aplikacji, odbierającemu te informację, kontrolować rozmowy. [0036] Korzystnie informacja o lokalizacji względnej jest określona przez serwer aplikacji, do którego podłączony jest terminal typu softphone podczas fazy uruchamiania, umożliwiając przez to konfigurację VoIP. Informacja o lokalizacji względnej może być określona zwłaszcza zgodnie z adresem logicznym terminala, na przykład jego adresem IP i adresem logicznym skrzynki połączeniowej, do której jest podłączony terminal. Informacja
- 7 - o lokalizacji względnej może być określona w różny sposób, zwłaszcza poprzez porównanie położenia geograficznego, określanego na przykład za pomocą modułu GPS (skrót od Global Positioning System w terminologii anglosaskiej), z położeniem geograficznym skrzynki połączeniowej określonym na podstawie danych rejestracyjnych użytkownika terminala. [0037] Aby odpowiedzieć na niektóre żądania operacyjne dostawcy usług (liczniki rozmów dozwolone w zależności od lokalizacji) i aby wszystkie terminale podłączone go tej samej skrzynki połączeniowej posiadały taką samą tożsamość publiczną (IMPU), pole SIP User Agent protokołu SIP zawiera informację o lokalizacji odbieraną, gdy terminal żąda swojej konfiguracji VoIP, gdy jest uaktywniany. [0038] Należy tu przypomnieć, że ze względów bezpieczeństwa konfiguracja terminala typu softphone nie jest zapisywana lokalnie i jest pobierana przy każdorazowej aktywacji terminala. [0039] Podczas pierwszej aktywacji terminal typu softphone powinien być podłączony do skrzynki połączeniowej, z którą jest powiązany. W ten sposób może pobrać swoją konfigurację VoIP z serwera typu FCPE (skrót od Frontal Customer Premise Equipment w terminologii anglosaskiej), którego adres bezwzględny (adres FQDN, skrót od Fully Qualified Domain Name w terminologii anglosaskiej) jest do niego dostarczany w kodzie aplikacji. Żądanie pobrania może być, na przykład, żądaniem http (skrót od HyperText Transfer Protocol w terminologii anglosaskiej). [0040] Serwer konfiguracji FCPE wydziela adres źródłowy z odebranego komunikatu, na przykład adres IP odebranego pakietu IP, należącego do tego komunikatu. Ten adres jest używany dla umożliwienia odpowiedzi na żądanie, a także jako referencja. Serwer pobierania konfiguracji FCPE przesyła ten adres do serwera identyfikacji dla identyfikacji klienta na początku takiego żądania. Można tu zaobserwować, że gdy skrzynka połączeniowa nawiązała sesję internetową PPPoE (skrót od Point-to-Point Protocol over Ethernet w terminologii anglosaskiej), aby odebrać adres IP i adresy serwerów DNS (skrót Domain Name Server w terminologii anglosaskiej), klient został zidentyfikowany za pomocą identyfikatora i hasła używanych dla sesji PPPoE i serwera BAS/Radius (akronim od Broadband Access Server w terminologii anglosaskiej) dla przypisania adresu IP. Informacje te są zapisywane przez serwer identyfikacji. [0041] Ponieważ w pierwszej kolejności następuje aktywacja terminala typu softphone, serwer konfiguracji FCPE żąda od klienta jego identyfikatora poczty (skrzynka poczty elektronicznej) dla większego zabezpieczenia usługi. Jeśli informacje wprowadzane przez klienta są poprawne, serwer konfiguracji generuje pliki cookie sesji na określony czas, na przykład na dwa miesiące, aby tak uniknąć nowego żądania wprowadzania parametrów uwierzytelniających przy każdym włączeniu terminala typu softphone. [0042] Serwer konfiguracji FCPE dostarcza więc plik konfiguracji VoIP do terminala. Można tu zauważyć, że plik konfiguracji VoIP zawiera dodatkowe pole związane z wynalazkiem, czyli pole Lokalizacja=Dom. Informacja ta jest dostarczana na podstawie rozpoznania adresu źródłowego IP przypisanego do skrzynki połączeniowej przez serwer BAS.
- 8 - [0043] Terminal typu softphone inicjalizuje więc swój stos SIP za pomocą następujących pól: IMPU=IMPU@nazwa domeny, zawarte w pliku konfiguracji; IMPU=IMPI@nazwa domeny, zawarte w pliku konfiguracji; Password=Password SIP zawarty w pliku konfiguracji; i, SIP User Agent=Softphone_Dom [0044] Terminal może więc zarejestrować się i uwierzytelnić na poziomie rdzenia sieci IMS, wykorzystując jej punkt wejściowy, dostarczany również w pliku konfiguracji. Może również przekazywać i odbierać rozmowy. [0045] Fig. 2 przedstawia schematycznie niektóre etapy konfiguracji terminala 200 typu softphone podczas jego pierwszego uruchomienia, w zależności od skrzynki połączeniowej 202 (Box), serwera BAS/Radius 204, serwera identyfikacji 206, serwera DNS 208, serwera FCPE 210 i rdzenia IMS 212. [0046] Początkowy etap (etap 214) ma na celu żądanie ustanowienia sesji PPPoE. Żądanie to, nadane przez skrzynkę połączeniową 202 w kierunku serwera BAS/Radius 204, zawiera identyfikator i hasło użytkownika dla ustanowienia połączenia internetowego. Pozwala ono skrzynce połączeniowej 202 nawiązać sesję internetową PPPoE. [0047] Po tym etapie następuje żądanie identyfikacji klienta (etap 216). Jest ono przesyłane z serwera BAS/Radius 204 do serwera identyfikacji 206. Zawiera ono odebrany identyfikator i hasło, pozwalające użytkownikowi ustanowić połączenie internetowe. W odpowiedzi serwer BAS/Radius 204 odbiera z serwera identyfikacji 206 identyfikację klienta i listę dozwolonych usług internetowych (etap 218). [0048] Serwer BAS/Radius 204 określa więc adres IP dla skrzynki połączeniowej 202 oraz adres pierwotny i wtórny IP DNS. Adresy te są przesyłane przez serwer BAS/Radius 204 do skrzynki połączeniowej 202 (etap 220). [0049] Skrzynka połączeniowa 202 ustanawia więc sesję internetową PPPoE, umożliwiającą aktywację terminalu 200. [0050] Podczas aktywacji terminal 200, podłączony za pomocą skrzynki połączeniowej 202, wysyła żądanie pozyskania adresu, aby odebrać adres serwera FCPE na podstawie adresu typu FQDN (etap 222). Żądanie to jest przesyłane przez terminal 200 do serwera DNS 208 za pomocą skrzynki połączeniowej 202 i serwera BAS/Radius 204. W odpowiedzi serwer DNS przesyła adres IP serwera FCPE 210 odpowiadający odebranemu adresowi typu FQDN (etap 224). [0051] Terminal 200 przesyła więc do serwera FCPE 210 żądanie odbioru pliku konfiguracji VoIP (etap 226). Żądanie jest przesyłane zgodnie z protokołem http terminala 200 do serwera FCPE 210 za pomocą skrzynki połączeniowej 202 i serwera BAS/Radius 204. Po odbiorze takiego żądania, serwer FCPE 210 pyta serwer identyfikacji 206 (etap 228) o tożsamość klienta w zależności od funkcji adresu źródłowego IP żądania odbioru pliku konfiguracji VoIP. Ten adres IP odpowiada adresowi IP skrzynki połączeniowej 202. W odpowiedzi, serwer FCPE 210 odbiera z serwera identyfikacji 206 tożsamość klienta (etap 230).
- 9 - [0052] Po odbiorze tożsamości klienta, serwer FCPE 210 żąda korzystnie od terminala 200 uwierzytelnienia, przekazując identyfikator i hasło poczty (etap 232). Żądanie to jest przesyłane przez serwer FCPE 210 w kierunku terminala 200 przez serwer BAS/Radius 204 i skrzynkę połączeniową 202. W odpowiedzi, terminal 200 przesyła serwerowi FCPE 210, za pomocą skrzynki połączeniowej 202 i serwera BAS/Radius 204, żądanie odbioru pliku konfiguracji VoIP, zawierającego identyfikator i hasło poczty użytkownika, zgodnie z protokołem http (etap 234). [0053] Po odbiorze tego żądania serwer FCPE 210 sprawdza na serwerze identyfikacji 206, czy identyfikowany klient ma ten właśnie identyfikator i hasło poczty (etap 236). Serwer identyfikacji 206 odpowiada serwerowi FCPE 210 pozytywnie lub negatywnie (etap 238). [0054] Jeśli identyfikowany klient ma ten właśnie identyfikator i hasło poczty, serwer FCPE 210 sprawdza, czy klient dysponuje usługą VoIP, generuje plik cookie sesji korzystnie o okresie ważności wielu miesięcy i generuje plik konfiguracji VoIP, w którym znajduje się informacja precyzująca, czy terminal 200 jest podłączony do skrzynki połączeniowej 202, to znaczy, czy terminal 200 jest w konfiguracji domowej (etap 240). [0055] Serwer FCPE 210 przesyła więc wygenerowany plik konfiguracji VoIP i plik cookie sesji do terminala 200 za pomocą serwera BAS/Radius 204 i skrzynki połączeniowej 202 (etap 242). Plik konfiguracji VoIP jest korzystnie przekształcany do formatu xml (skrót od extensible Markup Language w terminologii anglosaskiej). [0056] Jak przedstawiono, odbierany plik konfiguracji VoIP 244 zawiera informacje o lokalizacji względnej lokalizacja=dom. [0057] Aby zarejestrować się, terminal 200 przesyła żądanie pozyskania adresu do serwera DNS 208, za pomocą skrzynki połączeniowej 202 i serwera BAS/Radius 204, aby odebrać adres IP rdzenia IMS 212 na podstawie adresu typu FQDN (etap 246). W odpowiedzi terminal 200 odbiera z serwera DNS 208, za pomocą serwera BAS/ Radius 204 i skrzynki połączeniowej 202, adres IP punktu wejściowego rdzenia IMS 212 (etap 248). [0058] Terminal 200 może więc wysłać żądanie rejestracji do rdzenia IMS 212 (etap 250). Żądanie, zawierające tożsamość publiczną terminala 200, jest przesyłane za pomocą skrzynki połączeniowej 202 i serwera BAS/Radius 204. W odpowiedzi rdzeń IMS 212 żąda od terminala 200, poprzez serwer BAS/Radius 204 i skrzynkę połączeniową 202, uwierzytelnienia (etap 252). Terminal 200 przesyła więc żądanie rejestracji, zawierające tożsamość publiczną terminala 200 i dane uwierzytelniające, do rdzenia IMS 212 za pomocą skrzynki połączeniowej 202 i serwera BAS/Radius 204 (etap 254). Rdzeń IMS 212 rejestruje więc terminal 200 i potwierdza mu, poprzez serwer BAS/Radius 204 i skrzynkę połączeniową 202, wskazując czas trwania rejestracji (etap 256). [0059] Terminal 200 jest więc gotowy do wysyłania i odbierania rozmów. [0060] Po rejestracji, jeśli terminal typu softphone próbuje przesłać rozmowę wychodzącą, sygnalizacja rozmowy przechodzi do rdzenia IMS i usługi telefoniczne, powiązane
- 10 - z rozmówcą wywołującym, nazywane również originating w terminologii anglosaskiej, są wyłączone. [0061] Sygnalizacja rozmowy SIP przechodzi więc do serwera aplikacji. Serwer ten może odnaleźć konto klienta za pomocą jego tożsamości publicznej dostępnej w polach From, P- Preferred-ID i/lub P-Asserted-ID komunikatu SIP. Może on tak sprawdzić, jakie usługi związane z rozmówcą wywołującym powinny być uaktywnione dla tego klienta (rozmowa zastrzeżona, ograniczenie rozmów itp.). [0062] Serwer aplikacji sprawdza licznik rozmów symultanicznych, dozwolonych dla tego klienta. Ponieważ pole SIP USER Agent przybiera tu wartość Softphone-Dom, serwer aplikacji nie musi uwierzytelniać tylko jedną rozmowę symultaniczną (pod warunkiem, że klient nie zaabonował oferty umożliwiającej wiele rozmów symultanicznych). Zasada ta jest korzystnie konfigurowana na poziomie serwera aplikacji. [0063] Jeśli żadna rozmowa nie jest aktywna w skrzynce połączeniowej, licznik bieżącej rozmowy przyjmuje wartość zero. Rozmowa wychodząca rozpoczęta przez terminal typu softphone jest więc uwierzytelniona, a licznik bieżącej rozmowy wzrasta o jeden w czasie trwania rozmowy, i zmniejszany o jeden po jej zakończeniu (za pomocą komunikatu typu BYE). Jeśli podczas tej rozmowy, skrzynka połączeniowa próbuje nawiązać inną rozmowę, serwer aplikacji porównuje wartość licznika rozmów z maksymalną liczbą rozmów symultanicznych dla klienta i zezwala lub nie w zależności od wyniku porównania. Dla zobrazowania, jeśli dozwolona jest tylko jedna rozmowa symultaniczna, serwer aplikacji nie zezwala na ustanowienie drugiej rozmowy, gdy jedna rozmowa pochodzi z terminala typu softphone i jest on zlokalizowany w domu. Tak samo, jeśli skrzynka połączeniowa ustanowiła pierwszą rozmowę przed żądaniem ustanowienia rozmowy przez terminal typu softphone, serwer aplikacji odrzuca żądanie rozmowy pochodzące z tego terminala, jeśli jest on zlokalizowany w domu. [0064] Fig. 3 przedstawia schematycznie niektóre etapy zarządzania rozmowami nadawanymi przez terminal 300 typu softphone w zależności od rdzenia IMS 304, serwera aplikacji telefonii 306, oznaczonego jako AS Tel i terminala nazywanego 308, gdy terminal jest podłączony do skrzynki połączeniowej z nim powiązanej. [0065] Można tu zauważyć, że chociaż wszystkie połączenia między terminalem 300 a innymi urządzeniami przechodzą przez skrzynkę połączeniową i serwer BAS/Radius, nie są one przedstawione ze względu na czytelność. [0066] Gdy rozmowa wychodząca jest nadawana przez terminal 300, komunikat sygnalizacji rozmowy SIP jest przesyłany przez terminal 300 do rdzenia IMS 304 (etap 310). Komunikat ten, typu INVITE, ma tożsamość publiczną (IMPU) terminala wywołującego, numer terminala wywoływanego (zazwyczaj tożsamość publiczna terminala wywoływanego) i, według wynalazku, wskazanie lokalizacji, w takim wypadku pole SIP UserAgent przyjmuje wartość dom. [0067] W odpowiedzi rdzeń IMS 304 przesyła komunikat typu 100 TRYING (próba) do terminala 300, aby mu wskazać, że żądanie jest w trakcie przetwarzania (etap 312). Ponadto
- 11 - rdzeń IMS 304 przesyła odebrany komunikat sygnalizacyjny rozmowy SIP, wraz z tożsamością publiczną wywołującego, numer terminala wywoływanego i pole SIP User Agent, do serwera aplikacji telefonii 306 (etap 314). Serwer przesyła komunikat typu 100 TRYING do rdzenia IMS 304, aby mu wskazać, że żądanie jest w trakcie przetwarzania (etap 316). [0068] Algorytm autoryzacji rozmowy, zawierający zwłaszcza etap porównania wartości licznika rozmów dozwolonych z maksymalną liczbą rozmów dozwolonych dla klienta, jest więc używany do określenia, czy rozmowa może być ustanowiona lub nie (etap 318). [0069] Odwracając sytuację, komunikat o odmowie typu 403 Forbidden jest przesyłany przez serwer aplikacji telefonii 306 do rdzenia IMS 304 (etap 320), który przesyła go do terminala 300 (etap 322). Terminal 300 potwierdza więc tę odmowę do rdzenia IMS 304 (etap 324), który przesyła tę informację dalej do serwer aplikacji (nieprzedstawiony na fig. 3). [0070] Jeśli przeciwnie, rozmowa może być ustanowiona, serwer aplikacji telefonii 306 przesyła komunikat typu NVITE, zawierający tożsamość publiczną rozmówcy wywoływanego wraz z lub bez pola SIP User Agent, a nawet modyfikację pola SIP User Agent, do rdzenia IMS 304 (etap 326). W odpowiedzi, rdzeń IMS 304 przesyła komunikat typu 100 TRYING do serwera aplikacji telefonii 306, aby mu wskazać, że żądanie jest w trakcie przetwarzania (etap 328). [0071] W podobny sposób rdzeń IMS 304 przesyła więc komunikat typu INVITE, zawierający tożsamość publiczną terminala wywołującego i numer terminala wywoływanego, wraz z lub bez pola SIP User Agent, do terminala wywoływanego 308 (etap 330), który w odpowiedzi, przesyła komunikat typu 100 TRYING do rdzenia IMS 304, aby mu wskazać, że żądanie jest w trakcie przetwarzania (etap 332), a następnie komunikat typu 180 RINGING (etap 334). [0072] Rdzeń IMS 304 przesyła wówczas odebrany komunikat 180 RINGING do serwera aplikacji telefonii 306 (etap 336), który przesyła go ponownie do rdzenia IMS 304 (etap 338), skąd jest przesyłany do terminala 300 (etap 340). [0073] Jeśli terminal wywoływany 308 akceptuje rozmowę, komunikat akceptacji typu 200 OK jest przez niego przesyłany do rdzenia IMS 304 (etap 342). Komunikat akceptacji jest następnie przesyłany do serwera aplikacji telefonii 306 (etap 344), który przesyła go ponownie do rdzenia IMS 304 (etap 346), skąd jest przesyłany do terminala 300 (etap 348). [0074] Terminal 300 potwierdza wówczas rozmowę, przekazując komunikat akceptacji typu ACK do rdzenia IMS 304 (etap 350). Komunikat akceptacji jest następnie przesyłany do serwera aplikacji telefonii 306 (etap 352), który przesyła go ponownie do rdzenia IMS 304 (etap 354), skąd jest przesyłany do terminala wywoływanego (etap 356). [0075] Strumień audio 358, na przykład strumień audio RTP (skrót od Real- time Transport Protocol w terminologii anglosaskiej), jest ustanawiany między terminalem 300 i terminalem wywoływanym 308.
- 12 - [0076] Gdy terminal typu softphone według wynalazku jest używany w sytuacji nomadyczności, łączy się po uruchomieniu z serwerem konfiguracji VoIP FCPE dla odbioru w szczególności pliku konfiguracji VoIP. [0077] Serwer konfiguracji FCPE wydziela adres źródłowy z odebranego komunikatu, na przykład adres IP odebranego pakietu IP należącego do tego komunikatu. Ten adres jest używany zwłaszcza dla umożliwienia odpowiedzi na żądanie, a także jako referencja. Serwer konfiguracji FCPE przesyła ten adres do serwera identyfikacji dla identyfikacji klienta na początku takiego żądania. [0078] W tym celu serwer identyfikacji analizuje ten adres IP. Niemniej jednak, ponieważ terminal jest w tym przypadku połączony za pomocą punktu dostępu, a nie przez skrzynkę połączeniową, z którą jest powiązany terminal, zidentyfikowany adres IP nie odpowiada żadnemu klientowi. W tej konfiguracji, gdy klient nie może zostać zidentyfikowany przez adres IP, serwer konfiguracji odnajduje identyfikator klienta na podstawie pliku cookie sesji, utworzonego podczas pierwszej aktywacji i przekazanego wraz z żądaniem odbioru pliku konfiguracji VoIP. [0079] Jeśli plik cookie jest ważny, serwer konfiguracji generuje plik konfiguracji VoIP, wskazując że terminal jest w sytuacji nomadyczności, to znaczy, na przykład, wykorzystując wartość nomadyczność w polu pliku konfiguracji ( Lokalizacja=Nomadyczność ). [0080] Jeśli czas ważności pliku cookie sesji został przekroczony, serwer konfiguracji żąda od klienta ponownego uwierzytelnienia, na przykład na podstawie identyfikatora i hasła poczty. Jeśli klient zostanie uwierzytelniony, nowy plik cookie sesji jest generowany przez serwer konfiguracji ze wstępnie określonym terminem ważności, zazwyczaj na wiele miesięcy lub na wiele godzin. Jest powiązany z identyfikatorem klienta. [0081] Serwer konfiguracji generuje wówczas plik konfiguracji VoIP, zawierający pole Lokalizacja=Nomadyczność. [0082] Terminal typu softphone inicjalizuje więc swój stos SIP za pomocą następujących pól: IMPU=IMPU@nazwa domeny, zawarte w pliku konfiguracji; IMPU=IMPI@nazwa domeny, zawarte w pliku konfiguracji; Password=Password SIP zawarty w pliku konfiguracji; i, SIP User Agent=Softphone_Nomadyczność. [0083] Terminal typu softphone może więc zarejestrować się i uwierzytelnić na poziomie rdzenia sieci IMS, wykorzystując jej punkt wejściowy, dostarczany również w pliku konfiguracji. [0084] Softphone może również przekazywać i odbierać rozmowy. [0085] Fig. 4 przedstawia schematycznie niektóre etapy konfiguracji terminala 400 typu softphone podczas jego pierwszego uruchomienia w sytuacji nomadyczności, w zależności od serwera identyfikacji 402, serwera DNS 404, serwera FCPE 406 i rdzenia IMS 408.
- 13 - [0086] Można tu zauważyć, że chociaż wszystkie połączenia między terminalem 400 a innymi urządzeniami przechodzą przez punkt dostępu, nie jest on przedstawiony ze względu na czytelność. [0087] Pierwszy etap ma na celu uzyskanie adresu IP serwera FCPE 406. W tym celu żądanie pozyskania adresu jest przesyłane przez terminal 400 do serwera DNS 404 (etap 410). Żądanie to zawiera adres typu FQDN serwera FCPE 406. W odpowiedzi, serwer DNS 404 przesyła adres IP serwera FCPE 406 (etap 412). [0088] Terminal 400 przesyła więc żądanie do serwera FCPE 406 dla odbioru pliku konfiguracji VoIP (etap 414). Żądanie to zawiera zwłaszcza plik cookie sesji odebrany wcześniej przez terminal 400. Jest ono, na przykład, nadawane zgodnie z protokołem http. Po odbiorze tego żądania, serwer FCPE 406 żąda od serwera identyfikacji 402 tożsamości klienta wykorzystując terminal 400 (etap 416). Żądanie to zawiera adres źródłowy IP żądania odbioru pliku konfiguracji VoIP, to znaczy adresu IP punktu dostępu przez który terminal 400 jest podłączony do sieci komunikacyjnej. [0089] Ponieważ serwer identyfikacji 402 nie zna adresu IP, który odbiera, odpowiada serwerowi FCPE 406, że klient jest nieznany (etap 418). [0090] Serwer FCPE 406 określa wówczas, do kogo należy plik cookie odebrany w żądaniu odbioru pliku konfiguracji VoIP (na przykład wysyłając zapytanie do serwera identyfikacji) i generuje odpowiedni plik konfiguracji (etap 420). Plik ten zawiera wskazanie według którego terminal 400 jest w sytuacji nomadyczności. [0091] Jak wskazano poprzednio, jeśli plik cookie sesji nie jest już ważny, serwer FCPE 406 może przesłać do terminala 400 żądanie uwierzytelnienia, aby odnowić plik cookie sesji (nieprzedstawiony). [0092] Plik konfiguracji VoIP, jak również plik cookie sesji są następnie przesyłane przez serwer FCPE 406 do terminala 400 (etap 422). Plik konfiguracji VoIP jest korzystnie przesyłany w formacie xml. [0093] Jak przedstawiono, odebrany plik konfiguracji VoIP 424 zawiera określenie lokalizacja=dom. [0094] Aby zarejestrować się, terminal 400 przesyła żądanie pozyskania adresu do serwera DNS 404, aby odebrać adres IP rdzenia IMS 408 na podstawie adresu typu FQDN (etap 426). W odpowiedzi terminal 400 odbiera z serwera DNS 404 adres IP punktu wejściowego rdzenia IMS 408 (etap 428). [0095] Terminal 400 może więc wysłać żądanie rejestracji do rdzenia IMS 408 (etap 430). Żądanie 10 ma tożsamość publiczną terminala 400. W odpowiedzi rdzeń IMS 408 żąda od terminala 400 uwierzytelnienia (etap 432). Terminal 400 przesyła więc żądanie rejestracji zawierające tożsamość publiczną terminala 400 i dane uwierzytelniające, do rdzenia IMS 408 (etap 434). Rdzeń IMS 408 rejestruje wówczas terminal 400 potwierdza ten fakt wskazują mu czas trwania rejestracji (etap 436). [0096] Terminal 400 jest więc gotowy do wysyłania i odbierania rozmów.
- 14 - [0097] Jak wskazano powyżej, po rejestracji, jeśli terminal typu softphone próbuje przesłać rozmowę wychodzącą, sygnalizacja rozmowy przechodzi do rdzenia IMS i usługi telefoniczne, powiązane z rozmówcą wywołującym, są wyłączone. [0098] Ponownie sygnalizacja rozmowy SIP przechodzi do serwera aplikacji, a serwer aplikacji może odnaleźć konto klienta poprzez jego tożsamość publiczną, dostępną w polach From, P-Preferred-ID i/lub P-Asserted-ID komunikatu SIP. Może on tak sprawdzić, jakie usługi związane z rozmówcą wywołującym powinny być uaktywnione dla tego klienta (rozmowa zastrzeżona, ograniczenie rozmów itp.). [0099] Serwer aplikacji sprawdza więc licznik rozmów symultanicznych, dozwolonych dla tego klienta. Ponieważ pole SIP User Agent ma tutaj wartość Softphone_Nomadyczność, serwer aplikacji musi uwierzytelnić co najmniej dwie rozmowy symultaniczne: jedną z domu i co najmniej jedną z terminala w sytuacji nomadyczności (pod warunkiem, że klient zaabonował ofertę umożliwiającą wiele rozmów symultanicznych z domu i/lub w sytuacji nomadyczności). Zasada ta jest korzystnie konfigurowana na poziomie serwera aplikacji. [0100] Jak w poprzednim przypadku, w którym terminal typu softphone nadaje rozmowę będąc połączonym ze skrzynką połączeniową, z którą jest powiązany, licznik rozmów bieżących ma wartość zero, jeśli nie odbywa się żadna rozmowa. Rozmowa wychodząca pochodząca z terminala w sytuacji nomadyczności jest dozwolona, a licznik rozmów bieżących jest zwiększany o jeden, a następnie zmniejszany o jeden podczas uwolnienia rozmowy za pomocą komunikatu typu BYE. [0101] Jeśli podczas rozmowy wykonywanej przez terminal w sytuacji nomadyczności, skrzynka połączeniowa domu próbuje nawiązać równoległą rozmowę, na przykład z numerem alarmowym, serwer aplikacji uznaje, że wartość licznika rozmów jest równa jeden dla bieżącej rozmowy w sytuacji nomadyczności. Zezwala on więc na drugą rozmowę z urządzenia domowego. [0102] Tak samo, jeśli skrzynka połączeniowa domowa nawiązała pierwszą rozmowę przed żądaniem nawiązania rozmowy przez terminal w sytuacji nomadyczności, serwer aplikacji akceptuje tę rozmowę. [0103] Niemniej jednak, jeśli próbuje się nawiązać drugą rozmowę z urządzenia domowego, zakładając że inny terminal typu softphone jest podłączony do skrzynki połączeniowej oprócz używanego terminala telefonicznego, serwer aplikacji nie zezwala na tę drugą rozmowę poprzez analizę pól SIP User_ agent. [0104] Używając pola SIP User_agent, serwer aplikacji może zastosować logikę przetwarzania rozmowy dla terminali typu softphone, inną w sytuacji nomadyczności i inną dla terminali podłączonych do skrzynki połączeniowej, z którą są one związane, mimo tego, że mają tę samą tożsamość publiczną IMPU. [0105] Zarządzanie rozmowami nadawanymi przez terminal typu softphone, gdy jest on w sytuacji nomadyczności, jest podobne do zarządzania rozmowami nadawanymi przez
- 15 - terminal typu softphone, gdy jest on bezpośrednio podłączony do skrzynki połączeniowej, z którą jest związany. Różni się on jedynie algorytmem autoryzacji rozmów. [0106] Dlatego też, za wyjątkiem autoryzacji rozmów, algorytm opisany zgodnie z fig. 3 odnosi się do zarządzania rozmową nadaną przez terminal typu softphone, gdy jest on w sytuacji nomadyzmu. [0107] Fig. 5, zawierająca fig. 5a i 5b, przedstawia schematycznie niektóre etapy realizacji na serwerze aplikacji dla przetwarzania rozmów według wynalazku. Fig. 5a dotyczy wykrywania typu rozmowy i przetwarzania rozmów wyjściowych, a fig. 5b dotyczy rozmów przychodzących. [0108] Jak pokazano na fig. 5a, celem pierwszego etapu jest określenie typu rozmowy, to znaczy określenie, czy chodzi o rozmowę przychodzącą czy o rozmowę wychodzącą (etap 500). [0109] Jeśli chodzi o rozmowę wychodzącą, celem następnego etapu jest określenie, czy tożsamość publiczna terminala rozmówcy wywołującego jest znana serwerowi aplikacji i zapisana w bazie danych (BD), w której są zapisane tożsamości publiczne terminali mogących wywoływać rozmowy za pomocą zaproponowanej usługi (etap 502). [0110] Jeśli tożsamość publiczna terminala rozmówcy wywołującego nie jest znana serwerowi aplikacji, odpowiedź z odmową jest wysyłana do terminala wywołującego (etap 504), który przesyła potwierdzenie odbioru do serwera aplikacji (etap 506). Algorytm kończy działanie. [0111] Jeśli przeciwnie, tożsamość publiczna terminala wywołującego jest znana serwerowi aplikacji, przeprowadzany jest test dla określenia, czy terminal wywołujący znajduje się w sytuacji nomadyczności, czy nie (etap 508). Jeśli terminal rozmówcy wywołującego nie jest w sytuacji nomadyczności, profil usług według którego odbierana rozmowa jest nadawana z urządzenia domowego (terminal klasyczny lub terminal typu softphone), jest ładowany do pamięci serwera aplikacji (etap 510). W przeciwnym przypadku, jeśli terminal rozmówcy wywołującego jest w sytuacji nomadyczności, profil usług według którego odbierana rozmowa jest nadawana z terminala typu softphone niepodłączonego do skrzynki połączeniowej, z którą jest powiązany, jest ładowany do pamięci serwera aplikacji (etap 512). Profile usług załadowane do pamięci są w tym wypadku usługami typu originating. Pozwalają one zwłaszcza określić używaną logikę usług. [0112] Liczba ustanowionych rozmów bieżących, bez uwzględniania rozmowy w trakcie przetwarzania, jest następnie porównywana z maksymalną liczbą dozwolonych rozmów symultanicznych dla klienta wywołującego, w zależności od wcześniej załadowanego profilu (etap 514). Etap ten ma na celu porównanie liczby rozmów bieżących z maksymalną liczbą rozmów symultanicznych zgodnie z pochodzeniem rozmów bieżących. Tytułem przykładu, dwie rozmowy symultaniczne mogą być dozwolone, jeśli co najmniej jedna rozmowa jest nawiązana za pomocą danej skrzynki połączeniowej.
- 16 - [0113] Jeśli liczba ustanowionych rozmów bieżących nie jest mniejsza od liczby maksymalnej dozwolonych rozmów dla klienta wywołującego, zgodnie z załadowanym wcześniej profilem, wywołanie w trakcie przetwarzania jest odrzucane. W tym celu, odpowiedź z odrzuceniem wywołania jest wysyłana do rozmówcy wywołującego (etap 504), przekazując potwierdzenie odbioru do serwera aplikacji (etap 506). Algorytm kończy działanie. [0114] Przeciwnie, jeśli liczba ustanowionych rozmów bieżących jest mniejsza od liczby maksymalnej dozwolonych rozmów dla klienta wywołującego, zgodnie z załadowanym wcześniej profilem, liczba rozmów bieżących jest zwiększana o jeden (etap 516). Usługi związane z rozmówcą wywołującym są więc aktywowane w zależności od profilu wcześniej załadowanego do pamięci (etap 518), komunikat sygnalizacji rozmowy (INVITE) jest przesyłany w kierunku terminala rozmówcy wywoływanego (etap 520), a komunikaty odebrane przez serwer aplikacji są analizowane (etap 522). [0115] Gdy odebrany komunikat jest typu 100 TRYING, algorytm wykonuje pętlę (przynajmniej przez określony czas), oczekując na nowy komunikat. [0116] Gdy odebrany komunikat jest typu OK, jest on przesyłany dalej do terminala rozmówcy wywołującego (etap 524). Algorytm wykonuje pętlę (przynajmniej przez określony czas) oczekując na nowy komunikat. [0117] Gdy odebrany komunikat jest typu ACK, odebrany komunikat jest przesyłany dalej do terminala rozmówcy wywoływanego (etap 526). Algorytm wykonuje pętlę (przynajmniej przez określony czas), oczekując na nowy komunikat. [0118] Gdy komunikat jest typu BYE lub CANCEL, liczba rozmów bieżących jest zmniejszana o jeden (etap 528), a odebrany komunikat jest przesyłany dalej do terminala rozmówcy wywoływanego lub rozmówcy wywołującego, aby zakończyć działanie algorytmu (etap 530). [0119] Gdy odebrany komunikat jest typu 487 REQUEST_ TERMINATED, kończy on działanie algorytmu. [0120] Przetwarzanie rozmów przychodzących jest przedstawione na fig. 5b. [0121] Jeśli rozmowa w trakcie przetwarzania jest rozmową przychodzącą (fig. 5a, etap 500), celem następnego etapu jest określenie, czy tożsamość publiczna terminala wywoływanego jest znana serwerowi aplikacji i zapisana w bazie danych (BD), w której są zapisane tożsamości publiczne terminali, które mogą być wywoływane za pomocą zaproponowanej usługi (etap 532). [0122] Jeśli tożsamość publiczna terminala rozmówcy wywoływanego nie jest znana serwerowi aplikacji, odpowiedź z odrzuceniem rozmowy typu 404 Not Found jest wysyłana do terminala rozmówcy wywołującego (etap 534), który przesyła potwierdzenie odbioru do serwera aplikacji (etap 536). Algorytm kończy działanie.
- 17 - [0123] Jeśli przeciwnie, tożsamość publiczna terminala rozmówcy wywoływanego jest znana serwerowi aplikacji, profil usług dla rozmówcy wywoływanego, zwany zazwyczaj usługami terminating w terminologii anglosaskiej, jest ładowany do pamięci (etap 538). [0124] Jest wówczas wykonywany test, aby określić, czy usługa wysłania bezwarunkowego rozmów jest aktywna (etap 540). Celem usługi jest wysłanie wszystkich rozmów przychodzących do wstępnie określonego numeru, na przykład numeru poczty głosowej lub numeru osoby trzeciej. [0125] Jeśli usługa wysłania bezwarunkowego rozmów jest skonfigurowana, rozmowa przychodząca jest wysyłana do wstępnie określonego numeru znajdującego się w profilu terminating rozmówcy wywoływanego (etap 542). Algorytm kończy działanie. [0126] Jeśli przeciwnie, usługa wysyłania bezwarunkowego rozmów nie jest skonfigurowana, wykonywany jest test, aby porównać liczbę nawiązanych rozmów bieżących, bez uwzględniania rozmowy w trakcie przetwarzania, z maksymalną liczbą dozwolonych rozmów symultanicznych dla klienta wywoływanego, zgodnie z profilem załadowanym wcześniej (etap 544). Etap ten ma na celu porównanie liczby rozmów bieżących z maksymalną liczbą rozmów symultanicznych zgodnie z pochodzeniem rozmów bieżących. Tytułem przykładu, dwie rozmowy symultaniczne mogą być dozwolone, jeśli co najmniej jedna rozmowa jest nawiązana za pomocą danej skrzynki połączeniowej. [0127] Jeśli liczba bieżących rozmów nie jest mniejsza od maksymalnej liczby dozwolonych rozmów symultanicznych dla klienta wywoływanego, rozmowa w trakcie przetwarzania jest wysyłana na wstępnie określony numer znajdujący się w profilu terminating rozmówcy wywoływanego (etap 542). Algorytm kończy działanie. [0128] Przeciwnie, jeśli liczba ustanowionych bieżących rozmów jest mniejsza niż maksymalna liczba rozmów symultanicznych dozwolonych dla klienta wywołującego, usługi terminating klienta wywoływanego są aktywne (etap 546) i komunikat rozmowy INVITE jest wysyłany do terminala rozmówcy wywoływanego (etap 548). [0129] Liczba rozmów bieżących jest więc zwiększana o jeden (etap 550) i są analizowane komunikaty odebrane przez serwer aplikacji (etap 552). [0130] Gdy odebrany komunikat jest typu 100 TRYING, algorytm wykonuje pętlę (przynajmniej przez określony czas), oczekując na nowy komunikat. [0131] Gdy odebrany komunikat jest typu 200 OK, jest on przesyłany dalej do terminala rozmówcy wywołującego (etap 554). Algorytm wykonuje pętlę (przynajmniej przez określony czas) oczekując na nowy komunikat. [0132] Gdy odebrany komunikat jest typu ACK, ten odebrany komunikat jest przesyłany dalej do terminala rozmówcy wywoływanego (etap 556). Algorytm wykonuje pętlę (przynajmniej przez określony czas) oczekując na nowy komunikat. [0133] Gdy odebrany komunikat jest typu BYE lub CANCEL, liczba rozmów bieżących jest zmniejszana o jeden (etap 558), a odebrany komunikat jest przesyłany dalej do terminala
- 18 - rozmówcy wywoływanego lub rozmówcy wywołującego, aby zakończyć działanie algorytmu (etap 560). [0134] Gdy odebrany komunikat jest typu 487 REQUEST_ TERMINATED, ten odebrany komunikat jest wysyłany do terminala rozmówcy wywoływanego lub wywołującego, aby zakończyć rozmowę i działanie algorytmu (etap 560). [0135] Urządzenie przystosowane do realizacji wynalazku lub części wynalazku jest przedstawione na fig. 6. Urządzenie 600 jest na przykład stacją roboczą lub komputerem typu PC. [0136] Urządzenie 600 zawiera szynę komunikacyjną 605, do której są podłączone: jednostka centralna lub mikroprocesor 610 (CPU, Central Processing Unit); pamięć stała 615 (ROM, akronim od Read Only Memory w terminologii anglosaskiej) mogąca zawierać programy Prog, Prog1 i Prog2 ; pamięć operacyjna lub pamięć cache 620 (RAM, akronim od Random Access Memory w terminologii anglosaskiej) zawierający rejestry przystosowane do rejestrowania zmiennych i parametrów tworzonych lub modyfikowanych w trakcie wykonywania wymienionych programów; i, interfejs komunikacyjny 650, przystosowany do przesyłania i odbioru danych, zwłaszcza komunikatów związanych z rozmowami przychodzącymi i wychodzącymi. [0137] Opcjonalnie urządzenie 600 może również posiadać: ekran 625 (Ec) pozwalający wyświetlić dane i/lub obsłużyć interfejs graficzny przez użytkownika, który będzie mógł operować na programach według wynalazku, za pomocą klawiatury i myszy 630 (CS) lub innego urządzenia wskazującego, ekran dotykowy lub pilot; dysk twardy (DD) 635 mogący pomieścić wymienione programy Prog, Prog1 i Prog2 i dane do przetwarzania według wynalazku, i, czytnik kart pamięci 640 (Lc) dostosowany do kart pamięci 645 (C) i do odczytu dany przetwarzanych lub do przetworzenia według wynalazku. [0138] Szyna komunikacyjna umożliwia komunikację i współdziałanie różnych elementów zawartych w urządzeniu 600 lub do niego podłączonych. Przedstawienie szyny nie jest ograniczające, zwłaszcza jednostka centralna może przekazywać instrukcje każdemu elementowi urządzenia 600 bezpośrednio lub za pomocą innego elementu urządzenia 600. [0139] Kod wykonywalny każdego programu, pozwalający urządzeniu programowalnemu wykonać procesy według wynalazku, może być zapisany na przykład na dysku twardym 635 lub w pamięci stałej 615. [0140] Według przykładu wykonania, karta pamięci 645 może zawierać dane, jak również kod wykonywalny wymienionych wyżej programów, które po odczytaniu przez urządzenie 600 są zapisywane na dysku twardym 635.
- 19 - [0141] Według innego przykładu wykonania, kod wykonywalny programów może być pobrany, przynajmniej częściowo, przez interfejs 650 dla zapisania w identyczny sposób, jak opisany powyżej. [0142] Ogólnie, program/y mogą być zapisane na jednym z nośników pamięci urządzenia 600 przed wykonaniem. [0143] Jednostka centralna 610 będzie sterować i kierować wykonaniem instrukcji lub części kodu programu/ów według wynalazku, instrukcji które są zapisane na dysku twardym 635 lub w pamięci stałej 615 lub na innych wymienionych elementach. Po podłączeniu napięcia, program lub programy, które są zapisane w pamięci nieulotnej, na przykład na dysku twardym 635 lub w pamięci stałej 615, są przesyłane do pamięci operacyjnej 620, która zawiera kod wykonywalny programu lub programów według wynalazku, jak również rejestry do zapisywania zmiennych i parametrów koniecznych do realizacji wynalazku. [0144] Należy pamiętać, że urządzenie komunikacyjne, zawierające urządzenie według wynalazku, może również być urządzeniem programowanym.. Urządzenie to zawiera więc kod programu lub programów informatycznych, na przykład umieszczony w specjalnych układach scalonych (ASIC). [0145] Chociaż opis dotyczy zasadniczo problemu zarządzania rozmowami symultanicznymi, wynalazek może być zastosowany do rozwiązywania podobnych problemów. [0146] W szczególności można zaproponować oferty różnych usług telefonicznych dla terminali podłączonych do skrzynki połączeniowej dla terminali typu powiązanych z tą skrzynką, w sytuacji nomadyczności, przy czym mogą być one traktowane jako terminale podrzędne. W szczególności czas rozmowy terminali podłączonych do skrzynki połączeniowej może być różny od czasu dla terminali typu softphone, powiązanych z tą skrzynką, w sytuacji nomadyczności, zwłaszcza dla uniknięcia nadużyć lub nadmiernego korzystania z darmowych rozmów. Przez to możliwe jest zakazanie rozmów zbyt kosztownych wykonywanych z terminali typu softphone w sytuacji nomadyczności. Można również nie proponować niektórych usług, na przykład usługi znanej pod nazwą numer zastrzeżony, z terminali typu softphone w sytuacji nomadyczności. Można także zaproponować różne parametry w zależności od sytuacji, na przykład zaproponować różne listy telefonów dla usługi znanej jako Rozmowy zastrzeżone dla terminali podłączonych do skrzynki połączeniowej i dla terminali typu softphone, powiązanych z tą skrzynką, w sytuacji nomadyczności. [0147] Oczywiście można użyć istniejącego pola, aby przesłać informacje zapisane tutaj w polu SIP User Agent. Na przykład możliwe jest użycie pola lokalizacji SIP PANI. Niemniej jednak, ponieważ ich kodowanie jest zazwyczaj znormalizowane, nie jest zalecane ich użycie. [0148] W końcu informacja o lokalizacji, dostarczana w polu User_ agent, może być odebrana w różny sposób. W szczególności, może być odebrana z modułu pozycjonowania, na przykład modułu GPS zainstalowanego w terminalu typu softphone. W takim przypadku, informacja o lokalizacji może być wykorzystywana przez serwer aplikacji i można