SBC Fastweb

Netrunner.exe

Free User
Registrato
9 Gennaio 2024
Messaggi
3
Buongiorno,
ho un problema con un sbc fastweb in collaudo.
Mi hanno assegnato un numero provvisorio per i test, in uscita nessun problema in ingresso ricevo numero inesistente. Lato loro dicono sia tutto ok.

Configurando il DID sul mio gateway ricevo numero inesistente, se non configuro nessun DID la chiamata cade senza nessun avviso.
ip 10.10.1.4 è l'SBC
ip 172.16.51.10 è il mio gateway

Ricevo questo errore ad ogni tentativo di chiamata in ingresso:

<--- SIP read from UDP:10.10.1.4:5060 --->
INVITE sip:+390783*****@172.16.51.10:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.10.1.4:5060;branch=z9hG4bK3f8ltj10b8dpajcf6tf0.1
Call-ID: [email protected]
CSeq: 1 INVITE
To: <sip:+390783*****@172.16.51.10;lr;user=phone>
Content-Type: application/sdp
Max-Forwards: 58
Supported: 100rel
Allow: UPDATE,NOTIFY,ACK,SUBSCRIBE,INVITE,INFO,REFER,MESSAGE,CANCEL,PRACK,BYE,OPTIONS
Contact: <sip:392*****@10.10.1.4:5060;transport=udp>
From: <sip:392*****@10.10.1.4;user=phone>;tag=7150b724
Content-Length: 270

v=0
o=HPE-AS 58609 1 IN IP4 10.10.1.12
s=IMSS
c=IN IP4 10.10.1.12
t=0 0
a=sendrecv
m=audio 10014 RTP/AVP 18 101
b=RR:0
b=RS:0
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=maxptime:40
a=sqn:0
a=cdsc:1 image udptl t38
a=ptime:20

<------------->
--- (12 headers 16 lines) ---
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
== Using SIP VRTP TOS bits 136
== Using SIP VRTP CoS mark 4
== Using UDPTL TOS bits 184
== Using UDPTL CoS mark 5
Sending to 10.10.1.4 : 5060 (NAT)
Using INVITE request as basis request - [email protected]
[2024-01-09 10:19:57] NOTICE[1537]: chan_sip.c:15025 check_peer_ok: [YEASTARDNSMAP] Get peer by ip and toexten:+390783*****
Found peer 'trunk-sps-Unigate' for '392*****' from 10.10.1.4:5060
Found RTP audio format 18
Found RTP audio format 101
Found audio description format telephone-event for ID 101
Capabilities: us - 0x90e (gsm|ulaw|alaw|g726|g729), peer - audio=0x100 (g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 10.10.1.12:10014

Looking for +39078***** in DID_inbound_trunk-sps-Unigate (domain 172.16.51.10)

<--- Reliably Transmitting (NAT) to 10.10.1.4:5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.10.1.4:5060;branch=z9hG4bK3f8ltj10b8dpajcf6tf0.1;received=10.10.1.4
From: <sip:392*****@10.10.1.4;user=phone>;tag=7150b724
To: <sip:+390783*****@172.16.51.10;lr;user=phone>;tag=as6499b9a0
Call-ID: [email protected]
CSeq: 1 INVITE
Server: TE100
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0

[2024-01-09 10:19:57] NOTICE[1537]: chan_sip.c:21279 handle_request_invite: Call from 'trunk-sps-Unigate' to extension '+390783*****' rejected because extension not found.

Scheduling destruction of SIP dialog '[email protected]' in 6400 ms (Method: INVITE)

<--- SIP read from UDP:10.10.1.4:5060 --->
ACK sip:+390783*****@172.16.51.10:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.10.1.4:5060;branch=z9hG4bK3f8ltj10b8dpajcf6tf0.1
CSeq: 1 ACK
Call-ID: [email protected]
To: <sip:+390783*****[email protected];lr;user=phone>;tag=as6499b9a0
Max-Forwards: 58
From: <sip:392*****@10.10.1.4;user=phone>;tag=7150b724
Content-Length: 0

Grazie
 
Il DID come è configurato ?
 
Ciao Pier,
ho provato con +39xxxxxxx, poi solo xxxxxx, poi troncando lo 0 davanti, in ogni caso sento in risposta sempre "numero inesistente".
Se non inserisco DID ma imposto il pattern generico ( che con altri flussi funziona correttamente) X. la chiamata cade senza sentire nessun vocale.
 
Ciao, io ho fastweb business.
Ho avuto un problema molto simile.

La mia configurazione
Centralino 3cx on premise.
Modem fastweb business nel ced.
Ip privato di fastweb.
Centralino con ip locale al modem.

Configurazione trunk
L'unica configurazione funzionante ha il DID principale con il +39
Mi sono accorto del DID con il quale si presentava fastweb usando wireshark e sniffando il traffico sip.
Ho poi riportato il numero esattamento come si presentava nel traffico sip e ha iniziato a funzionare.
Il trunk su 3cx sul centralino, risultava per me comunque in stato down.
Eppure funzionava tutto perfettamente.

Hai poi risolto ?
 
Si, risolto. Era un problema del provider, confermo che passa con il +39.
ciao
 

Inizia con 3CX – Admin

Forum statistics

Discussioni
44.332
Messaggi
232.474
Membri
78.281
Ultimo Iscritto
Aguabuena