5. Descrizione normativa

Questa sezione descrive normativamente le estensioni delle funzionalità di apparenza condivisa. Le seguenti definizioni sono utilizzate in tutto questo documento:

Appearance number (Numero di apparenza): Un numero di apparenza è un intero positivo associato a uno o più dialoghi di un AOR. I numeri di apparenza sono gestiti da un Appearance Agent e visualizzati e resi all'utente da UAs che supportano questa specifica.

Seizing (Sequestro): Un'apparenza può essere riservata prima che venga effettuata una chiamata sequestrandola. Un'apparenza può essere sequestrata comunicando uno stato artificiale di "trying" prima di avviare effettivamente un dialogo.

Selecting (Selezione) (o Not-Seizing): Un'apparenza è semplicemente selezionata (cioè, non sequestrata) se non c'è tale comunicazione di stato artificiale di "trying" prima di avviare un dialogo.

5.1. Elementi

Un sistema completo per implementare questa funzionalità consiste di:

1. UAs che supportano pubblicazioni, sottoscrizioni e notifiche per il pacchetto di eventi di dialogo SIP e le estensioni e il comportamento del pacchetto di dialogo di apparenza condivisa.

2. Un Appearance Agent costituito da uno State Agent per il pacchetto di eventi di dialogo che implementa un Event State Compositor (ESC) e le estensioni e il comportamento del pacchetto di dialogo di apparenza condivisa.

3. Un server proxy di forking che può comunicare con lo State Agent.

4. Un registrar che supporta il pacchetto di eventi di registrazione.

Il comportamento di questi elementi è descritto normativamente nelle sezioni seguenti dopo le definizioni delle estensioni del pacchetto di dialogo.

5.2. Estensioni del pacchetto di dialogo per apparizioni condivise

Questa specifica definisce quattro nuovi elementi come estensioni al pacchetto di eventi di dialogo SIP [RFC4235]. Lo schema è definito nella sezione 6. Gli elementi sono <appearance>, <exclusive>, <joined-dialog> e <replaced-dialog>, che sono sotto-elementi dell'elemento <dialog>.

5.2.1. L'elemento <appearance>

L'elemento <appearance>, figlio dell'elemento <dialog>, viene utilizzato per trasmettere il numero di apparizione del dialogo descritto dall'elemento <dialog> padre. Quando viene inviato da un UA in un PUBLISH con <dialog> padre con attributo state "trying" all'agente di apparizione, l'UA sta richiedendo l'assegnazione del numero di apparizione specificato al dialogo corrente o futuro con gli identificatori di dialogo specificati. Quando un elemento <appearance> viene inviato dall'agente di apparizione in una NOTIFY, indica che il numero di apparizione è stato assegnato al dialogo specificato.

Si noti che un elemento <dialog-info> descrive i dialoghi contenuti dal punto di vista dell'UA (denominato dall'attributo "entity"), indipendentemente dal fatto che la richiesta contenitrice sia inviata dall'UA o dall'agente di apparizione. In particolare, se l'UA ha inviato una richiesta all'interno del dialogo descritto, l'URI del campo di intestazione To corrisponderebbe al valore <remote> <identity> e il parametro to-tag corrisponderebbe all'attributo remote-tag. Analogamente, l'URI del campo di intestazione From corrisponderebbe al valore <local> <identity> e il parametro from-tag corrisponderebbe all'attributo local-tag.

5.2.2. L'elemento <exclusive>

L'elemento <exclusive>, figlio dell'elemento <dialog>, è un booleano che, quando è true, indica che l'UA non è disposto ad accettare un INVITE con un campo di intestazione Join o Replaces indirizzato al dialogo descritto dall'elemento <dialog> che è il padre dell'elemento <exclusive>. Ad esempio, alcuni sistemi di apparizioni condivise consentono la ripresa della chiamata solo quando la chiamata è in attesa. In questo caso, l'elemento <exclusive> dovrebbe essere impostato su "false" quando la chiamata è in attesa e su "true" quando la chiamata non è in attesa, anziché lasciare che il valore "exclusive" sia implicito dallo stato di attesa.

