Implementazione del livello di trasporto per un UAC SIP

Question

Implementazione del livello di trasporto per un UAC SIP

#1 da (2 voti)
#2 da (0 voti)

1

Ho una domanda piuttosto semplice, ma specifica sull'implementazione del livello di trasporto per un UAC SIP.

Mi aspetto la risposta a una richiesta sullo stesso socket su cui ho inviato la richiesta, o faccio in modo che il listener UDP o TCP prenda la risposta e poi la instradi alla transazione corretta da lì? La RFC non sembra dire nulla in merito.

Sembra che specialmente usando UDP, che è senza connessione, dovrei solo lasciare che gli ascoltatori captino la risposta, ma sembra una sorta di contro intuitivo. In particolare, ho visto molte implementazioni UAC che non dipendono dall'avere un listener nel livello di trasporto.

Inoltre, la maggior parte delle implementazioni che ho visto non hanno il ciclo di ricezione UAS che risponde al socket. Ciò tende a indicare che il client non dovrebbe aspettarsi una risposta sul socket su cui ha inviato la richiesta.

Per chiarimenti:

Supponiamo che il mio livello di trasporto sia costituito dai seguenti elementi:

TCPClient (Sends Requests for a UAC via TCP)
UDPClient (Sends Requests for a UAC vid UDP)
TCPSever (Loop receiving Requests and dispatching to transaction layer via TCP)
UDPServer (Loop receiving Requests and dispatching to transaction layer via UDP)

Ovviamente, il * Client invia le mie richieste. La domanda è: cosa riceve la risposta? Il client * in attesa di una chiamata o di una chiamata recviva dal socket utilizzato per inviare la richiesta, o il * server?

Al contrario, il * Server riceve le mie richieste, Cosa invia la risposta? Il cliente? questo non spezza un po 'i ruoli di ogni membro?

Aggiorna Ho effettuato un'acquisizione di pacchetti su una transazione SIP Invite tra Ekiga e un server PolyCom. Ekiga era il cliente e Polycom era il server. Nella richiesta di invito Ekiga ha utilizzato la porta 5060 nell'intestazione via. 5060 è la porta su cui UAS sta ascoltando, quindi sembrerebbe indicare che l'UDPServer sta ricevendo le risposte a tutte le richieste e non all'UDPClient che ha inviato la richiesta. Questo ragionamento è valido?

design-patterns networking sockets sip

posta Jonathan Henson 15.11.2012 - 22:10

fonte

2 risposte

0

Quando ho fatto il mio sip stack, ho creato tutti i messaggi nel livello di trasporto e li ho passati al livello successivo che doveva identificare le transazioni corrette.

Anche in questo modo è più semplice testare.

risposta data 15.11.2012 - 22:18

fonte

Leggi altre domande sui tag design-patterns networking sockets sip

L'escaping fornito dalla libreria di Google-Gson è sufficiente per garantire un payload JSON sicuro? WCF una connessione Entity Framework

score 2 · Accepted Answer

Durante la lettura della sezione 18 di RFC3261 sul livello di trasporto, si afferma chiaramente che il livello di trasporto deve essere in grado di ricevere risposte per una transazione su ciascuno di

Il socket TCP utilizzato per inviare la richiesta ( TCPClient )
Una nuova connessione TCP all'indirizzo da cui è stata inviata la richiesta e il numero di porta come pubblicizzato nel campo "inviato" dell'intestazione "Via" ( TCPServer sull'invio dell'indirizzo IP)
Una nuova connessione TCP a cui UA sta normalmente ascoltando nuove transazioni ( TCPServer )
Un datagramma UDP sull'indirizzo da cui è stata inviata la richiesta e il numero di porta come pubblicizzato nel campo "inviato" dell'intestazione "Via" ( UDPServer sull'invio dell'indirizzo IP)
Un datagramma UDP in cui l'UA sta normalmente ascoltando nuove transazioni ( UDPServer )

Quindi, fondamentalmente solo UDPClient non può ricevere risposte.

Per quanto riguarda l'invio di risposte, quando la richiesta è arrivata su un trasporto affidabile (TCP), provare a utilizzare lo stesso socket per la risposta. Se ciò non è possibile, apri una nuova connessione come se invii un messaggio completamente nuovo. Questo dovrebbe dare meno sorprese.

Riguardo ai ruoli *Server e *Client : in genere, il client invia richieste e riceve risposte, mentre il server riceve richieste e invia risposte. Tuttavia, per UDP questo modello non funziona davvero. Ci si potrebbe andare per il modello che il cliente invia i datagrammi, mentre il server riceve i datagrammi (indipendentemente dal fatto che siano richieste o risposte).