Salute a tutti,
Sto affrontando ormai da qualche giorno un problema che sembra essere senza soluzine, mi chiedo se qualcun altro oltre me ha mai avuto a che fare con questo genere di fastidi.
Di seguito l'architettura in cui si presenta il problema.
[Telefono]-->[CME]-->[NAT c837]--->[messagenet]-->[ATA]
Succede che quando chiamo dal telefono --> l'ATA vedo solo il flusso RTP uscente dal mio CME, quindi nessun flusso di ritorno.
Debuggando ulteriormente ho trovato la seguente a mio avviso stranezza, ed è nell' interpretazione di questo fenomeno che avrei bisogno di aiuto.
L'INVITE uscente dal mio cme è il segunete
INVITE sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP 10.xxx.xxx.xxx:1030;branch=z9hG4bK1FA18DD
Remote-Party-ID: "202" <sip:[email protected]:1030>;party=calling;screen=no;privacy=off
From: "202" <sip:[email protected]>;tag=EFD66C-1C4D
To: <sip:[email protected]>
Date: Mon, 02 Mar 2009 22:12:18 GMT
Call-ID: [email protected]
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 120141183-112071134-2153681569-1022927555
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1236031938
Contact: <sip:[email protected]:1030>
Expires: 60
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: xxx
v=0
o=CiscoSystemsSIP-GW-UserAgent 4925 2870 IN IP4 10.xxx.xxx.xxx
s=SIP Call
c=IN IP4 10.xxx.xxx.xxx
t=0 0
m=audio 18308 RTP/AVP 18 19
c=IN IP4 10.xxx.xxx.xxx
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:19 CN/8000
a=ptime:20
la nat box IOS (ip nat service sip udp port 5061) lo trasforma in
INVITE sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP 62.xxx.xxx.xxx:1030;branch=z9hG4bK1FA18DD
Remote-Party-ID: "202" <sip:[email protected]:1030>;party=calling;screen=no;privacy=off
From: "202" <sip:[email protected]>;tag=EFD66C-1C4D
To: <sip:[email protected]>
Date: Mon, 02 Mar 2009 22:12:18 GMT
Call-ID: [email protected]
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 120141183-112071134-2153681569-1022927555
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1236031938
Contact: <sip:[email protected]:1030>
Expires: 60
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: xxx
v=0
o=CiscoSystemsSIP-GW-UserAgent 4925 2870 IN IP4 10.xxx.xxx.xxx
s=SIP Call
c=IN IP4 10.xxx.xxx.xxx
t=0 0
m=audio 18308 RTP/AVP 18 19
c=IN IP4 62.xxx.xxx.xxx
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:19 CN/8000
a=ptime:20
Ora, anche se ho cancellato parte degli indirizzi IP, le mie perplessità rimangono e sono comunque leggibili; nel message body SDP, ci sono due linee "c=" (contact information), il che sembra compatibile con quanto affermato dall'RFC 2327, tutti gli invite che ho visto ad eccezione di questo ne hanno uno solo, generalmente il primo quello del Session description.
Mi chiedo quindi perché cme abbia questo comportamento dissimile dagli altri sip proxy.
Escludendo però questo problema, che potrebbe sembrare ai più solo accademico, il fatto è che alla fine la telefonata non funziona, dalla parte CME si vede solo il flusso uscente senza alcuna traccia del ritorno.
L'ATA, da parte sua, cerca di aprire un flusso RTP cn l'indirizzo privato 10.xxx.xxx.xxx e non con l'indirizzo pubblico 62.xxx.xxx.xxx mostrando qunindi che utilizza i dati della prima linea "c=", quella che la nat box IOS non ha cambiato.
Avendo bisogno di risolvere questo problema, mi chiedo quindi se c'è un modo di forzare CME a produrre INVITE con un solo "c=" nel message body SDP, o in alternativa convincere la nat box IOS a cambiare tutti le linee "c=" che ci sono nel message body SDP e non solo quella del Media description.
Ringrazio in anticipo chiunque possa aiutarmi.
Doppia "contact information" nel message body SDP
Moderatore: Federico.Lagni
-
ep
- Network Emperor
- Messaggi: 260
- Iscritto il: sab 06 dic , 2008 11:36 am
Mi sembra una bella analisi, bravo!
Hai provato a seguire la terza via, e cioè lasciare SOLO l'IP privato chiedendo all'837 di non mettere le mani nei pacchetti SIP, sperando che i server di Messagenet facciano tutto da soli? (configurazione: "no ip nat service sip udp port 5060")
Ciao!
Hai provato a seguire la terza via, e cioè lasciare SOLO l'IP privato chiedendo all'837 di non mettere le mani nei pacchetti SIP, sperando che i server di Messagenet facciano tutto da soli? (configurazione: "no ip nat service sip udp port 5060")
Ciao!
-
lilloxy
- n00b
- Messaggi: 14
- Iscritto il: lun 02 mar , 2009 11:49 pm
Grazie per la pronta risposta, in effetti le soluzioni più semplici spesso non vengono neanche considerate... Come in effetti è accaduto in questo caso.
In effetti però, neanche questa sembra funzionare, ed i sintomi del fenomeno sono esattamente gli stessi che avevo quando facevo nat di SIP sul router amministrato da me. Non ho ancora verificatolato lato ATA ma accade, come nel caso precedente, che il flusso generato dall' ATA non arriva, non sul mio border router, e con una buona approssimazione, neanche sui server di Messagenet. Il problema quindi deve essere necessariamente la doppia riga "connection information" nel message body SDP generato da CME che non vengono processate in maniera corretta dagli ALG NAT. Messagenet utilizza OpenSer il quale ho letto da qualche parte preveda addirittura un modulo software per il Nat Traversal dei pacchetti sip generati da gateway sip Cisco. C'è qualcuno che ha una qualche idea su come forzare CME a generare INVITE sip con un solo "connection information" ?
Grazie.
In effetti però, neanche questa sembra funzionare, ed i sintomi del fenomeno sono esattamente gli stessi che avevo quando facevo nat di SIP sul router amministrato da me. Non ho ancora verificatolato lato ATA ma accade, come nel caso precedente, che il flusso generato dall' ATA non arriva, non sul mio border router, e con una buona approssimazione, neanche sui server di Messagenet. Il problema quindi deve essere necessariamente la doppia riga "connection information" nel message body SDP generato da CME che non vengono processate in maniera corretta dagli ALG NAT. Messagenet utilizza OpenSer il quale ho letto da qualche parte preveda addirittura un modulo software per il Nat Traversal dei pacchetti sip generati da gateway sip Cisco. C'è qualcuno che ha una qualche idea su come forzare CME a generare INVITE sip con un solo "connection information" ?
Grazie.
Alessandro
-
lilloxy
- n00b
- Messaggi: 14
- Iscritto il: lun 02 mar , 2009 11:49 pm
Per chiunque abbia il mio stesso problema.
Dopo varie, ulteriori ricerche, sono arrivato alla conclusione che il problema sia da ricercare nell'ATA.
Nell'RFC 2327 è scritta chiaramente la possibilità della presenza di due linee "contact information" e mostra anche che sia il comportamento di CME, che le mette entrambe, sia quell nella nat box che ne "processa" solo una, sono corretti.
Per completezza riporto la parte dell'RFC che descrive questa caratteristica.
"A session announcement must contain one "c=" field in each media description or a "c=" field at the session-level. It may contain a session-level "c=" field and one additional "c=" field per media description, in which case the per-media values override the session-level settings for the relevant media."
Inoltre, sempre per completezza, riporto la marca ed il modello dell'ATA che soffre questo fastidio:
Sagem ATA 101S. Attualmente non so dire quale sia il numero di revisione del firmware, di cui comunque ne esiste una versione aggiornata. Quando riuscrò a cambiare la revisione, l'ATA in questione non è in mio possesso, ne riporterò sul forum l'esito.
Grazie per l'assistenza.
Dopo varie, ulteriori ricerche, sono arrivato alla conclusione che il problema sia da ricercare nell'ATA.
Nell'RFC 2327 è scritta chiaramente la possibilità della presenza di due linee "contact information" e mostra anche che sia il comportamento di CME, che le mette entrambe, sia quell nella nat box che ne "processa" solo una, sono corretti.
Per completezza riporto la parte dell'RFC che descrive questa caratteristica.
"A session announcement must contain one "c=" field in each media description or a "c=" field at the session-level. It may contain a session-level "c=" field and one additional "c=" field per media description, in which case the per-media values override the session-level settings for the relevant media."
Inoltre, sempre per completezza, riporto la marca ed il modello dell'ATA che soffre questo fastidio:
Sagem ATA 101S. Attualmente non so dire quale sia il numero di revisione del firmware, di cui comunque ne esiste una versione aggiornata. Quando riuscrò a cambiare la revisione, l'ATA in questione non è in mio possesso, ne riporterò sul forum l'esito.
Grazie per l'assistenza.
Alessandro