È importante notare che questo elemento è solo un suggerimento. Per impedire a un altro UA di prendere o di unirsi a una chiamata, un UA può, oltre a impostare il tag <exclusive>, non segnalare le informazioni complete del dialogo all'agente di apparizione. La mancanza delle informazioni complete del dialogo (Call-ID, remote-tag e local-tag) impedisce a un altro UA di costruire un campo di intestazione Join o Replaces. Sebbene un UA possa impostare <exclusive> su "true", l'UA deve comunque essere pronto a rifiutare un INVITE Join relativo a questo dialogo. Se questi identificatori di dialogo sono già stati condivisi con l'agente di apparizione, l'UA potrebbe inviare un INVITE Replaces per modificarli e poi non segnalare i nuovi all'agente di apparizione.

Se il proxy sa quali dialoghi sono contrassegnati come esclusivi, il proxy PUÒ imporre questa esclusività rifiutando le richieste INVITE Join e INVITE Replaces contenenti tali identificatori di dialogo con una risposta 403 (Forbidden).

Si noti che l'esclusività non ha nulla a che fare con la selezione o l'occupazione del numero di apparizione -- riguarda invece le operazioni di controllo della chiamata che possono essere eseguite su un dialogo.

Se l'elemento <exclusive> non è presente, si presume che sia false.

5.2.3. L'elemento <joined-dialog>

L'elemento <joined-dialog>, figlio dell'elemento <dialog>, viene utilizzato per trasmettere gli identificatori di dialogo di qualsiasi altro dialogo unito (miscelato o in bridging) con il dialogo. Solo l'UA che è l'endpoint comune dei dialoghi miscelati (e che quindi controlla l'operazione di miscelazione) dovrebbe includere questo elemento nelle pubblicazioni all'agente di apparizione. Si noti che questo elemento dovrebbe essere utilizzato anche quando il campo di intestazione Join non è stato utilizzato per unire i dialoghi. Ad esempio, due dialoghi separati su un UA potrebbero essere uniti senza alcuna operazione di controllo della chiamata SIP. I dialoghi uniti condivideranno lo stesso numero di apparizione.

Se l'elemento <joined-dialog> non è presente, si presume che il dialogo non sia unito né debba essere unito a qualsiasi altro dialogo.

5.2.4. L'elemento <replaced-dialog>

L'elemento <replaced-dialog>, figlio dell'elemento <dialog>, viene utilizzato per trasmettere gli identificatori di dialogo di qualsiasi altro dialogo che sarà o è stato sostituito con questo dialogo. Ad esempio, un UA nel gruppo che riprende una chiamata su un altro UA inviando un INVITE con Replaces includerebbe questo elemento per il dialogo sostitutivo. I dialoghi sostituiti condivideranno lo stesso numero di apparizione.

Se l'elemento <replaced-dialog> non è presente, si presume che il dialogo non abbia sostituito né debba sostituire qualsiasi altro dialogo.

5.3. Agenti utente con apparizioni condivise

Gli UA che supportano la funzionalità di apparizioni condivise utilizzano il pacchetto di stato del dialogo [RFC4235] con le estensioni di apparizione condivisa e il parametro del campo di intestazione Event 'shared' definito nella sezione 13.

Gli UA utilizzano le estensioni del pacchetto di dialogo nella sezione 5.2 insieme a SUBSCRIBE [RFC6665], NOTIFY [RFC6665] e PUBLISH [RFC3903]. Le richieste SUBSCRIBE, NOTIFY e PUBLISH per il pacchetto di eventi del dialogo includono il parametro del campo di intestazione Event 'shared' come richiesto da questa specifica.

La presenza del parametro del campo di intestazione Event 'shared' indica all'agente di apparizione che l'UA supporta questa specifica.

All'inizializzazione, l'UA DEVE sottoscrivere il pacchetto di eventi del dialogo dell'AOR e aggiornare la sottoscrizione secondo il SIP Events Framework [RFC6665]. Se la richiesta SUBSCRIBE fallisce, allora potrebbe non essere presente alcun agente di apparizione e questa funzionalità non è attiva per questo AOR. L'UA PUÒ riprovare periodicamente la sottoscrizione per vedere se le condizioni sono cambiate a intervalli non inferiori a quattro ore.

Quattro ore sono state scelte per limitare il test di sottoscrizione a sei al giorno per UA. L'aumento di questo intervallo ridurrebbe questo traffico di fallimento ma richiederebbe più tempo per scoprire un agente di apparizione appena attivato.

Gli UA possono anche utilizzare la presenza del parametro del campo di intestazione Event 'shared' nei NOTIFY per scoprire la presenza di un agente di apparizione per l'AOR.

Gli UA che implementano la funzionalità di apparizioni condivise, la risposta alle chiamate, l'unione e il bridging DEVONO supportare l'invio di un INVITE con Replaces [RFC3891] o Join [RFC3911]. L'agente utente client (UAC) deve includere le informazioni to-tag e from-tag nell'intestazione Replaces o Join in modo che il dialogo corretto venga abbinato dall'agente utente server (UAS) secondo le regole degli RFC 3891 e 3911.

Tutti gli UA che implementano la funzionalità di apparizioni condivise e supportano INVITE DEVONO supportare la ricezione di un INVITE con un campo di intestazione Replaces [RFC3891] o Join [RFC3911].

Quando si pubblicano o si notificano informazioni sul pacchetto di dialogo, un UA include il più grande set di identificazione del dialogo disponibile al momento della pubblicazione, con l'eccezione che un UA può omettere informazioni se desidera impedire ad altri UA di unirsi o rispondere a una chiamata. L'identificazione del dialogo include URI di destinazione locali e remoti, call-id, to-tag e from-tag. Sebbene queste informazioni di identificazione del dialogo siano opzionali in [RFC4235], sono essenziali nella funzionalità di apparizioni condivise, consentendo operazioni di controllo delle chiamate. Quando si mettono le chiamate in attesa, utilizzare il tag di funzionalità "+sip.rendering=no" per indicare ciò nelle notifiche del pacchetto di dialogo. L'utilizzo della descrizione completa della sessione SDP costringe invece l'endpoint a eseguire molta analisi aggiuntiva, complicando inutilmente il codice e invitando errori.

Il rendering accurato dello stato inattivo/attivo/avviso/attesa degli altri UA nel gruppo è una parte importante della funzionalità di apparizioni condivise.

Un UA che non ha bisogno di occupare un particolare numero di apparizione (o non se ne preoccupa) invierebbe semplicemente un INVITE come al solito per effettuare una chiamata in uscita.

Se la chiamata è una chiamata di emergenza, un UA NON DEVE mai attendere un'occupazione confermata prima di inviare un INVITE. Invece, la chiamata di emergenza DEVE procedere senza attendere la transazione PUBLISH.

Se un UA richiede un particolare numero di apparizione, l'UA DEVE inviare una richiesta PUBLISH del pacchetto di dialogo e attendere una risposta 2xx prima di inviare l'INVITE. Questo è richiesto nelle seguenti situazioni:

1. Quando l'utente occupa un particolare numero di apparizione per una chiamata in uscita (ad esempio, occupando l'apparizione e andando "fuori dal gancio", se l'interfaccia utente dell'UA utilizza questa metafora).

2. Quando l'utente ha richiesto che un numero di apparizione non venga utilizzato per una chiamata in uscita (cioè, durante una chiamata di consultazione, una chiamata di "media di servizio" come per la musica in attesa [RFC7088], o per una chiamata non considerata parte del gruppo di apparizioni condivise).

3. Quando l'utente ha scelto di unirsi (o collegare) a una chiamata esistente.

4. Quando l'utente ha scelto di sostituire (o prendere) una chiamata esistente.

Si noti che quando un UA occupa un'apparizione prima dell'istituzione di un dialogo (numeri 1 e 2 nell'elenco sopra), non tutte le informazioni sul dialogo saranno disponibili. In particolare, quando un UA pubblica un tentativo di occupare un'apparizione prima di conoscere l'URI di destinazione, potrebbero essere disponibili informazioni minime o nessuna informazione sul dialogo. Ad esempio, in alcuni casi, sarà noto solo l'URI di destinazione locale per la chiamata: nessuna informazione sul dialogo. Se il tag From e Call-ID non erano presenti nel PUBLISH iniziale, un nuovo PUBLISH DEVE essere inviato non appena queste informazioni sono disponibili.

La prima pubblicazione farà sì che l'agente di apparizione riservi il numero di apparizione per questo UA. Se la pubblicazione non ha alcun identificatore di dialogo (ad esempio, Call-ID o local-tag), l'agente di apparizione non può assegnare il numero di apparizione a un particolare dialogo dell'UA fino alla seconda pubblicazione, che conterrà alcuni identificatori di dialogo.

Questo stato di pubblicazione viene aggiornato come descritto in [RFC3903] durante lo stato del dialogo iniziale o l'agente di apparizione può riassegnare il numero di apparizione. Una volta che il dialogo è passato allo stato confermato, non sono necessari aggiornamenti di pubblicazione.

Questa specifica presuppone che l'agente di apparizione abbia altri mezzi oltre alla pubblicazione UA per conoscere lo stato dei dialoghi UA. In questa specifica, PUBLISH viene utilizzato per indicare le operazioni del numero di apparizione desiderate e previste. Una volta che un dialogo passa da iniziale a confermato, questo ruolo è terminato; quindi, non sono necessari aggiornamenti di pubblicazione.

I numeri di apparizione sono un'etichetta abbreviata per i dialoghi attivi e in sospeso relativi a un AOR. Molte delle funzionalità e dei servizi costruiti utilizzando questa estensione si basano sul rendering corretto di queste informazioni all'utente umano. Inoltre, la natura di gruppo della funzionalità significa che il rendering deve essere simile tra diversi fornitori e diversi modelli. Il mancato rispetto di ciò ridurrà notevolmente il valore e l'utilità di queste estensioni di protocollo. In un'interfaccia utente correttamente progettata per questa funzionalità, il numero di apparizione per ogni dialogo attivo e in sospeso viene esplicitamente (cioè, per numero di apparizione) o implicitamente (utilizzando una metafora dell'interfaccia utente che rende chiara la numerazione e l'ordinamento all'utente) reso all'utente. L'identità dell'estremità remota di ogni dialogo (ad esempio, l'identità della parte remota) non è una sostituzione utile per il numero di apparizione. Lo stato di ogni apparizione deve anche essere reso (inattivo, attivo, occupato, unito, ecc.). Gli UA possono dire che un insieme di dialoghi sono uniti (collegati o mescolati) insieme dalla presenza di uno o più elementi <joined-dialog> contenenti altri identificatori di dialogo SIP. I numeri di apparizione dei dialoghi possono essere appresi tramite notifiche del pacchetto di dialogo contenenti l'elemento <appearance> dall'agente di apparizione o dal parametro Alert-Info 'appearance' in un INVITE in arrivo. In caso di conflitto, la notifica del pacchetto di dialogo ha la precedenza.

Un utente può selezionare un numero di apparizione ma poi abbandonare l'effettuazione di una chiamata (riagganciare). In questo caso, l'UA libera il numero di apparizione rimuovendo lo stato dell'evento con un PUBLISH come descritto in [RFC3903]. Il mancato rispetto di ciò richiederà operazioni non necessarie da parte dell'agente di apparizione e occuperà numeri di apparizione che potrebbero altrimenti essere utilizzati da altri UA nel gruppo di apparizioni condivise.

Un UA DOVREBBE registrarsi all'AOR solo se è probabile che l'UA risponda alle chiamate in arrivo. Se l'UA sta principalmente monitorando lo stato delle chiamate del gruppo di apparizioni condivise e rispondendo o unendosi alle chiamate, l'UA DOVREBBE solo sottoscrivere all'AOR e non registrarsi all'AOR. Se un UA di monitoraggio si registra piuttosto che solo sottoscrivere, genera grandi quantità di traffico di rete non necessario.

Tutti gli UA sottoscritti riceveranno NOTIFY del pacchetto di dialogo dello stato di tentativo per gli INVITE in arrivo.

Un UA NON DEVE inserire un parametro 'appearance' in un campo di intestazione Alert-Info in un INVITE o altra richiesta.

L'agente di apparizione è l'unico responsabile di farlo.

5.3.1. Numeri di apparizione e contesto di chiamata

Ci sono casi in cui due dialoghi separati su un UA non sono mescolati ma condividono lo stesso "contesto". Cioè, si riferiscono l'uno all'altro e non dovrebbero essere trattati allo stesso modo di altri due dialoghi all'interno del gruppo. Un esempio di questo è una "chiamata di consultazione" in cui un utente mette un dialogo esistente in attesa, quindi chiama un altro utente, prima di tornare al dialogo originale. Un altro caso, descritto di seguito, si verifica durante le operazioni di trasferimento, dove per un periodo transitorio, un UA è coinvolto in dialoghi con altri due UA, ma i dialoghi sono correlati e non dovrebbero essere trattati come dialoghi indipendenti. Questi casi sono gestiti al meglio non assegnando un numero di apparizione a un dialogo appena creato quando condivide un contesto con un dialogo esistente. Ma se il dialogo preesistente viene terminato, il suo numero di apparizione dovrebbe essere riassegnato al dialogo appena creato.

Un UA che desidera effettuare una chiamata ma non ha un numero di apparizione assegnato invia un PUBLISH prima di inviare l'INVITE. Il PUBLISH non ha un elemento 'appearance' presente, ma ha il parametro del campo di intestazione Event 'shared' presente. Se la politica dell'agente di apparizione non consente chiamate senza un numero di apparizione assegnato, una risposta 400 (Bad Request) viene inviata dall'agente di apparizione e l'UA ripubblicherà selezionando/occupando un numero di apparizione o invierà l'INVITE senza pubblicare, nel qual caso l'agente di apparizione ne assegnerà uno.

Si noti che se un agente di apparizione rifiuta chiamate senza un numero di apparizione, alcune operazioni come chiamate di consultazione, trasferimento e musica in attesa possono essere impattate negativamente.

5.3.2. Numeri di apparizione e controllo delle chiamate

Quando viene generato un INVITE per tentare di collegare o prendere una chiamata (cioè, contiene Join o Replaces con un identificatore di dialogo di un altro dialogo nel gruppo di apparizioni condivise), l'UA DEVE prima inviare un PUBLISH all'agente di apparizione. Questo PUBLISH conterrà:

1. Il numero di apparizione della chiamata unita o sostituita nell'elemento <appearance>

2. Le informazioni del dialogo dal campo di intestazione Join nell'elemento <joined-dialog>, se il dialogo viene unito

3. Le informazioni del dialogo dal campo di intestazione Replaces nell'elemento <replaced-dialog>, se il dialogo viene sostituito

Si noti che queste informazioni vengono fornite all'agente di apparizione in modo che possa fornire un comportamento di assegnazione dell'apparizione appropriato. Se l'INVITE Join o Replaces è stato inviato senza pubblicare prima, l'agente di apparizione potrebbe assegnare un nuovo numero di apparizione a questo INVITE, il che sarebbe un errore. Con Join, la pubblicazione ha l'elemento <joined-dialog> per impedire all'agente di apparizione di generare una risposta 400 (Bad Request) a causa del riutilizzo di un numero di apparizione. Per Replaces, lo scopo del <replaced-dialog> è impedire una condizione di gara in cui il BYE potrebbe causare il rilascio del numero di apparizione quando dovrebbe rimanere con il dialogo sostitutivo.

5.3.3. Numeri di apparizione e trasferimento

Durante un'operazione di trasferimento, è importante che il numero di apparizione non cambi durante l'operazione. Considera l'esempio di Alice, un membro di un gruppo di apparizioni condivise, che sta parlando con Carol, che è al di fuori del gruppo di apparizioni condivise. Carol trasferisce Alice a David, che è anche al di fuori del gruppo di apparizioni condivise. Ad esempio, se Alice sta utilizzando l'apparizione 3 per la sessione con Carol, la sessione risultante con David dovrebbe anche utilizzare il numero di apparizione 3. Altrimenti, un cambio di numero di apparizione può causare un "salto" sull'interfaccia utente e confusione per l'utente. Ci sono due possibili scenari utilizzando la terminologia della RFC 5589: Alice è il trasferito in qualsiasi tipo di trasferimento (riceve il REFER) o il target di trasferimento in un trasferimento assistito (riceve l'INVITE con Replaces).

Se Alice è il trasferito, l'INVITE innescato dal REFER viene trattato come una chiamata di consultazione. Alice DOVREBBE pubblicare richiedendo che l'agente di apparizione non assegni un numero di apparizione per questo INVITE. Quando il trasferimento è completato, Alice DOVREBBE pubblicare di nuovo per spostare il numero di apparizione dal dialogo con Carol al dialogo con David. Se viene inviato un PUBLISH per spostare il numero di apparizione, la pubblicazione DEVE essere inviata prima di inviare il BYE a Carol per evitare una condizione di gara in cui l'agente di apparizione riassegna il numero di apparizione dopo aver visto il BYE.

Se Alice è il target, l'INVITE in arrivo conterrà un campo di intestazione Replaces. Di conseguenza, l'agente di apparizione avrà riutilizzato il numero di apparizione del dialogo con Carol, e questo numero di apparizione continuerà ad essere utilizzato dopo che il dialogo con Carol è stato terminato.

5.4. Agente di apparizione

Un agente di apparizione definito in questa specifica DEVE implementare un agente di stato del pacchetto di dialogo per gli UA registrati all'AOR. L'agente di apparizione DEVE supportare le estensioni del pacchetto di dialogo di apparizione definite nella sezione 5.2 e utilizzare il parametro del campo di intestazione Event 'shared'. L'agente di apparizione DEVE supportare pubblicazioni e sottoscrizioni per questo pacchetto di eventi.

L'agente di apparizione DEVE avere un modo per scoprire lo stato di tutti i dialoghi associati all'AOR. Se queste informazioni non sono disponibili da un proxy con stato delle chiamate o da un agente utente back-to-back (B2BUA), l'agente di apparizione può utilizzare il pacchetto di eventi di registrazione [RFC3680] per conoscere gli UA associati all'AOR e sottoscrivere il loro stato di evento del dialogo. Un agente di apparizione può anche sottoscrivere lo stato di evento del dialogo di un UA al fine di ricostruire lo stato. Di conseguenza, il registrar DEVE supportare il pacchetto di eventi di registrazione.

Le notifiche del pacchetto di dialogo sono raccomandate dalla RFC 4235 per "contenere solo informazioni sui dialoghi il cui stato o informazioni di partecipazione sono cambiati". Questa specifica estende la RFC 4235 come segue. L'agente di apparizione DOVREBBE inviare notifiche dello stato dell'evento del dialogo ogni volta che i seguenti eventi accadono agli UA nel gruppo AOR:

1. Una chiamata viene ricevuta, effettuata, risposta o terminata.

2. Una chiamata viene messa in attesa o ripresa.

3. Una chiamata viene unita o sostituita.

4. Un numero di apparizione viene riservato o rilasciato.

L'agente di apparizione DEVE allocare un numero di apparizione per tutte le chiamate in arrivo e inviare notifiche immediate agli UA sottoscritti all'AOR del gruppo condiviso. Un nuovo numero di apparizione viene allocato tranne nel caso di un INVITE in arrivo con un campo di intestazione Join o Replaces. In questo caso, il numero di apparizione dovrebbe corrispondere al numero di apparizione del dialogo a cui ci si unisce o che viene sostituito. Se l'INVITE Replaces o Join proviene dall'esterno del gruppo di apparizioni condivise, l'agente di apparizione includerà un elemento <joined-dialog> o <replaced-dialog> nella NOTIFY contenente le informazioni del dialogo dal campo di intestazione Replaces o Joined.

L'agente di apparizione DEVE essere in grado di comunicare con il proxy di forking per conoscere le chiamate in arrivo e anche per passare il numero di apparizione al proxy o garantire che il campo di intestazione Alert-Info sia incluso nell'INVITE con il numero di apparizione appropriato.

Si noti che gli UA devono essere in grado di gestire INVITE in arrivo senza un numero di apparizione assegnato. Ciò potrebbe essere causato da un guasto dell'agente di apparizione o da un'altra condizione di errore. Sebbene la corretta rappresentazione dell'INVITE possa non essere possibile, è meglio che ignorare o far fallire l'INVITE.

Un agente di apparizione DOVREBBE assegnare un numero di apparizione a un dialogo in uscita se non è stato ricevuto un PUBLISH che seleziona/occupa un particolare numero di apparizione.

Si noti che se il gruppo di apparizioni condivise ha UA che non sono a conoscenza delle apparizioni e che effettuano chiamate, l'agente di apparizione allocherà comunque numeri di apparizione per gli INVITE inviati da tali UA.

Un agente di apparizione che riceve un PUBLISH con un numero di apparizione verifica che la pubblicazione sia valida. Un numero di apparizione può essere assegnato a un solo dialogo, a meno che non vi sia un elemento <joined-dialog> o <replaced-dialog> che indichi che il dialogo sarà/è stato sostituito o unito. Viene restituita una risposta 400 (Bad Request) se il numero di apparizione scelto non è valido, e una NOTIFY immediata DOVREBBE essere inviata all'UA contenente lo stato completo dell'evento di dialogo.

Un agente di apparizione che riceve un PUBLISH senza un numero di apparizione ma con il parametro del campo di intestazione Event 'shared' presente interpreta ciò come una richiesta dell'UA di non assegnare un numero di apparizione. Se la politica dell'agente di apparizione non lo consente, viene restituita una risposta 400 (Bad Request). Se la politica lo consente, viene restituita una risposta 200 (OK) e non viene allocato alcun numero di apparizione. Un agente di apparizione non deve condividere queste informazioni di dialogo (cioè inviare una NOTIFY) con altri UA nel gruppo, poiché le informazioni non saranno rappresentate dagli altri UA.

L'agente di apparizione alloca un numero di apparizione a un dialogo dal momento in cui l'apparizione viene richiesta tramite un PUBLISH o dalla ricezione di un INVITE fino al momento in cui l'ultimo dialogo associato all'apparizione viene terminato, inclusi tutti i dialoghi che sono uniti o sostituiti. Durante lo stato di dialogo iniziale, l'agente di apparizione controlla la frequenza di pubblicazione dello stato del dialogo utilizzando il campo di intestazione Expires nelle risposte 200 (OK) alle richieste PUBLISH. Si RACCOMANDA un intervallo di 3 minuti. Dopo che il dialogo associato alla pubblicazione è stato confermato, la scadenza dello stato di pubblicazione non ha alcun effetto sull'allocazione dell'apparizione. Se la pubblicazione non contiene informazioni sullo stato del dialogo, l'agente di apparizione DEVE riservare il numero di apparizione per l'UA ma non può assegnare l'apparizione a un particolare dialogo dell'UA. Quando lo stato di pubblicazione viene aggiornato con qualsiasi informazione di dialogo, il numero di apparizione può quindi essere assegnato al particolare dialogo. Un UA a cui è stato allocato un numero di apparizione utilizzando un PUBLISH PUÒ liberare il numero di apparizione rimuovendo lo stato dell'evento con un PUBLISH come descritto in [RFC3903].

Se un INVITE viene inviato da un membro del gruppo all'AOR condivisa (cioè, chiamano la propria AOR), l'agente di apparizione DEVE assegnare due numeri di apparizione. Il primo numero di apparizione sarà quello selezionato o assegnato all'INVITE in uscita. Il secondo numero di apparizione sarà un altro assegnato dall'agente di apparizione per l'INVITE quando viene riforcato ai membri del gruppo.

Questo serve a preservare un comportamento comune nei sistemi legacy.

Se un INVITE viene inviato da un membro del gruppo utilizzando l'AOR condivisa o inviato all'AOR condivisa e non è disponibile alcun numero di apparizione, il proxy PUÒ rifiutare l'INVITE con un codice di risposta 403 (Forbidden).

I numeri di apparizione vengono utilizzati solo per i dialoghi in cui uno o più UA associati all'AOR del gruppo sono partecipanti. Se un INVITE in arrivo all'AOR del gruppo viene inoltrato a un'altra AOR, il numero di apparizione viene immediatamente liberato e può essere assegnato a un altro dialogo.