La Fibre
Datacenter et équipements réseaux => Routeurs => 
Téléphonie VoIP / SIP => Discussion démarrée par: artemus24 le 14 août 2023 à 12:54:25
-
Salut à tous.
J'ai installé Asterisk dans mon Debian 11 version Bullseye. J'ai pris la dernière version d'Asterisk en date, la 20.4.0.
J'ai suivi ce didacticiel (https://computingforgeeks.com/install-asterisk-lts-on-debian-linux/?expand_article=1) pour installer Asterisk. Ainsi que celui-ci (https://leblogdolivyeahh.wordpress.com/2020/08/05/debian-10-voip-voix-sur-ip-partie-1-installation-dasterisk/) qui est en deux parties.
a) à la place de "sudo ./configure", j'ai fait cela "sudo ./configure --with-jansson-bundled".
b) dans le service "asterisk", un message d'anomalie concernant "radius" a été résolu avec ces explications là (https://www.nme.one/blog/ubuntu-20-04-asterisk-16-cant-open-etc-radiusclient-ng-radiusclient-conf-error-radcli-rc_read_config-rc_read_config-cant-open/).
A priori, aucune grand difficulté pour l'installation d'Asterisk version 20.4.0. Le service Asterisk est opérationnel et j'ai pu entrer dans la console Asterisk. Donc tout est ok !
Là où j'ai eu plus de difficulté, c'est de paramétrer Asterisk avec les identifiants de ma ligne téléphonique SFR. Il faut savoir que les différentes versions d'Asterisk ne sont pas toujours compatibles entre elles. Ce qui m'a fait perdre beaucoup de temps, j'ai cru que je devais, comme dans les exemples trouvés dans ce forum, travaillé sur les fichiers "sip.conf", "extensions.conf" et "users.conf". Que nenni ! Il faut maintenant travailler sur "pjsip.conf" et "extensions.conf". Après l'installation, on trouve ces fichiers dans le répertoire "/ext/asterisk".
Voici mon "pjsip.conf" :
[registration]
auth_rejection_permanent=yes
[transport-udp-nat]
bind=0.0.0.0
external_media_address=xxx.xxx.xxx.xxx ; c'est mon adresse IPv4 WAN ou Publique.
external_signaling_address=xxx.xxx.xxx.xxx ; c'est mon adresse IPv4 WAN ou Publique.
local_net=192.168.1.0/24 ; c'est l'adresse de mon réseau local.
protocol=udp
type=transport
; --------- ;
; Trunk SFR ;
; --------- ;
[sfr]
contact=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
type=aor
[sfr]
password=XXXXXXXXXXXXXXXX ; Password dans l'application de NextGens
username=NDIXXXXXXXXXX.XXX.XXX@sfr.fr ; Username dans l'application de NextGens
type=auth
[sfr]
allow=!all,opus,speex,g722,alaw,ulaw,gsm
aors=sfr
context=incoming
from_domain=ims.mnc010.mcc208.3gppnetwork.org
from_user=+33XXXXXXXXX ; Display Name dans l'application de NextGens
outbound_auth=sfr
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
transport=transport-udp-nat
type=endpoint
[sfr]
endpoint=sfr
match=residential.p-cscf.sfr.net
type=identify
[sfr]
client_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org ; Display Name @ Domain dans l'application de NextGens
outbound_auth=sfr
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
server_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org ; Display Name @ Domain dans l'application de NextGens
transport=transport-udp-nat
type=registration
; --------- ;
; Templates ;
; --------- ;
[aor_dynamic](!)
max_contacts=1
remove_existing=yes
type=aor
[auth_userpass](!)
type=auth
auth_type=userpass
[endpoint_internal](!)
allow=!all,alaw
context=outgoing
from_domain=ims.mnc010.mcc208.3gppnetwork.org ; Domain dans l'application de NextGens
language=fr
type=endpoint
; ---------- ;
; Phone Line ;
; ---------- ;
[artemus](aor_dynamic)
[artemus](auth_userpass)
password=artemus
username=artemus
[artemus](endpoint_internal)
auth=artemus
aors=artemusEt voici le fichier "extensions.conf" :
[general]
autofallthrough=yes
clearglobalvars=no
priorityjumping=no
static=yes
writeprotect=no
[globals]
CONSOLE=Console/dsp
IAXINFO=guest
TRUNK=DAHDI/G2
TRUNKMSD=1
[outgoing]
exten => _0[12345679]XXXXXXXX,1,Dial(PJSIP/${EXTEN}@sfr)
exten => _+33[12345679]XXXXXXXX,1,Dial(PJSIP/${EXTEN}@sfr)
exten => _1023,1,Dial(PJSIP/${EXTEN}@sfr)
[incoming]
exten => s,1,Dial(PJSIP/artemus)Ces deux fichiers de configurations sont opérationnels, mais ils ne sont pas définitifs. Je teste sur le SoftPhone Zoiper5 au travers du numéro de téléphone du Service Client SFR : 1023.
Après chaque modification des fichiers, il faut relancer le service Asterisk :
systemctl restart asterisk.service
systemctl status asterisk.servicePour configurer Zoiper5, j'ai mis :
Première page :
--> artemus (c'est l'identifiant de mon poste téléphone)
--> artemus (c'est mon mot de passe)
Deuxième page
--> 192.168.1.11 (c'est l'adresse IPv4 dans mon réseau LAN où se trouve le serveur Asterisk).
Si tout ce passe bien, vous obtiendrez "UDP SIP : succès en vert".
Je vais dans la console asterisk :
asterisk -rvvvPuis sous Zoiper5, je tape le numéro 1023, celui du service client SFR. Voici le compte-rendu :
Running as user 'asterisk'
Running under group 'asterisk'
Connected to Asterisk 20.4.0 currently running on Debian (pid = 38311)
Debian*CLI>
-- Executing [1023@outgoing:1] Dial("PJSIP/artemus-00000000", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
> 0x7f3338052b70 -- Strict RTP learning after remote address set to: 92.91.230.104:5892
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/artemus-00000000
> 0x7f333801bda0 -- Strict RTP learning after remote address set to: 192.168.1.11:40829
> 0x7f333801bda0 -- Strict RTP switching to RTP target address 192.168.1.11:40829 as source
> 0x7f3338052b70 -- Strict RTP switching to RTP target address 92.91.230.104:5892 as source
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/artemus-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/artemus-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/artemus-00000000
> 0x7f3338052b70 -- Strict RTP learning complete - Locking on source address 92.91.230.104:5892
> 0x7f333801bda0 -- Strict RTP learning complete - Locking on source address 192.168.1.11:40829
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/artemus-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/artemus-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/artemus-00000000
== Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/artemus-00000000' status is 'CHANUNAVAIL'
Debian*CLI> Pour ce test, mon Asus sous Debian est relié à la Box SFR. Je me retrouve déconnecté au bout des 32 secondes comme pour les tests précédents.
Nous avons une précision sur la nature de cette déconnexion : "CHANUNAVAIL".
J'en suis là pour l'instant. comme qui dirait, la suite au prochain épisode.
Cordialement.
Artemus24.
@+
-
Comme j'ai modifié mes fichiers, je les remets :
pjsip.conf :
[transport-udp-nat]
bind=0.0.0.0
external_media_address=XXX.XXX.XXX.XXX
external_signaling_address=XXX.XXX.XXX.XXX
local_net=192.168.1.0/255.255.255.0
protocol=udp
type=transport
; --------- ;
; Templates ;
; --------- ;
[my_codecs](!)
disallow=all
allow=alaw
allow=ulaw
allow=gsm
[aor_dynamic](!)
max_contacts=1
remove_existing=yes
type=aor
[auth_userpass](!)
auth_type=userpass
type=auth
[endpoint_internal](!,my_codecs)
context=outgoing
from_domain=ims.mnc010.mcc208.3gppnetwork.org
language=fr
type=endpoint
; --------- ;
; Trunk SFR ;
; --------- ;
[sfr]
contact=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
type=aor
[sfr]
auth_type=userpass
password=XXXXXXXXXXXXXXXX
;;realm=
username=NDIXXXXXXXXXX.XXX.XXX@sfr.fr
type=auth
[sfr](my_codecs)
100rel=required
aors=sfr
context=incoming
from_domain=ims.mnc010.mcc208.3gppnetwork.org
from_user=+33XXXXXXXXX
outbound_auth=sfr
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
transport=transport-udp-nat
type=endpoint
[sfr]
endpoint=sfr
match=residential.p-cscf.sfr.net
type=identify
[sfr]
client_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_auth=sfr
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
server_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
transport=transport-udp-nat
type=registration
; ------------------- ;
; Phone Line 'Zoiper' ;
; ------------------- ;
[zoiper](aor_dynamic)
[zoiper](auth_userpass)
password=zoiper
username=zoiper
[zoiper](endpoint_internal)
auth=zoiper
aors=zoiper
callerid=zoiper
extensions.conf :
[general]
autofallthrough=yes
clearglobalvars=no
priorityjumping=no
static=yes
writeprotect=no
[globals]
CONSOLE=Console/dsp
IAXINFO=guest
TRUNK=DAHDI/G2
TRUNKMSD=1
[outgoing]
exten => _X.,1,Dial(PJSIP/${EXTEN}@sfr)
exten => _X.,n,Hangup()
[incoming]
exten => s,1,Dial(PJSIP/zoiper)
Ci-après une trace de la communication quand je fais le 1023 (Service Client SFR).
-
<--- Received SIP request (1326 bytes) from UDP:192.168.1.11:45764 --->
INVITE sip:1023@192.168.1.11;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.11:45764;branch=z9hG4bK-524287-1---d7966bbe8cd328a8;rport
Max-Forwards: 70
Contact: <sip:zoiper@192.168.1.11:45764;transport=UDP>
To: <sip:1023@192.168.1.11>
From: <sip:zoiper@192.168.1.11;transport=UDP>;tag=09f12e30
Call-ID: gAgscy15debma_BfUc6IkA..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, timer, sec-agree, outbound, path, X-cisco-serviceuri
User-Agent: Z 5.6.1 v2.10.19.9
Allow-Events: presence, kpml, talk, as-feature-event
Content-Length: 648
v=0
o=Z 0 21282916 IN IP4 192.168.1.11
s=Z
c=IN IP4 192.168.1.11
t=0 0
m=audio 55552 RTP/AVP 106 9 98 101 0 8 3
a=rtpmap:106 opus/48000/2
a=fmtp:106 sprop-maxcapturerate=16000; minptime=20; useinbandfec=1
a=rtpmap:98 telephone-event/48000
a=fmtp:98 0-16
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp-mux
m=audio 55552 RTP/AVPF 106 9 98 101 0 8 3
a=rtpmap:106 opus/48000/2
a=fmtp:106 sprop-maxcapturerate=16000; minptime=20; useinbandfec=1
a=rtpmap:98 telephone-event/48000
a=fmtp:98 0-16
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp-mux
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
<--- Transmitting SIP response (503 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---d7966bbe8cd328a8
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=z9hG4bK-524287-1---d7966bbe8cd328a8
CSeq: 1 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1692195895/bbd695058ecfe00e7ab5b81396661e4d",opaque="2ff404522100a4b3",algorithm=MD5,qop="auth"
Server: Asterisk PBX 20.4.0
Content-Length: 0
<--- Received SIP request (351 bytes) from UDP:192.168.1.11:45764 --->
ACK sip:1023@192.168.1.11;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.11:45764;branch=z9hG4bK-524287-1---d7966bbe8cd328a8;rport
Max-Forwards: 70
To: <sip:1023@192.168.1.11>;tag=z9hG4bK-524287-1---d7966bbe8cd328a8
From: <sip:zoiper@192.168.1.11;transport=UDP>;tag=09f12e30
Call-ID: gAgscy15debma_BfUc6IkA..
CSeq: 1 ACK
Content-Length: 0
<--- Received SIP request (1625 bytes) from UDP:192.168.1.11:45764 --->
INVITE sip:1023@192.168.1.11;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.11:45764;branch=z9hG4bK-524287-1---04203c58a61ade96;rport
Max-Forwards: 70
Contact: <sip:zoiper@192.168.1.11:45764;transport=UDP>
To: <sip:1023@192.168.1.11>
From: <sip:zoiper@192.168.1.11;transport=UDP>;tag=09f12e30
Call-ID: gAgscy15debma_BfUc6IkA..
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, timer, sec-agree, outbound, path, X-cisco-serviceuri
User-Agent: Z 5.6.1 v2.10.19.9
Authorization: Digest username="zoiper",realm="asterisk",nonce="1692195895/bbd695058ecfe00e7ab5b81396661e4d",uri="sip:1023@192.168.1.11;transport=UDP",response="9762d077578025d8447848e8f74b6156",cnonce="351f64212bb6fb16a306be607aef2657",nc=00000001,qop=auth,algorithm=MD5,opaque="2ff404522100a4b3"
Allow-Events: presence, kpml, talk, as-feature-event
Content-Length: 648
v=0
o=Z 0 21282916 IN IP4 192.168.1.11
s=Z
c=IN IP4 192.168.1.11
t=0 0
m=audio 55552 RTP/AVP 106 9 98 101 0 8 3
a=rtpmap:106 opus/48000/2
a=fmtp:106 sprop-maxcapturerate=16000; minptime=20; useinbandfec=1
a=rtpmap:98 telephone-event/48000
a=fmtp:98 0-16
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp-mux
m=audio 55552 RTP/AVPF 106 9 98 101 0 8 3
a=rtpmap:106 opus/48000/2
a=fmtp:106 sprop-maxcapturerate=16000; minptime=20; useinbandfec=1
a=rtpmap:98 telephone-event/48000
a=fmtp:98 0-16
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp-mux
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
<--- Transmitting SIP response (311 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Content-Length: 0
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000012", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
<--- Transmitting SIP request (1069 bytes) to UDP:92.91.129.200:5062 --->
INVITE sip:1023@ims.mnc010.mcc208.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org>
Contact: <sip:+33XXXXXXXXX@XXX.XXX.XXX.XXX:5060>
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
CSeq: 23228 INVITE
Route: <sip:residential.p-cscf.sfr.net;lr>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Require: 100rel
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 20.4.0
Content-Type: application/sdp
Content-Length: 280
v=0
o=- 383691559 383691559 IN IP4 XXX.XXX.XXX.XXX
s=Asterisk
c=IN IP4 XXX.XXX.XXX.XXX
t=0 0
m=audio 17854 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
<--- Received SIP response (438 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 100 Trying
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Date: Wed, 16 Aug 2023 14:24:55 GMT
Content-Length: 0
<--- Received SIP response (942 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 183 Session Progress
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Require: 100rel
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062;x-afi=105>
Content-Type: application/sdp
RSeq: 1
Content-Length: 235
v=0
o=LucentPCSF 1631970971 1631970971 IN IP4 imsgroup-019.tng1asbc05.ims.sfr.net
s=-
c=IN IP4 92.91.230.139
t=0 0
m=audio 35412 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
-- PJSIP/sfr-00000013 is making progress passing it to PJSIP/zoiper-00000012
<--- Transmitting SIP response (853 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Contact: <sip:192.168.1.11:5060>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 21282918 IN IP4 192.168.1.11
s=Asterisk
c=IN IP4 192.168.1.11
t=0 0
m=audio 10890 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=audio 0 RTP/AVPF 106 9 98 101 0 8 3
<--- Received SIP response (942 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 183 Session Progress
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Require: 100rel
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062;x-afi=105>
Content-Type: application/sdp
RSeq: 1
Content-Length: 235
v=0
o=LucentPCSF 1631970971 1631970971 IN IP4 imsgroup-019.tng1asbc05.ims.sfr.net
s=-
c=IN IP4 92.91.230.139
t=0 0
m=audio 35412 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
-- PJSIP/sfr-00000013 is making progress passing it to PJSIP/zoiper-00000012
<--- Transmitting SIP response (853 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: <sip:192.168.1.11:5060>
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 21282918 IN IP4 192.168.1.11
s=Asterisk
c=IN IP4 192.168.1.11
t=0 0
m=audio 10890 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=audio 0 RTP/AVPF 106 9 98 101 0 8 3
<--- Received SIP request (996 bytes) from UDP:192.168.1.11:45764 --->
REGISTER sip:192.168.1.11;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.11:45764;branch=z9hG4bK-524287-1---4f3e6e84ffcc40d2;rport
Max-Forwards: 70
Contact: <sip:zoiper@192.168.1.11:45764;rinstance=f8e4393d973ab382;transport=UDP>
To: <sip:zoiper@192.168.1.11;transport=UDP>
From: <sip:zoiper@192.168.1.11;transport=UDP>;tag=33da4d23
Call-ID: zH8FcrvsjHUcCYm3Sttw-Q..
CSeq: 257 REGISTER
Expires: 60
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, sec-agree, outbound, path, X-cisco-serviceuri
User-Agent: Z 5.6.1 v2.10.19.9
Authorization: Digest username="zoiper",realm="asterisk",nonce="1692195844/0ca0c31768bd2aa28614f20860933e24",uri="sip:192.168.1.11;transport=UDP",response="528a3430532bcbd39c7b9edc544a6dfe",cnonce="4e56f59af27e3276bf972f8c2dc36a9a",nc=00000002,qop=auth,algorithm=MD5,opaque="0b92ddfe333bcc7f"
Allow-Events: presence, kpml, talk, as-feature-event
Content-Length: 0
<--- Transmitting SIP response (520 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---4f3e6e84ffcc40d2
Call-ID: zH8FcrvsjHUcCYm3Sttw-Q..
From: <sip:zoiper@192.168.1.11>;tag=33da4d23
To: <sip:zoiper@192.168.1.11>;tag=z9hG4bK-524287-1---4f3e6e84ffcc40d2
CSeq: 257 REGISTER
WWW-Authenticate: Digest realm="asterisk",nonce="1692195897/7a10e537cd5ed26aee104daea63071b1",opaque="37a560c9336e38b8",stale=true,algorithm=MD5,qop="auth"
Server: Asterisk PBX 20.4.0
Content-Length: 0
<--- Received SIP request (996 bytes) from UDP:192.168.1.11:45764 --->
REGISTER sip:192.168.1.11;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.11:45764;branch=z9hG4bK-524287-1---a1331db20e6fd74d;rport
Max-Forwards: 70
Contact: <sip:zoiper@192.168.1.11:45764;rinstance=f8e4393d973ab382;transport=UDP>
To: <sip:zoiper@192.168.1.11;transport=UDP>
From: <sip:zoiper@192.168.1.11;transport=UDP>;tag=33da4d23
Call-ID: zH8FcrvsjHUcCYm3Sttw-Q..
CSeq: 258 REGISTER
Expires: 60
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, sec-agree, outbound, path, X-cisco-serviceuri
User-Agent: Z 5.6.1 v2.10.19.9
Authorization: Digest username="zoiper",realm="asterisk",nonce="1692195897/7a10e537cd5ed26aee104daea63071b1",uri="sip:192.168.1.11;transport=UDP",response="3d5c2255078eed076b0c55931d63dfc1",cnonce="ff58e7a21bee38056d2a7a26faaab112",nc=00000001,qop=auth,algorithm=MD5,opaque="37a560c9336e38b8"
Allow-Events: presence, kpml, talk, as-feature-event
Content-Length: 0
<--- Transmitting SIP response (497 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---a1331db20e6fd74d
Call-ID: zH8FcrvsjHUcCYm3Sttw-Q..
From: <sip:zoiper@192.168.1.11>;tag=33da4d23
To: <sip:zoiper@192.168.1.11>;tag=z9hG4bK-524287-1---a1331db20e6fd74d
CSeq: 258 REGISTER
Date: Wed, 16 Aug 2023 14:24:57 GMT
Contact: <sip:zoiper@192.168.1.11:45764;transport=UDP;rinstance=f8e4393d973ab382>;expires=59
Expires: 60
Server: Asterisk PBX 20.4.0
Content-Length: 0
<--- Received SIP response (942 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 183 Session Progress
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Require: 100rel
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062;x-afi=105>
Content-Type: application/sdp
RSeq: 1
Content-Length: 235
v=0
o=LucentPCSF 1631970971 1631970971 IN IP4 imsgroup-019.tng1asbc05.ims.sfr.net
s=-
c=IN IP4 92.91.230.139
t=0 0
m=audio 35412 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
-- PJSIP/sfr-00000013 is making progress passing it to PJSIP/zoiper-00000012
-
Comme cela dépasse les 20 000 caractères, voici la fin de ce debug :
<--- Transmitting SIP response (853 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: <sip:192.168.1.11:5060>
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 21282918 IN IP4 192.168.1.11
s=Asterisk
c=IN IP4 192.168.1.11
t=0 0
m=audio 10890 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=audio 0 RTP/AVPF 106 9 98 101 0 8 3
<--- Received SIP response (942 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 183 Session Progress
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Require: 100rel
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062;x-afi=105>
Content-Type: application/sdp
RSeq: 1
Content-Length: 235
v=0
o=LucentPCSF 1631970971 1631970971 IN IP4 imsgroup-019.tng1asbc05.ims.sfr.net
s=-
c=IN IP4 92.91.230.139
t=0 0
m=audio 35412 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
-- PJSIP/sfr-00000013 is making progress passing it to PJSIP/zoiper-00000012
<--- Transmitting SIP response (853 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: <sip:192.168.1.11:5060>
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 21282918 IN IP4 192.168.1.11
s=Asterisk
c=IN IP4 192.168.1.11
t=0 0
m=audio 10890 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=audio 0 RTP/AVPF 106 9 98 101 0 8 3
<--- Received SIP response (942 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 183 Session Progress
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Require: 100rel
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062;x-afi=105>
Content-Type: application/sdp
RSeq: 1
Content-Length: 235
v=0
o=LucentPCSF 1631970971 1631970971 IN IP4 imsgroup-019.tng1asbc05.ims.sfr.net
s=-
c=IN IP4 92.91.230.139
t=0 0
m=audio 35412 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
-- PJSIP/sfr-00000013 is making progress passing it to PJSIP/zoiper-00000012
<--- Transmitting SIP response (853 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: <sip:192.168.1.11:5060>
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 21282918 IN IP4 192.168.1.11
s=Asterisk
c=IN IP4 192.168.1.11
t=0 0
m=audio 10890 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=audio 0 RTP/AVPF 106 9 98 101 0 8 3
<--- Received SIP response (942 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 183 Session Progress
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Require: 100rel
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062;x-afi=105>
Content-Type: application/sdp
RSeq: 1
Content-Length: 235
v=0
o=LucentPCSF 1631970971 1631970971 IN IP4 imsgroup-019.tng1asbc05.ims.sfr.net
s=-
c=IN IP4 92.91.230.139
t=0 0
m=audio 35412 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
-- PJSIP/sfr-00000013 is making progress passing it to PJSIP/zoiper-00000012
<--- Transmitting SIP response (853 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: <sip:192.168.1.11:5060>
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 21282918 IN IP4 192.168.1.11
s=Asterisk
c=IN IP4 192.168.1.11
t=0 0
m=audio 10890 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=audio 0 RTP/AVPF 106 9 98 101 0 8 3
<--- Received SIP response (942 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 183 Session Progress
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Require: 100rel
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062;x-afi=105>
Content-Type: application/sdp
RSeq: 1
Content-Length: 235
v=0
o=LucentPCSF 1631970971 1631970971 IN IP4 imsgroup-019.tng1asbc05.ims.sfr.net
s=-
c=IN IP4 92.91.230.139
t=0 0
m=audio 35412 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
-- PJSIP/sfr-00000013 is making progress passing it to PJSIP/zoiper-00000012
<--- Transmitting SIP response (853 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: <sip:192.168.1.11:5060>
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 21282918 IN IP4 192.168.1.11
s=Asterisk
c=IN IP4 192.168.1.11
t=0 0
m=audio 10890 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=audio 0 RTP/AVPF 106 9 98 101 0 8 3
<--- Received SIP request (996 bytes) from UDP:192.168.1.11:45764 --->
REGISTER sip:192.168.1.11;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.11:45764;branch=z9hG4bK-524287-1---daa603d1c87afe64;rport
Max-Forwards: 70
Contact: <sip:zoiper@192.168.1.11:45764;rinstance=f8e4393d973ab382;transport=UDP>
To: <sip:zoiper@192.168.1.11;transport=UDP>
From: <sip:zoiper@192.168.1.11;transport=UDP>;tag=33da4d23
Call-ID: zH8FcrvsjHUcCYm3Sttw-Q..
CSeq: 259 REGISTER
Expires: 60
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, sec-agree, outbound, path, X-cisco-serviceuri
User-Agent: Z 5.6.1 v2.10.19.9
Authorization: Digest username="zoiper",realm="asterisk",nonce="1692195897/7a10e537cd5ed26aee104daea63071b1",uri="sip:192.168.1.11;transport=UDP",response="60f88bf2676c226bf9060fe16caedb96",cnonce="74c7ab030d1b219f1954d0225e631369",nc=00000002,qop=auth,algorithm=MD5,opaque="37a560c9336e38b8"
Allow-Events: presence, kpml, talk, as-feature-event
Content-Length: 0
<--- Transmitting SIP response (520 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---daa603d1c87afe64
Call-ID: zH8FcrvsjHUcCYm3Sttw-Q..
From: <sip:zoiper@192.168.1.11>;tag=33da4d23
To: <sip:zoiper@192.168.1.11>;tag=z9hG4bK-524287-1---daa603d1c87afe64
CSeq: 259 REGISTER
WWW-Authenticate: Digest realm="asterisk",nonce="1692195950/6b3cf4806e6db0313a5b8090d332b0db",opaque="06af3be96e764dc7",stale=true,algorithm=MD5,qop="auth"
Server: Asterisk PBX 20.4.0
Content-Length: 0
<--- Received SIP request (996 bytes) from UDP:192.168.1.11:45764 --->
REGISTER sip:192.168.1.11;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.11:45764;branch=z9hG4bK-524287-1---f0a5c617e4e39de6;rport
Max-Forwards: 70
Contact: <sip:zoiper@192.168.1.11:45764;rinstance=f8e4393d973ab382;transport=UDP>
To: <sip:zoiper@192.168.1.11;transport=UDP>
From: <sip:zoiper@192.168.1.11;transport=UDP>;tag=33da4d23
Call-ID: zH8FcrvsjHUcCYm3Sttw-Q..
CSeq: 260 REGISTER
Expires: 60
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, sec-agree, outbound, path, X-cisco-serviceuri
User-Agent: Z 5.6.1 v2.10.19.9
Authorization: Digest username="zoiper",realm="asterisk",nonce="1692195950/6b3cf4806e6db0313a5b8090d332b0db",uri="sip:192.168.1.11;transport=UDP",response="91465edc3410cf256308ff8c5748fe90",cnonce="b949d3427ee6322476338aaa28b1d990",nc=00000001,qop=auth,algorithm=MD5,opaque="06af3be96e764dc7"
Allow-Events: presence, kpml, talk, as-feature-event
Content-Length: 0
<--- Transmitting SIP response (497 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---f0a5c617e4e39de6
Call-ID: zH8FcrvsjHUcCYm3Sttw-Q..
From: <sip:zoiper@192.168.1.11>;tag=33da4d23
To: <sip:zoiper@192.168.1.11>;tag=z9hG4bK-524287-1---f0a5c617e4e39de6
CSeq: 260 REGISTER
Date: Wed, 16 Aug 2023 14:25:50 GMT
Contact: <sip:zoiper@192.168.1.11:45764;transport=UDP;rinstance=f8e4393d973ab382>;expires=59
Expires: 60
Server: Asterisk PBX 20.4.0
Content-Length: 0
<--- Received SIP response (470 bytes) from UDP:92.91.129.200:5062 --->
SIP/2.0 500 Server Internal Error
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Content-Length: 0
<--- Transmitting SIP request (536 bytes) to UDP:92.91.129.200:5062 --->
ACK sip:1023@ims.mnc010.mcc208.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
CSeq: 23228 ACK
Route: <sip:residential.p-cscf.sfr.net;lr>
Max-Forwards: 70
User-Agent: Asterisk PBX 20.4.0
Content-Length: 0
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000012", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000012'
<--- Transmitting SIP response (502 bytes) to UDP:192.168.1.11:45764 --->
SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP 192.168.1.11:45764;rport=45764;received=192.168.1.11;branch=z9hG4bK-524287-1---04203c58a61ade96
Call-ID: gAgscy15debma_BfUc6IkA..
From: <sip:zoiper@192.168.1.11>;tag=09f12e30
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
CSeq: 2 INVITE
Server: Asterisk PBX 20.4.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Reason: Q.850;cause=38
Content-Length: 0
<--- Received SIP request (352 bytes) from UDP:192.168.1.11:45764 --->
ACK sip:1023@192.168.1.11;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.11:45764;branch=z9hG4bK-524287-1---04203c58a61ade96;rport
Max-Forwards: 70
To: <sip:1023@192.168.1.11>;tag=62bd4cd3-00e9-4600-8abf-5973761bfe96
From: <sip:zoiper@192.168.1.11;transport=UDP>;tag=09f12e30
Call-ID: gAgscy15debma_BfUc6IkA..
CSeq: 2 ACK
Content-Length: 0
Debian*CLI>
-
Et la même sortie dans la console Aserisk sans le trace du debut :
Asterisk 20.4.0, Copyright (C) 1999 - 2022, Sangoma Technologies Corporation and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Running as user 'asterisk'
Running under group 'asterisk'
Connected to Asterisk 20.4.0 currently running on Debian (pid = 116941)
== Contact zoiper/sip:zoiper@192.168.1.11:45764;transport=UDP;rinstance=f8e4393d973ab382 has been deleted
== Endpoint zoiper is now Unreachable
-- Added contact 'sip:zoiper@192.168.1.11:45764;transport=UDP;rinstance=07cff2a5eb20ee96' to AOR 'zoiper' with expiration of 60 seconds
== Endpoint zoiper is now Reachable
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000000", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
[Aug 16 17:03:10] WARNING[116985]: res_pjsip_outbound_authenticator_digest.c:507 digest_create_request_with_auth: Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000000", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000000'
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000002", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
[Aug 16 17:03:14] WARNING[116985]: res_pjsip_outbound_authenticator_digest.c:507 digest_create_request_with_auth: Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000002", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000002'
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000004", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
[Aug 16 17:03:17] WARNING[116985]: res_pjsip_outbound_authenticator_digest.c:507 digest_create_request_with_auth: Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000004", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000004'
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000006", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
[Aug 16 17:03:21] WARNING[116985]: res_pjsip_outbound_authenticator_digest.c:507 digest_create_request_with_auth: Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000006", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000006'
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000008", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
-- PJSIP/sfr-00000009 is making progress passing it to PJSIP/zoiper-00000008
-- PJSIP/sfr-00000009 is making progress passing it to PJSIP/zoiper-00000008
-- PJSIP/sfr-00000009 is making progress passing it to PJSIP/zoiper-00000008
-- PJSIP/sfr-00000009 is making progress passing it to PJSIP/zoiper-00000008
-- PJSIP/sfr-00000009 is making progress passing it to PJSIP/zoiper-00000008
-- PJSIP/sfr-00000009 is making progress passing it to PJSIP/zoiper-00000008
-- PJSIP/sfr-00000009 is making progress passing it to PJSIP/zoiper-00000008
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000008", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000008'
Debian*CLI> Ce n'est qu'à la cinquième tentative que j'ai pu obtenir la communication téléphonique au 1023.
Je ne comprends pas cette anomalie :
Aug 16 17:03:17] WARNING[116985]: res_pjsip_outbound_authenticator_digest.c:507 digest_create_request_with_auth: Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.Il y a bien une option "realm" pour le type=auth du trunk SFR. J'ai essayé plusieurs combinaisons, sans résoudre le problèmes.
A vrai dire, je ne sais pas ce que je dois mettre pour éviter cet avertissement qui bloque la communication.
Comme on peut le voir, il y a eu sept "making progress passing" et sur le dernière, on atteint les 32 secondes et provoque l'arrêt de la communication.
-
Voici deux communications consécutives réussies :
Asterisk 20.4.0, Copyright (C) 1999 - 2022, Sangoma Technologies Corporation and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Running as user 'asterisk'
Running under group 'asterisk'
Connected to Asterisk 20.4.0 currently running on Debian (pid = 13170)
Debian*CLI> pjsip show registrations
<Registration/ServerURI..............................> <Auth....................> <Status.......>
==========================================================================================
sfr/sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org sfr Registered (exp. 3586s)
Objects found: 1
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000000", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 requested media update control 26, passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000000", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000000'
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000002", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
-- PJSIP/sfr-00000003 is making progress passing it to PJSIP/zoiper-00000002
-- PJSIP/sfr-00000003 requested media update control 26, passing it to PJSIP/zoiper-00000002
-- PJSIP/sfr-00000003 is making progress passing it to PJSIP/zoiper-00000002
-- PJSIP/sfr-00000003 is making progress passing it to PJSIP/zoiper-00000002
-- PJSIP/sfr-00000003 is making progress passing it to PJSIP/zoiper-00000002
-- PJSIP/sfr-00000003 is making progress passing it to PJSIP/zoiper-00000002
-- PJSIP/sfr-00000003 is making progress passing it to PJSIP/zoiper-00000002
-- PJSIP/sfr-00000003 is making progress passing it to PJSIP/zoiper-00000002
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000002", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000002'
Debian*CLI> Comme on peut le voir, il n'y a plus ce message d'avertissement mais je n'ai pas résolu le problème.
Il reste juste à résoudre le problème de la coupure de la communication au bout des 32 secondes.
Je n'ai pas trouvé grand chose dans le répertoire /var/log/asterisk/cdr-custom/Master.csv :
""""" <zoiper>","zoiper","1023","outgoing","PJSIP/zoiper-00000000","PJSIP/sfr-00000001","Dial","PJSIP/1023@sfr","2023-08-17 12:30:59","","2023-08-17 12:32:04","64","0","NO ANSWER","DOCUMENTATION","","1692268259.0","",0
""""" <zoiper>","zoiper","1023","outgoing","PJSIP/zoiper-00000002","PJSIP/sfr-00000003","Dial","PJSIP/1023@sfr","2023-08-17 12:32:12","","2023-08-17 12:33:17","64","0","NO ANSWER","DOCUMENTATION","","1692268332.3","",3Pour ce qui est des LOG, rien d'intéressant. Le mieux est encore d'utiliser la console Asterisk.
-
J'ai résolu le problème des 32 secondes. :)
Dans le Trunc SFR, à la section "type=endpoint", il faut ajouter "rewrite_contact=yes" car par défaut, il est à "no".
J'ai fait le test de vérification à partir de mon Debian 11 derrière l'ONT de SFR et ça fonctionne !!!
Voici la solution définitive concernant le paramétrage de la configuration de "pjsip.conf".
[transport-udp-nat]
bind=0.0.0.0
external_media_address=XXX.XXX.XXX.XXX ; c'est l'adresse IP WAN ou publique
external_signaling_address=XXX.XXX.XXX.XXX ; c'est l'adresse IP WAN ou publique
local_net=XXX.XXX.XXX.XXX/255.255.255.255 ; c'est l'adresse IP WAN ou publique
protocol=udp
type=transport
; --------- ;
; Templates ;
; --------- ;
[my_codecs](!)
disallow=all
allow=alaw
allow=ulaw
allow=gsm
[aor_dynamic](!)
max_contacts=1
remove_existing=yes
type=aor
[auth_userpass](!)
auth_type=userpass
type=auth
[endpoint_internal](!,my_codecs)
context=outgoing
from_domain=ims.mnc010.mcc208.3gppnetwork.org
language=fr
type=endpoint
; --------- ;
; Trunk SFR ;
; --------- ;
[sfr]
contact=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
type=aor
[sfr]
auth_type=userpass
password=XXXXXXXXXXXXXXXX
realm= ; pour résoudre le message d'anomalie qui me dérangeait
username=NDIXXXXXXXXXX.XXX.XXX@sfr.fr
type=auth
[sfr](my_codecs)
aors=sfr
context=incoming
from_domain=ims.mnc010.mcc208.3gppnetwork.org
from_user=+33XXXXXXXXX
outbound_auth=sfr
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
rewrite_contact=yes ; pour ne plus avoir les messages "making progress passing", et la coupure au bout des 32 secondes.
transport=transport-udp-nat
type=endpoint
[sfr]
endpoint=sfr
match=residential.p-cscf.sfr.net
type=identify
[sfr]
client_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_auth=sfr
outbound_proxy=sip:residential.p-cscf.sfr.net\;lr
server_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
transport=transport-udp-nat
type=registration
; ------------------- ;
; Phone Line 'Zoiper' ;
; ------------------- ;
[zoiper](aor_dynamic)
[zoiper](auth_userpass)
password=zoiper
username=zoiper
[zoiper](endpoint_internal)
auth=zoiper
aors=zoiper
callerid=zoiperJe ne redonne pas le fichier "extension.conf" car il n'a pas changé.
Et voici un exemple du compte-rendu d'une communication réussie sans coupure au bout des 32 secondes :
Asterisk 20.4.0, Copyright (C) 1999 - 2022, Sangoma Technologies Corporation and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Running as user 'asterisk'
Running under group 'asterisk'
Connected to Asterisk 20.4.0 currently running on Debian (pid = 31183)
Debian*CLI>
Debian*CLI>
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000008", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
-- PJSIP/sfr-00000009 is making progress passing it to PJSIP/zoiper-00000008
-- PJSIP/sfr-00000009 is ringing
[Aug 18 11:54:59] WARNING[31316][C-00000005]: channel.c:5765 set_format: Unable to find a codec translation path: (slin) -> (alaw)
[Aug 18 11:54:59] WARNING[31316][C-00000005]: indications.c:140 playtones_alloc: Unable to set 'PJSIP/zoiper-00000008' to signed linear format (write)
[Aug 18 11:54:59] WARNING[31316][C-00000005]: channel.c:4682 indicate_data_internal: Unable to handle indication 3 for 'PJSIP/zoiper-00000008'
-- PJSIP/sfr-00000009 answered PJSIP/zoiper-00000008
-- Channel PJSIP/sfr-00000009 joined 'simple_bridge' basic-bridge <8b25e4e8-6d86-4c95-8768-d82396fb8bc4>
-- Channel PJSIP/zoiper-00000008 joined 'simple_bridge' basic-bridge <8b25e4e8-6d86-4c95-8768-d82396fb8bc4>
-- Channel PJSIP/sfr-00000009 left 'native_rtp' basic-bridge <8b25e4e8-6d86-4c95-8768-d82396fb8bc4>
-- Channel PJSIP/zoiper-00000008 left 'native_rtp' basic-bridge <8b25e4e8-6d86-4c95-8768-d82396fb8bc4>
== Spawn extension (outgoing, 1023, 1) exited non-zero on 'PJSIP/zoiper-00000008'
Debian*CLI> Comme on peut le voir, les "making progress passing" ont été réduits à 1.
Maintenant, nous avons un "ringing" qui confirme que la communication a été reconnue par SFR.
Je suis allé au bout de la communication via le répondeur du Service Client SFR, soit un peu plus de 2 minutes.
Les trois Warning ne sont pas bloquants, sauf que je ne sais pas les résoudre.
Problème résolu en ce qui concerne les 32 secondes. :D
En l'état, cette configuration vous permet de passer des communications téléphoniques depuis votre SoftPhone.
Ma configuration demande encore quelques ajustements et complémentarités en ce qui concerne le DialPlan, et l'IPv6.
Cordialement.
Artemus24.
@+
-
Les trois Warning ne sont pas bloquants, sauf que je ne sais pas les résoudre.
c'est pas l'ordre dans lequel tu as mis tes codecs ?
Sur la box SFR l'ordre de préférence est celui-ci
<codec enable="true" id="1">G711_alaw</codec>
<codec enable="true" id="2">G711_mulaw</codec>
<codec enable="true" id="3">G729_ab</codec>
<codec enable="false" id="4">G726</codec>
<codec enable="false" id="5">G722</codec>
sur les péripheriques et asterisk, vérifie que tu as le meme ordre partout. Sinon je pense que ca va essayer des codecs qui ne conviennent peut etre pas et générer le warning.
-
Dans Zoiper, j'ai mis dans cet ordre :
--> G.711 a-law
--> G.711 mu-law
--> GSM FR
Dans "sudo make menuselect", à l'installation, j'ai installé tous les sons français :
--> alaw
--> gsm
--> g729
--> g722
--> sln16
--> siren7
--> siren14
Dans Asterisk, j'ai mis dans cet ordre :
--> alaw
--> ulaw
--> gsm
Les codecs concernent le premier Warning. Mais les deux autres, je ne comprends pas.
Running as user 'asterisk'
Running under group 'asterisk'
Connected to Asterisk 20.4.0 currently running on Debian (pid = 3094)
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000000", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 is ringing
[Aug 18 14:26:40] WARNING[3219][C-00000001]: channel.c:5765 set_format: Unable to find a codec translation path: (slin) -> (alaw)
[Aug 18 14:26:40] WARNING[3219][C-00000001]: indications.c:140 playtones_alloc: Unable to set 'PJSIP/zoiper-00000000' to signed linear format (write)
[Aug 18 14:26:40] WARNING[3219][C-00000001]: channel.c:4682 indicate_data_internal: Unable to handle indication 3 for 'PJSIP/zoiper-00000000'
-- PJSIP/sfr-00000001 answered PJSIP/zoiper-00000000
-- Channel PJSIP/sfr-00000001 joined 'simple_bridge' basic-bridge <b172428c-b260-4bc5-97f4-3312a68d4eb2>
-- Channel PJSIP/zoiper-00000000 joined 'simple_bridge' basic-bridge <b172428c-b260-4bc5-97f4-3312a68d4eb2>
-- Channel PJSIP/zoiper-00000000 left 'native_rtp' basic-bridge <b172428c-b260-4bc5-97f4-3312a68d4eb2>
-- Channel PJSIP/sfr-00000001 left 'native_rtp' basic-bridge <b172428c-b260-4bc5-97f4-3312a68d4eb2>
== Spawn extension (outgoing, 1023, 1) exited non-zero on 'PJSIP/zoiper-00000000'
Debian*CLI> D'où sort ce SLIN ? De SFR, je suppose.
Mais je ne l'ai pas dans "sudo make menuselect", ni dans Asterisk et encore moins dans Zoiper.
A moins que "sln16" soit le "slin".
Edit: je n'ai pas de "sln16" ou de "slin" coté Zoiper.
Si je mets "sln16" dans Asterisk, je suis déconnecté de SFR.
-
A mon avis les 2 warnings suivants sont la conséquence du premier, mais cela reste que des warnings, c'est peut etre normal...en tout cas ça n'a pas d'incidence sur le fonctionnement final, non ?
EDIT:
une piste en tout cas une explication ici : https://community.freepbx.org/t/transcoding-from-slin-to-ulaw-and-back-why/58643
By default, Asterisk uses SLIN as internal codec so everything is transcoded to SLIN. Supposedly, you could disable that behaviour with parameter transcode_via_sln=no
à mettre dans asterisk.conf
-
Je pense que "transcode_via_sln=no" ne correspond pas à ma version Asterisk 20.4.0.
Je l'ai mis dans le fichier "/etc/asterisk/asterisk.conf" et je l'ai testé. Ça ne fonctionne pas.
Merci de m'aider. :)
Pour les trois warnings de la codification slin -> alaw, cela ne pose aucun problème puisque la communication prend le codec "g.711 a-law".
Je viens de faire un test d'une communication entrante avec le mobile de mon voisin.
Ça ne fonctionne pas sous Asterisk alors qu'avec MicroSIP configuré, ça fonctionne.
Au mobile, SFR m'indique que mon numéro de téléphone n'existe pas.
Je soupçonne que le problème vient de ce Warning : "Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.".
Je continue de chercher mais je ne trouve rien comme résolution de ce problème.
Il est difficile de s'y retrouver entre les différentes versions d'Asterisk et ce warning similaire au lien mais avec un contexte différent.
L'idée tourne autour du "domain" qu'il ne faudrait pas mettre ou de mettre la même chose entre "from_user" (endpoint) et "username" (auth) du Trunk SFR.
J'ai testé mas cela ne fonctionne pas.
C'est une anomalie qui ne se produit pas tout le temps et il est difficile d'en connaitre la cause.
-
je crois qu'a un moment tu combines des parametres et il ne faut pas. genre +33xxxxxxxxxx@domain
le +33xxxxxx doit aller quelque part et le domain est a renseigner. ensuite c'est asterisk qui se charge de combiner lorsque c'est necessaire je pense.
-
Je veux bien croire que je commets des erreurs, mais je me suis inspiré de plusieurs didacticiels comme celui-ci (https://lafibre.info/remplacer-sfr/ftth-tuto-bypass-complet-neufbox-avec-un-routeur-openwrt/msg944722/#msg944722) ou comme celui-là (https://lafibre.info/remplacer-sfr/ftth-remplacement-de-la-box-nb6vac-par-pfsense/msg965998/#msg965998). Le pire dans cette histoire, cela fonctionne chez eux et pas chez moi et je ne sais pas pourquoi.
Tu as aussi celui-ci (https://community.asterisk.org/t/pjsip-407-error-only-with-asterisk/89622) ou [urlhttps://community.asterisk.org/t/sip-trunk-registered-but-no-incoming-calls/89952=]celui-là/url] dont je me suis inspiré et tous les autres sujets que j'ai parcouru au hasard de mes recherches.
La communication ne se fait pas systématiquement et j'ai ce message qui m'indique la cause :
[Aug 19 10:30:47] WARNING[7883]: res_pjsip_outbound_authenticator_digest.c:507 digest_create_request_with_auth: Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.
== Everyone is busy/congested at this time (1:0/0/1)sauf que je ne comprends pas sa signification.
Je suis obligé de m'y reprendre à plusieurs fois avant d'avoir la communication.
J'en ai beaucoup moins qu'au début de mes tests, mais j'en ai toujours.
Mon but est de ne plus jamais avoir ce Warning bloquant.
Je ne fais que découvrir les possibilités d'Asterisk 20 sachant que les autres versions ont une configuration différentes de celle que j'utilise.
Dans Asterisk 20, je dois utiliser "chan_pjsip" alors que la plupart des exemples sont en "chan_sip", ce qui ne facilite pas la transposition.
Et en plus, chacun a une configuration particulière, entre ceux qui ont un téléphone VOIP et ceux qui comme moi utilise un SoftPhone.
Pas facile de s'y retrouver car je cherche à l'aveuglette sans bien comprendre ce que je fais.
Je procède par comparaison et quand je vois une option que je ne connais pas, je la teste.
-
J'ai consulté les codecs :
Debian*CLI> module show like codec_
Module Description Use Count Status Support Level
codec_g722.so ITU G.722-64kbps G722 Transcoder 0 Running core
codec_gsm.so GSM Coder/Decoder 0 Running core
codec_resample.so SLIN Resampling Codec 0 Running core
codec_ulaw.so mu-Law Coder/Decoder 0 Running core
4 modules loaded
Debian*CLI> Ou est passé le "alaw" ?
Puis, j'ai fait ceci, histoire de savoir comment le charger :
Debian*CLI> core show help module
module load -- Load a module by name
module refresh -- Completely unloads and loads a module by name
module reload -- Reload configuration for a module
module show [like] -- List modules and info
module unload -- Unload a module by name
Debian*CLI>
Debian*CLI> module load codec_alaw.so
Loaded codec_alaw.so
== Registered translator 'alawtolin' from codec alaw to slin, table cost, 900000, computational cost 55
== Registered translator 'lintoalaw' from codec slin to alaw, table cost, 600000, computational cost 107
Loaded codec_alaw.so => (A-law Coder/Decoder)
Debian*CLI> module show like codec_
Module Description Use Count Status Support Level
codec_alaw.so A-law Coder/Decoder 0 Running core
codec_g722.so ITU G.722-64kbps G722 Transcoder 0 Running core
codec_gsm.so GSM Coder/Decoder 0 Running core
codec_resample.so SLIN Resampling Codec 0 Running core
codec_ulaw.so mu-Law Coder/Decoder 0 Running core
5 modules loaded
Debian*CLI> Ça y est, il est présent maintenant.
J'ai fait le test de la communication vers le 1023, et les Warning ont disparu.
Question : pourquoi suis-je obligé de chargé ce module alaw dans Asterisk ?
Dans "sudo make menuselect", il a pourtant été bien installé. Je ne comprends pas ???
-
Le problème est qu'au redémarrage je perds le chargement du module alaw.so que j'avais fait précédemment.
Donc, ce module est bien installé au chargement (troisième ligne en commençant par le haut) :
Debian*CLI> core show codecs
Disclaimer: this command is for informational purposes only.
It does not indicate anything about your configuration.
ID TYPE NAME FORMAT DESCRIPTION
------------------------------------------------------------------------------------------------
30 image png png (PNG Image)
6 audio g726 g726 (G.726 RFC3551)
4 audio alaw alaw (G.711 a-law)
2 audio g723 g723 (G.723.1)
20 audio speex speex (SpeeX)
21 audio speex speex16 (SpeeX 16khz)
22 audio speex speex32 (SpeeX 32khz)
24 audio g722 g722 (G722)
25 audio siren7 siren7 (ITU G.722.1 (Siren7, licensed from Polycom))
31 video h261 h261 (H.261 video)
32 video h263 h263 (H.263 video)
8 audio adpcm adpcm (Dialogic ADPCM)
35 video h265 h265 (H.265 video)
43 audio silk silk8 (SILK Codec (8 KHz))
44 audio silk silk12 (SILK Codec (12 KHz))
45 audio silk silk16 (SILK Codec (16 KHz))
46 audio silk silk24 (SILK Codec (24 KHz))
27 audio g719 g719 (ITU G.719)
33 video h263p h263p (H.263+ video)
34 video h264 h264 (H.264 video)
19 audio g729 g729 (G.729A)
9 audio slin slin (16 bit Signed Linear PCM)
10 audio slin slin12 (16 bit Signed Linear PCM (12kHz))
11 audio slin slin16 (16 bit Signed Linear PCM (16kHz))
12 audio slin slin24 (16 bit Signed Linear PCM (24kHz))
13 audio slin slin32 (16 bit Signed Linear PCM (32kHz))
14 audio slin slin44 (16 bit Signed Linear PCM (44kHz))
15 audio slin slin48 (16 bit Signed Linear PCM (48kHz))
16 audio slin slin96 (16 bit Signed Linear PCM (96kHz))
17 audio slin slin192 (16 bit Signed Linear PCM (192kHz))
3 audio ulaw ulaw (G.711 u-law)
18 audio lpc10 lpc10 (LPC10)
42 audio none none (<Null> codec)
41 image t38 t38 (T.38 UDPTL Fax)
38 video vp9 vp9 (VP9 video)
37 video vp8 vp8 (VP8 video)
5 audio gsm gsm (GSM)
36 video mpeg4 mpeg4 (MPEG4 video)
23 audio ilbc ilbc (iLBC)
39 text red red (T.140 Realtime Text with redundancy)
40 text t140 t140 (Passthrough T.140 Realtime Text)
28 audio opus opus (Opus Codec)
29 image jpeg jpeg (JPEG image)
7 audio g726aal2 g726aal2 (G.726 AAL2)
1 audio codec2 codec2 (Codec 2)
26 audio siren14 siren14 (ITU G.722.1 Annex C, (Siren14, licensed from Polycom))
Debian*CLI> mais il ne se charge pas.
Il est indiqué dans ce lien (https://community.asterisk.org/t/asterisk-16-0-0-no-alaw-translation/76651/4) de modifier le fichier "/etc/asterisk/module.conf".
J'ai cherché la ligne où j'ai "ulaw" puisque je sais qu'il est chargé.
Je l'ai trouvé, je la duplique en mettant "alaw" et je fais une nouvelle tentative de démarrage d'Asterisk.
J'ai fait le test de la communication sortante et je n'ai plus mes Warnings, ceux concernant les codecs.
Problème résolu ! :D
Il ne me reste plus qu'un warning à résoudre.
-
Bravo ! ;) 8)
-
Le problème est qu'au redémarrage je perds le chargement du module alaw.so que j'avais fait précédemment.
Donc, ce module est bien installé au chargement (troisième ligne en commençant par le haut) :
Debian*CLI> core show codecs
Disclaimer: this command is for informational purposes only.
It does not indicate anything about your configuration.
ID TYPE NAME FORMAT DESCRIPTION
------------------------------------------------------------------------------------------------
30 image png png (PNG Image)
6 audio g726 g726 (G.726 RFC3551)
4 audio alaw alaw (G.711 a-law)
2 audio g723 g723 (G.723.1)
20 audio speex speex (SpeeX)
21 audio speex speex16 (SpeeX 16khz)
22 audio speex speex32 (SpeeX 32khz)
24 audio g722 g722 (G722)
25 audio siren7 siren7 (ITU G.722.1 (Siren7, licensed from Polycom))
31 video h261 h261 (H.261 video)
32 video h263 h263 (H.263 video)
8 audio adpcm adpcm (Dialogic ADPCM)
35 video h265 h265 (H.265 video)
43 audio silk silk8 (SILK Codec (8 KHz))
44 audio silk silk12 (SILK Codec (12 KHz))
45 audio silk silk16 (SILK Codec (16 KHz))
46 audio silk silk24 (SILK Codec (24 KHz))
27 audio g719 g719 (ITU G.719)
33 video h263p h263p (H.263+ video)
34 video h264 h264 (H.264 video)
19 audio g729 g729 (G.729A)
9 audio slin slin (16 bit Signed Linear PCM)
10 audio slin slin12 (16 bit Signed Linear PCM (12kHz))
11 audio slin slin16 (16 bit Signed Linear PCM (16kHz))
12 audio slin slin24 (16 bit Signed Linear PCM (24kHz))
13 audio slin slin32 (16 bit Signed Linear PCM (32kHz))
14 audio slin slin44 (16 bit Signed Linear PCM (44kHz))
15 audio slin slin48 (16 bit Signed Linear PCM (48kHz))
16 audio slin slin96 (16 bit Signed Linear PCM (96kHz))
17 audio slin slin192 (16 bit Signed Linear PCM (192kHz))
3 audio ulaw ulaw (G.711 u-law)
18 audio lpc10 lpc10 (LPC10)
42 audio none none (<Null> codec)
41 image t38 t38 (T.38 UDPTL Fax)
38 video vp9 vp9 (VP9 video)
37 video vp8 vp8 (VP8 video)
5 audio gsm gsm (GSM)
36 video mpeg4 mpeg4 (MPEG4 video)
23 audio ilbc ilbc (iLBC)
39 text red red (T.140 Realtime Text with redundancy)
40 text t140 t140 (Passthrough T.140 Realtime Text)
28 audio opus opus (Opus Codec)
29 image jpeg jpeg (JPEG image)
7 audio g726aal2 g726aal2 (G.726 AAL2)
1 audio codec2 codec2 (Codec 2)
26 audio siren14 siren14 (ITU G.722.1 Annex C, (Siren14, licensed from Polycom))
Debian*CLI> mais il ne se charge pas.
Il est indiqué dans ce lien (https://community.asterisk.org/t/asterisk-16-0-0-no-alaw-translation/76651/4) de modifier le fichier "/etc/asterisk/module.conf".
J'ai cherché la ligne où j'ai "ulaw" puisque je sais qu'il est chargé.
Je l'ai trouvé, je la duplique en mettant "alaw" et je fais une nouvelle tentative de démarrage d'Asterisk.
J'ai fait le test de la communication sortante et je n'ai plus mes Warnings, ceux concernant les codecs.
Problème résolu ! :D
Il ne me reste plus qu'un warning à résoudre.
mais tout ce que tu fais là, ca peut servir à terme pour le topic à coté du sip chez sfr?
-
Salut Trekker92.
Je n'ai pas bien compris le sens de ta question.
Ce sujet est consacré à la configuration d'Asterisk, pour utiliser Zoiper comme SoftPhone et résoudre les problèmes liés à la ligne téléphonique SFR.
L'un de ces problèmes qui est résolu maintenant est celui du dépassement des 32 secondes.
Donc oui, cela peut servir pour ceux qui veulent installer Asterisk dans leur routeur.
-
L'un de ces problèmes qui est résolu maintenant est celui du dépassement des 32 secondes.
En fait il est résolu avec Asterisk, mais il n'est pas résolu de façon universelle, dans le sens ou sans astérisk avec un client SIP comme zoiper/microsip on a toujours le probleme.
-
Tout à fait, et je crois comprendre qu'il manque une fonctionnalité dans ces SoftPhone pour être compatible avec le réseau SFR.
-
Le problème de mon dernier Warning concerne le fonctionnement des serveurs Proxy. Nous avons trois serveurs proxy :
--> mitry.p-cscf.sfr.net:5062
--> corbas.p-cscf.sfr.net:5062
--> trappes.p-cscf.sfr.net:5062
Voici celui de Mitry :
~> dig mitry.p-cscf.sfr.net
; <<>> DiG 9.16.42-Debian <<>> mitry.p-cscf.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11647
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mitry.p-cscf.sfr.net. IN A
;; ANSWER SECTION:
mitry.p-cscf.sfr.net. 1758 IN A 92.91.129.8
mitry.p-cscf.sfr.net. 1758 IN A 92.91.129.40
mitry.p-cscf.sfr.net. 1758 IN A 92.91.129.24
mitry.p-cscf.sfr.net. 1758 IN A 92.91.129.56
mitry.p-cscf.sfr.net. 1758 IN A 92.91.129.72
;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Aug 22 18:18:20 CEST 2023
;; MSG SIZE rcvd: 129
~>Celui de Corbas :
~> dig corbas.p-cscf.sfr.net
; <<>> DiG 9.16.42-Debian <<>> corbas.p-cscf.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47989
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;corbas.p-cscf.sfr.net. IN A
;; ANSWER SECTION:
corbas.p-cscf.sfr.net. 1720 IN A 92.91.179.24
corbas.p-cscf.sfr.net. 1720 IN A 92.91.179.8
corbas.p-cscf.sfr.net. 1720 IN A 92.91.179.72
corbas.p-cscf.sfr.net. 1720 IN A 92.91.179.56
corbas.p-cscf.sfr.net. 1720 IN A 92.91.179.40
;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Aug 22 18:18:59 CEST 2023
;; MSG SIZE rcvd: 130
~>Et enfin, celui de trappes :
~> dig trappes.p-cscf.sfr.net
; <<>> DiG 9.16.42-Debian <<>> trappes.p-cscf.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41473
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;trappes.p-cscf.sfr.net. IN A
;; ANSWER SECTION:
trappes.p-cscf.sfr.net. 1663 IN A 92.91.129.136
trappes.p-cscf.sfr.net. 1663 IN A 92.91.129.152
trappes.p-cscf.sfr.net. 1663 IN A 92.91.129.168
trappes.p-cscf.sfr.net. 1663 IN A 92.91.129.200
trappes.p-cscf.sfr.net. 1663 IN A 92.91.129.184
;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Aug 22 18:19:56 CEST 2023
;; MSG SIZE rcvd: 131
~>Comme nous le constatons, un serveur proxy comprend cinq adresses IP et nous avons trois serveurs proxy.
Il existe une url regroupant ces trois serveurs proxy sous le nom de "residential.p-cscf.sfr.net".
Ce serveur proxy fonctionne avec le préfixe "_sip._udp", je suppose gérer par Asterisk :
~> dig _sip._udp.residential.p-cscf.sfr.net
; <<>> DiG 9.16.42-Debian <<>> _sip._udp.residential.p-cscf.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46833
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_sip._udp.residential.p-cscf.sfr.net. IN A
;; Query time: 4 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Aug 22 18:26:29 CEST 2023
;; MSG SIZE rcvd: 65
~> host -t SRV _sip._udp.residential.p-cscf.sfr.net
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 corbas.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 trappes.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 mitry.p-cscf.sfr.net.
~>La connexion se fait en deux temps :
a) SFR sélectionne l'un des trois groupes de proxy : mitry, corbas ou trappes. Selon quel critère ? Je ne sais pas.
b) à chaque appel, une nouvelle adresse IP est sélectionnée dans le groupe des cinq, par rotation.
Quand une adresse IP est sélectionnée, il est possible qu'elle ne fonctionne pas. D'où le message du Warning.
Dans le pire des cas, j'ai quatre appels rejetés pour un appel réussie.
J'aurai bien aimé avoir une solution avec l'url "residential.p-cscf.sfr.net" mais je n'ai rien trouvé.
Inversement, j'ai une solution si je remplace cet url par l'adresse IPv4 suivante :
outbound_proxy=sip:92.91.129.136:5062\;lrIl s'agit du serveur proxy de trappes. Je l'ai testé et à chaque fois, j'ai la communication qui se fait.
Je veux bien, mais jusqu'au jour où cette adresse IPv4 sera en maintenance et je n'aurai plus aucune communication.
Disons que c'est partiellement résolu, en attente de trouver mieux. :(
Il semble que le fonctionnement de ce serveur proxy pose des problèmes pour obtenir l'autorisation d'accès à SFR.
Si vous avez d'autres informations à ce sujet, je suis preneur, afin de résoudre définitivement ce problème.
-
J'aurai bien aimé avoir une solution avec l'url "residential.p-cscf.sfr.net" mais je n'ai rien trouvé.
Soit c'est résolu dans la SFR box, soit dans le réseau peut être au niveau OLT.
-
bonjour xp25.
Je ne sais pas comment fouiller dans la Box SFR pour connaitre leur solution.
Et l'OLT, je n'ai pas accès depuis chez moi.
Je ne comprends pas ta réponse et comment trouver la solution selon tes recommendations.
-
La double résolution.
C'est pas natif sous Asterisk, faut la construire pour qu'il n'y est plus d'échecs.
SFR doit avoir un script qui tourne pour sélectionner la bonne IP pour ne pas mettre en échec un appel.
-
D'accord, je comprends mieux. :)
As tu un exemple que je suis l'implémenter dans Asterisk ?
-
Il faut un script ou une configuration similaire qui fasse la chose suivante :
Que "residential.p-cscf.sfr.net" soit résolu, qu'un serveur Proxy soit choisi et testé fonctionnel et balancé à Asterisk.
Un genre de route toujours accessible.
Tu vois ce que je veux dire ?
-
EDIT :
les ip ne répondent pas au ping :(
-
Je penses que certains client soft/hard VOIP sont capable de gérer un proxy tournant, ce que Asterisk ne doit pas faire par défaut, on lui donne le bon proxy en dur et ça fonctionne :
Inversement, j'ai une solution si je remplace cet url par l'adresse IPv4 suivante :
outbound_proxy=sip:92.91.129.136:5062\;lrIl s'agit du serveur proxy de trappes. Je l'ai testé et à chaque fois, j'ai la communication qui se fait.
Je veux bien, mais jusqu'au jour où cette adresse IPv4 sera en maintenance et je n'aurai plus aucune communication.
Il faut donc monter le carrousel qui doit être implémenté dans la SFR Box et qui pioche la bonne IP.
-
Bonjour Rooot.
Tu as changé ton logo. :)
Tu vois ce que je veux dire ?
Je comprends ce que tu me dis, mais je ne sais pas comment l'implémenter.
Je connais les adresses IPv4 et IPv6 des trois serveurs Proxy SFR.
Il y en a quinze pour l'IPv4 et quinze pour l'IPv6, soit cinq par serveur proxy et il y a trois serveurs proxy.
Je n'ai pas besoin de résoudre l'url "residential.p-cscf.sfr.net" puisque je connais toutes les adresses IP associées.
En théorie il suffirait de pinguer les 5 ip, et d'utiliser la premiere qui répond. Dans la pratique....
J'ai pris l'adresse IPv4 que j'ai mis pour l'option "outbound_proxy" et qui fonctionne dans Asterisk puisque j'ai la communication.
J'ai fait le test du ping mais ça ne fonctionne pas.
Un genre de route toujours accessible.
Sauf que le route est statique dans Asterisk et tu voudrais qu'il soit dynamique, après avoir été testé comme opérationnel.
Et bien sûr, avant chaque appel, ne pas attendre 30 secondes avant de pouvoir passer la communication.
ca peut du coup peut etre expliquer le probleme des 30s.
C'est 32 secondes et cela n'a aucun rapport avec le serveur proxy SFR.
faudrait tester microsip/zoiper (sans asterisk) avec une des 5 ip au lieu du domaine.
EDIT:
j'ai testé, ca marche pas mieux.
L'adresse IPv4 en tant que proxy s'écrit : "92.91.129.136:5062\;lr".
Je l'ai testé et je suis bien inscrit en TCP sous Zoiper5.
Je ne sais pas si j'ai pu avoir la communication car je n'ai pas de son.
Je ne sais pas si en conservant la même adresse IPv4, j'ai à chaque fois la communication téléphonique.
Pour l'instant, ça fonctionne en l'état, mais j'ai quand même un doute sur sa fiabilité sur le long terme.
-
C'est 32 secondes et cela n'a aucun rapport avec le serveur proxy SFR.
Ben l'idée qui m'amene a ce résonnement c'est que dans les mutliples etapes pour initier la communication il y a des resolution de dns. et je me suis dis qu'il etait possible qu'a un moment on s'incrit sur une IP, puis par la suite une nouvelle résolution renvoie une autre ip et du coup on communique avec une ip qui n'est pas celle qu'on a recu au début, d'ou l'absence de reponse et la communication qui se coupe.
-
Je comprends ce que tu me dis, mais je ne sais pas comment l'implémenter.
Je connais les adresses IPv4 et IPv6 des trois serveurs Proxy SFR.
Il y en a quinze pour l'IPv4 et quinze pour l'IPv6, soit cinq par serveur proxy et il y a trois serveurs proxy.
Je n'ai pas besoin de résoudre l'url "residential.p-cscf.sfr.net" puisque je connais toutes les adresses IP associées.
Sauf que le route est statique dans Asterisk et tu voudrais qu'il soit dynamique, après avoir été testé comme opérationnel.
Et bien sûr, avant chaque appel, ne pas attendre 30 secondes avant de pouvoir passer la communication.
Je ne sais pas si en conservant la même adresse IPv4, j'ai à chaque fois la communication téléphonique.
Pour l'instant, ça fonctionne en l'état, mais j'ai quand même un doute sur sa fiabilité sur le long terme.
Il faut une sorte de proxy intermédiaire qui puisse vérifier la bonne route avant un appel.
Un script de condition qui va renvoyer l'IP adéquate en tout temps, ça prend 1/2 seconde.
Ca peut être sur 1h, 6h, 24h, à chaque appel.
Le script peut être lancé avant la numérotation.
-
Ben l'idée qui m'amene a ce résonnement c'est que dans les mutliples etapes pour initier la communication il y a des resolution de dns. et je me suis dis qu'il etait possible qu'a un moment on s'incrit sur une IP, puis par la suite une nouvelle résolution renvoie une autre ip et du coup on communique avec une ip qui n'est pas celle qu'on a recu au début, d'ou l'absence de reponse et la communication qui se coupe.
Si il y a ça, OMG :-X
-
Si il y a ça, OMG :-X
ben du coup ce serait plus un probleme coté client que serveur. les telephones ip n'ont pas ce probleme donc leur soft est mieux codé ;D
ou alors c'est SFR qui fait des trucs pas "standards" du coup les logiciels ne tiennent pas compte de cette possibilité.
@artemus24 si tu veux fouiner dans le firmware de la box SFR, tu peux le récupérer a cette adresse :
https://download.nb6thd.neufbox.neuf.fr/nb6vac_Version%204.0.45d/NB6VAC-MAIN-R4.0.45d
pour le décompiler il faudra y aller a coup de binwalk pour avoir le rootfs. je peux te le donner en version decompressé si tu veux.
-
@ Rooot : non car Asterisk recoit l'adresse IPv4 en premier et reste dessus, puis il entame un échange avec le serveur SFR.
Il manquait l'option "rewrite_contact=yes" pour que l'échange démarre normalement.
Pour ce qui est de la résolution DNS, je ne sais pas ce que Asterisk prend, mais j'ai ceux de ma Box SFR.
Mais cela ne va rien résoudre du tout car le problème ne se trouve pas dans la résolution DNS mais dans celui de trouve la bonne adresse IP.
Ca peut être sur 1h, 6h, 24h, à chaque appel.
Tu proposes de t'aligner sur la périodicité et de faire comme SFR, changer l'adresse IP toutes les 1h, 6h, 24h, par la crontab
Un script de condition qui va renvoyer l'IP adéquat en tout temps, ça prend 1/2 seconde.
Et comment fais-tu la liaison avec Asterisk ? Je ne vais pas arrêter le serveur, faire la modification dans le fichier "pjsip.conf" et relancer le serveur.
Si il y a ça, OMG :-X
Un protocole divin :D pour résoudre un problème de non conformité au SIP.
La seule chose qui ne soit pas conforme au SIP est la gestion du serveur proxy. Habituellement, il n'y en a qu'un qui fonctionne 24/24.
Je ne comprends pas pourquoi les téléphones VOIP/SIP fonctionnent.
-
En cherchant "residential.p-cscf.sfr.net" sur google, je suis tombé sur
ces topics :
-> https://lafibre.info/remplacer-sfr/bypasser-la-neufbox/96/
-> https://docs.opnsense.org/manual/how-tos/sfr_red_fr_ftth.html
-> https://community.asterisk.org/t/asterisk-20-4-0-no-outgoing-communication/98297/15
Dont une question posée par artemus24 ;D
L'attribution des serveurs Proxy SFR (Mitry, Corbas, Trappes) et des adresses IP (cinq par serveur) fonctionne par rotation. Chaque nouvelle communication modifie l'adresse IP précédemment attribuée. En ipv4, j'ai une quinzaine d'adresses IPv4 à gérer, idem pour IPv6.
Dans Asterisk, n'y a-t-il pas une option pour prendre ceux qui sont actifs ?
Et évidemment par un DEV Asterisk : Il n'y a pas. Une telle chose a été demandée, mais personne ne l’a mise en œuvre.
Les réponses suivantes :-X
-> https://blog.kodono.info/wordpress/2013/08/25/configurer-sfr-libertalk-en-sip-sur-android-et-iphone-avec-media5fone/
Là il y a tout un github pour bypasser SFR/RED box -> https://github.com/opnsense/docs/blob/master/source/manual/how-tos/sfr_red_fr_ftth.rst
Peut être va t'on trouver des pistes ;)
-
Tu proposes de t'aligner sur la périodicité et de faire comme SFR, changer l'adresse IP toutes les 1h, 6h, 24h, par la crontab
Juste pour faire la vérif.
Et comment fais-tu la liaison avec Asterisk ?
Je ne vais pas arrêter le serveur, faire la modification dans le fichier "pjsip.conf" et relancer le serveur.
C'est là qu'entre en scène un proxy local renseigné à la place de "residential.p-cscf.sfr.net" et un script qui va fouiner quelle bonne IP utiliser.
Un protocole divin :D pour résoudre un problème de non conformité au SIP.
La seule chose qui ne soit pas conforme au SIP est la gestion du serveur proxy. Habituellement, il n'y en a qu'un qui fonctionne 24/24.
J'espère que ce n'est que ça !
Je ne comprends pas pourquoi les téléphones VOIP/SIP fonctionnent.
Apparemment ils ont une capacité que Asterisk n'a pas :-\
-
il y avait aussi la piste de siproxd (a la place d'asterisk) qui a été évoqué a maintes reprise par @nextgens.
peut etre plus simple a configurer, en tout cas moin "usine a gaz". Bon j'y suis pas arrivé pour autant ;D j'ai pas insisté, @artemus24 si tu as du temps tu devrais regarder.
Par contre je n'ai pas compris si avec cette methode on doit conserver la box dans notre reseau local.
-
Je ne comprends pas pourquoi les téléphones VOIP/SIP fonctionnent.
Apparemment ils ont une capacité que Asterisk n'a pas :-\
Bizarre tout de même car ce genre de téléphone doit gérer le protocole VOIP/SIP, mais pas les spécificités à un FAI.
Ce qui voudrait dire que cette spécificité est présente chez plusieurs FAI.
Comme je l'ai dit dans mes nombreuses interventions, c'est le téléphone VOIP/SIP que je vais privilégier au final.
Je ne me suis pas encore vraiment penché sur l'acquisition d'un téléphone VOIP/SIP.
Il y a le "Gigaset COMFORT 550 IP flex" qui est le successeur du "Gigaset C530 IP".
Mais j'aimerai trouver une solution avec Asterisk !
La seule chose qui ne soit pas conforme au SIP est la gestion du serveur proxy. Habituellement, il n'y en a qu'un qui fonctionne 24/24.
J'espère que ce n'est que ça !
J'ai pu résoudre tous mes problèmes avec Asterisk sauf celui du serveur proxy SFR.
Dont une question posée par artemus24 ;D
Oui, je me suis inscrit dans le forum Asterisk de langue anglaise et la réponse me déçoit.
C'est là qu'entre en scène un proxy local renseigné à la place de "residential.p-cscf.sfr.net" et un script qui va fouiner quelle bonne IP utiliser.
Je ne connais pas les serveurs proxy. Je suppose que l'on peut en créer un localement dans son ordinateur ou dans le routeur. Mais comment va-t-il fonctionner ?
Je suppose à partir d'un script, mais le véritable problème, que je ne sais pas résoudre, est de trouver la bonne adresse IP.
il y avait aussi la piste de siproxd (a la place d'asterisk) qui a été évoqué a maintes reprise par @nextgens.
Je veux bien mais j'ai survolé le lien (https://github.com/hb9xar/siproxd) sans bien comprendre à quoi ça sert.
-
Apparemment ils ont une capacité que Asterisk n'a pas :-\
Bizarre tout de même car ce genre de téléphone doit gérer le protocole VOIP/SIP, mais pas les spécificités à un FAI.
Ce qui voudrait dire que cette spécificité est présente chez plusieurs FAI.
Je ne connais pas les serveurs proxy. Je suppose que l'on peut en créer un localement dans son ordinateur ou dans le routeur. Mais comment va-t-il fonctionner ?
Je suppose à partir d'un script, mais le véritable problème, que je ne sais pas résoudre, est de trouver la bonne adresse IP.
A la réflexion, je pense qu'il manque un paramètre envoyé au proxy qui est passé par les téléphones SIP pour déterminer une bonne route.
Faudrait voir comment proposer à Asterisk un proxy local qui fait le schmilblick et reçoit la bonne IP.
-
Et faire une capture du trafic voir ce qu'il se passe exactement ? C'est souvent le meilleur moyen de trouver des trucs...
EDIT : La connexion se fait en deux temps :
a) SFR sélectionne l'un des trois groupes de proxy : mitry, corbas ou trappes. Selon quel critère ? Je ne sais pas.
b) à chaque appel, une nouvelle adresse IP est sélectionnée dans le groupe des cinq, par rotation.
Pour le DNS, vu la config des record SRV, c'est de l'équitable (comme les IP en fait c'est un round robin). Ils ont le même poids (33), ça change donc à chaque requête, pas de préférence à priori.
-
A la réflexion, je pense qu'il manque un paramètre envoyé au proxy qui est passé par les téléphones SIP pour déterminer une bonne route.
C'est ce que je pense aussi, il manque une option dans Asterisk, qui doit certainement exister dans les téléphones VOIP/SIP.
Faudrait voir comment proposer à Asterisk un proxy local qui fait le schmilblick et reçoit la bonne IP
.
Je fais un test sur l'adresse IP que j'ai sélectionnée. Pour l'instant, elle fonctionne depuis 19h hier.
Pour le proxy, je ne sais même pas quoi installer.
Et faire une capture du trafic voir ce qu'il se passe exactement ? C'est souvent le meilleur moyen de trouver des trucs...
Je veux bien mais je ne sais pas faire de captures du trafic.
Qu'est-ce que cela devrait nous apprendre ?
D'autres adresses IP que ceux du serveurs proxy ?
-
Ça permettrait au moins de découvrir le fonctionnent des téléphones en direct. Ainsi que le fameux DNS "mystère" pour la box (enfin s'il y en a un). Celle que t'as peut se brancher à un ONT externe ? Et peut-être d'autres surprises encore...
Pour les branchements, il te faut soit une double carte réseau, ou beaucoup plus simple, un switch avec port mirroring (en gros un switch manageable avec VLAN, en théorie ils le font tous). T'as ça sous la main ? Ainsi qu'un PC pour analyser avec wireshark.
Et aussi de quoi simuler le DHCP de SFR, mais normalement la box n'est pas trop pénible (contrairement à orange...) ça devrait le faire.
-
Bonjour Renaud07.
Sans compter le fameux DNS "mystère" pour la box (enfin s'il y en a un).
Je n'ai pas compris cette histoire de DNS "mystère". En principe, les DNS de SFR sont :
--> 109.0.66.10
--> 109.0.66.20
--> 2a02:8400::0
--> 2a02:8400::1
S'il s'agit des urls SIP, je crois qu'ils fonctionnent différemment, sans bien comprendre comment.
Celle que t'as peut se brancher à un ONT externe ?
J'ai la Box plus (ou Box 7) de SFR. Oui, je la branche sur l'ONT qui a été fourni avec.
Pour les branchements, il te faut soit une double carte réseau, ...
Je n'ai pas une double carte réseau, mais j'ai deux adaptateurs RJ45/USB.
... ou beaucoup plus simple, un switch avec port mirroring (en gros un switch manageable avec VLAN, en théorie ils le font tous).
J'ai un switch classique mais il n'est pas manageable : D-link DGS108 (https://www.ldlc.com/fiche/PB00125880.html).
T'as ça sous la main ? Ainsi qu'un PC pour analyser avec wireshark.
J'ai aussi des Raspberry Pi, mais je n'ai qu'un seul ordinateur, un Asus TUF705DT.
Et aussi de quoi simuler le DHCP de SFR, mais normalement la box n'est pas trop pénible (contrairement à orange...) ça devrait le faire.
Le branchement :
ONT <--> câble éthernet <--> switch <--> câble éthernet <--> Box <--> câble éthernet <--> Ordinateur
^
+--> câble ethernet <--> raspberry Pi.
-
DNS mystère = proxy de répartition
Il faut savoir comment discute un phone SIP et les serveurs SFR pour 1 s'accrocher durablement et 2 à chaque fois !
Quelle IP est retournée et pourquoi, basé sur IP/MAC/LOGIN/GEO/NUM/what else ?
-
Le schéma, c'est la config actuelle ? Tu passes donc par la box ? Pour le raspberry ça marche comment par contre ? Car dans cette config, il est aussi connecté à l'ONT...
Ce qu'il faudrait faire : vu qu'il n'y a pas de VLAN dans la conf SFR (ou alors j'ai loupé un truc), tu peux rester sur windows (je suppose que tu l'utilise en OS principal) et tout faire avec une VM pfsense, ça sera plus simple que se coltiner une debian en CLI.
L'idée : brancher un adaptateur USB et en faire le WAN de la box et dans la VM l'assigner à son LAN (en mode pont). Ensuite rajouter une seconde interface à cette VM et la mettre en NAT, de sorte à ressortir sur ton LAN. Et transformer le raspberry en routeur, en utilisant l'autre adaptateur, relié à l'ONT, et au LAN avec son interface intégré de l'autre (ou directement à ton PC), là par contre va falloir le faire à la main.
DNS mystère = proxy de répartition
Pas tout à fait, plutôt un DNS spécifique à la VOIP autre que les 4 cités ci-dessus (comme suggéré par x0r). Pour résoudre notamment le domaine de l'URI contact qui éviterait le rewrite_contact=yes
Mais c'est sûr qu'on risque de trouver d'autres trucs intéressants.
-
Je veux bien mais j'ai survolé le lien (https://github.com/hb9xar/siproxd) sans bien comprendre à quoi ça sert.
SIProxd est une sorte de passerelle quand un soft ou hardphone ne peut communiquer avec le serveur SIP situé en dehors de notre réseau.
Un genre d'intermédiaire qui va dire : eh oh SFR, je me connecte et tu maintiens la connexion comme tu aimes et avec les arguments que tu attends et que je peux pas te passer autrement. Et derrière le soft/hard ou Asterisk se connecte à SIProxd et agit comme un gentil phone ;D
-
Je suis depuis mardi 22 aout 2023 vers les 19H sur la même adresse proxy 92.91.129.152 et la communication se fait à chaque fois.
Il faut savoir comment discute un phone SIP et les serveurs SFR pour 1 s'accrocher durablement et 2 à chaque fois !
N'y-a-t-il pas déjà eu des recherches faites à ce sujet dans le forum lafibre.info ?
Pour tout ce qui est dialogue de type SIP entre sfr et asterisk, je pense que tout est fonctionnel, en tout cas, en ce qui me concerne.
Le seul problème rencontré est le serveur proxy SFR.
Le schéma, c'est la config actuelle ?
Non, c'était une suggestion mais il me semble que cela soit impossible d'effectuer une capture avec mon switch à cause du flux qui est redirigé.
Je pense qu'avec un hub, cela serait possible sauf qu'il me faut trois câbles RJ45/usb et je n'en ai que deux.
Pour mes tests Asterisk, j'utilise Debian 11 version Bullseye. Mes Raspberry sont aussi en Bullseye mais dans Raspberry Pi OS, une distribution différente mais basée sur Debian.
L'idée : brancher un adaptateur USB et en faire le WAN de la box et dans la VM l'assigner à son LAN (en mode pont). Ensuite rajouter une seconde interface à cette VM et la mettre en NAT, de sorte à ressortir sur ton LAN. Et transformer le raspberry en routeur, en utilisant l'autre adaptateur, relié à l'ONT, et au LAN avec son interface intégré de l'autre (ou directement à ton PC), là par contre va falloir le faire à la main.
Je n'ai qu'un seul ordinateur physique, un Asus ou j'ai plusieurs système d'exploitation sur des disques externes, sauf en ce qui concerne windows 10 Pro qui est interne.
Cela me semble bien compliquer de procéder ainsi, juste pour effectuer une capture de flux.
N'y a-t-il pas plus simple sous Debian, pour capturer le flux puisque les échanges se font entre mon ordinateur et l'internet ?
Je suppose même que l'on peut réduire cela en écoutant quelques ports comme le 5060, 5062 et d'autres que j'ignore pour l'instant
J'ai déjà une trace (pjsip set logger on) des échanges à partir de la console Asterix, mais au final, je n'ai pas apris grand chose.
Juste qu'en utilisant "residential.p-cscf.sfr.net", il y avait un changement de l'adresse IP du proxy sfr à chaque nouvel appel.
-
L'asterisk est sur ton PC en VM ? Dans ce cas pas de soucis en effet, il suffit de lancer wireshark sur windows, filtrer les bonnes IP et c'est plié.
Le montage que je propose c'est pour capturer ce que fait la box et là tu n'as pas d'autre choix que de faire comme ça. Il faut considérer ça comme un remplacement de box puis la mettre au cul du routeur pour avoir le tel, comme je peux le faire chez moi : J'ai un openwrt en routeur, la box est reliée à mon LAN et passe par une VM pfsense pour avoir le tel fonctionnel. Enfin, c'est du temporaire, le temps que je la reconnecte au routeur directement, problème d'adresse MAC.
-
Je suis depuis mardi 22 aout 2023 vers les 19H sur la même adresse proxy 92.91.129.152 et la communication se fait à chaque fois.
Asterisk a visiblement un problème d'indécision en résolvant continuellement le proxy.
J'ai déjà une trace (pjsip set logger on) des échanges à partir de la console Asterix, mais au final, je n'ai pas apris grand chose.
Juste qu'en utilisant "residential.p-cscf.sfr.net", il y avait un changement de l'adresse IP du proxy sfr à chaque nouvel appel.
Et ça, ce n'est pas normal.
Le proxy doit être résolu et ne pas bouger tout les pets de travers dans les échanges entre le client (Hard/Soft/Asterisk).
SFR a mis en dur l'adresse residential pour justement faire une config adaptive mais pas qui commence à rentré dans un << pousse toi c'est mon tour >> d'IP.
-
@xp25, ben c'est de l'équilibrage de charge...pour moi c'est normal qu'a chaque résolution l'ordre des ip proposées change. il y a 5 serveurs par dns, donc les requetes doivent etre equitablement réparties sur les 5 serveurs. on sature pas un serveur pour ensuite renvoyer sur un autre et ainsi de suite..
si tu fais un nslookup trappes.p-cscf.sfr.net toutes les 5 secondes l'ordre des ip renvoyées n'est jamais le meme, et c'est normal.
ou alors je n'ai pas compris ce que tu voulais dire :o
-
je viens de tester un truc et je suis surpris du résultat.
dans le fichier /etc/hosts de mon routeur, j'ai ajouté les 5 ips de trappes:
92.91.129.136 trappes.p-cscf.sfr.net
92.91.129.152 trappes.p-cscf.sfr.net
92.91.129.168 trappes.p-cscf.sfr.net
92.91.129.184 trappes.p-cscf.sfr.net
92.91.129.200 trappes.p-cscf.sfr.netmon dns c'est mon routeur en 192.168.1.1, et mon routeur a comme dns ceux de sfr.
j'ai redémarré dnsmasq après la modif.
lorsque je lance un nslookup trappes.p-cscf.sfr.net, les ip retournées sont mélangées a chaque fois. c'est pourtant pas SFR qui me les renvoie puisqu'elles sont en dur dans le fichier hosts du routeur. Meme dnsmasq les mélange a chaque requete ??
-
C'est le comportement attendu : dnsmasq fait du round robin entre les differentes adresses. C'est la même chose que ce que fait le serveur DNS de SFR.
-
L'asterisk est sur ton PC en VM ?
Asterisk est sous Debian 11 mais je ne suis pas en VM. Debian 11 est installé sur un disque Western digital externe à mon Asus.
Dans ce cas pas de soucis en effet, il suffit de lancer wireshark sur windows, filtrer les bonnes IP et c'est plié.
Je ne peux pas utiliser Windows 10 Pro en même temps que Debian 11 car je n'ai qu'un seul ordinateur. C'est l'un ou l'autre mais pas les deux.
Je peux me tromper, mais je pense que les cinq adresses IP correspondent au découpage en cinq zones géographique du téléphone en France.
Je parle bien sûr des lignes téléphonique fixes dont les numéros commencent par 01, 02, 03, 04 et 05.
Depuis votre poste fixe téléphonique, une seule adresse IP est opérationnelle pour un groupe donnée et il y a trois groupes : mitry, corbas et trappes.
Ce découpage me semble logique à cause du nombre de téléphone fixe en France.
Au premier trimestre 2022, il y avait 37,89 millions d'abonnés. Le plus haut a été en 2009 où il y avait 41,09 millions d'abonnés.
Il faut répartir ces abonnés d'une manière homogène sur les différents serveurs proxy SFR.
Le proxy doit être résolu et ne pas bouger tout les pets de travers dans les échanges entre le client (Hard/Soft/Asterisk).
De chez moi, l'accès au proxy est résolu si je choisis l'une des quinze adresses IP qui est opérationnelle.
Comme je l'ai déjà dit, depuis mardi 22 aout 2023 vers les 19H00, j'utilise la même adresse IP de trappes (92.91.129.152) en tant que proxy et elle est opérationnelle.
Je viens de faire le test aujourd'hui même, sous Asterisk, à partir de "mitry.p-cscf.sfr.net" pour vérifier les communications téléphoniques :
+---------------+----------+
| Adresse IP | Résultat |
+--------------+----------+
| 92.91.129.24 | ko |
| 92.91.129.40 | Ok |
| 92.91.129.8 | ko |
| 92.91.129.56 | ko |
| 92.91.129.72 | ko |
+---------------+----------+Comme je l'attendais, une seule adresse IP est opérationnelle. Avec Corbas,
+---------------+----------+
| Adresse IP | Résultat |
+--------------+----------+
| 92.91.179.56 | ko |
| 92.91.179.40 | ko |
| 92.91.179.24 | ko |
| 92.91.179.8 | ko |
| 92.91.179.72 | Ok |
+---------------+----------+Même constatation. Et avec Trappes :
+----------------+----------+
| Adresse IP | Résultat |
+---------------+----------+
| 92.91.129.152 | Ok |
| 92.91.129.184 | ko |
| 92.91.129.136 | Ok |
| 92.91.129.168 | ko |
| 92.91.129.200 | Ok |
+---------------+----------+Le comportement de Trappes est différent de Mitry ou de Corbas : trois adresses IP sont opérationnelles. Je ne me l'explique pas.
Sur le nombre de site, je m'attendais à deux, disons le primaire et le secondaire, mais pourquoi trois ?
A chaque nouvel appel, l'adresse IP change et fonctionne d'une manière cyclique de périodicité 5.
Je ne sais que dire sur le comportement de ce serveur proxy SFR.
En utilisant les url, SFR ne respecte pas les normes SIP.
Il m'a été conseillé d'utiliser plutôt une adresse IP que l'url.
Cela fonctionne chez moi (pour combien de temps) en utilisant celle de trappes : "92.91.129.152".
En dehors d'Asterisk, je ne sais pas identifier les adresses IP du proxy SFR qui sont opérationnelles.
-
Le fonctionnement est super bizarre quand même. Ça fait du round robin entre les adresses mais seules certaines marchent... va comprendre ::) Dans ce cas autant avoir un serveur (ou 2 à la limite) par zone géographique, chaque box résout son proxy local et basta. C'est ce que fait orange par ex : un serveur par grande ville (paris, lyon, marseille, nice, bordeaux...), y'a pas 10000 adresses derrière.
Donc si ton hypothèse est la bonne et que malgré le RR, ça n'autorise que certains proxys (basé sur le N° de ligne je suppose), autant rester sur celles qui marchent en les mettant en dur dans le fichiers hosts... ça ne doit pas changer souvent.
Pour ce qui est de la détection, en théorie asterisk est censé se débrouiller... mais là c'est plus vicieux, je ne sais pas s'il se base sur le fait que l'IP est joignable ou pas, car si ça le laisse s'enregistrer mais bloque les appels (t'es ok sur le proxy mais les appels passent pas c'est ça ? ça renvoie le congested du début ?) là ça risque de pas marcher... donc le fichier hosts (ou un seul proxy comme actuellement) est la seule solution (à moins d'implémenter le mécanisme de la box, mais faut trouver ce que c'est...)
Pour la capture sur debian, si t'as mis une interface graphique, tu peux installer wireshark comme sur win, par contre si c'est en CLI, il faut passer par tcpdump. C'est pour ça que je suggérais la VM, c'est infiniment plus pratique que de faire un dualboot... surtout pour faire du test au début. Car j'imagine qu'il va aller sur le raspberry une fois configuré ?
-
en utilisant netcat (nc) pour effectuer un ping sur le port 5062 :
C:\netcat>nc -vz 92.91.129.24 5062
24.129.91.92.rev.sfr.net [92.91.129.24] 5062 (?) open
C:\netcat>nc -vz 92.91.129.40 5062
40.129.91.92.rev.sfr.net [92.91.129.40] 5062 (?) open
C:\netcat>nc -vz 92.91.129.8 5062
8.129.91.92.rev.sfr.net [92.91.129.8] 5062 (?) open
C:\netcat>nc -vz 92.91.129.56 5062
56.129.91.92.rev.sfr.net [92.91.129.56] 5062 (?) open
C:\netcat>nc -vz 92.91.129.72 5062
72.129.91.92.rev.sfr.net [92.91.129.72] 5062 (?) open
ca indique que pour mitry, le port 5062 est bien ouvert sur toutes les IP.
le serveur est visiblement réglé pour ne pas répondre aux ping, mais on voit bien que le port 5062 est open. le serveur est donc actif.
EDIT:
idem pour corbas
-
Mais vu que ça ne marche pas pour tous, le blocage doit s'effectuer selon le numéro, c'est bien ce qu'il me semblait. Donc en fait impossible de déduire quoi que ce soit sur la simple ouverture du port
-
mais comment font les téléphones SIP pour s'en sortir dans ce cas ? vu qu'avec eux aucun souci et pas besoin d'asterix...
-
Ils doivent surement faire un test de connectivité pour valider qu'un appel peut passer et mettent l'IP fonctionnelle en 1er et peut être qu'après chaque appel, rebelote.
Asterisk lui fait la résolution au moment de l'appel comme un bleu, il apprend pas !
C'est peut être ça qu'il faut changer dans la config d'Asterisk, juste implémenter un check en fin d'appel pour ne pas voir un prochain appel en échec.
-
mais comment font les téléphones SIP pour s'en sortir dans ce cas ? vu qu'avec eux aucun souci et pas besoin d'asterix...
Fais une capture du trafic et tu seras fixé. Je ferais volontiers les tests, mais je suis pas chez SFR... et chez OVH, y'a pas tous ces mécanismes bizarres.
-
@ Renaud07 : c'est basé que sur la zone téléphonique, là où se trouve le raccordement à la FTTH.
Depuis le 01 janvier 2023, les numéros fixes ne sont plus associés à la zone téléphonique.
Il n'y a pas que les numéros fixes mais ceux des mobiles ainsi que ceux des entreprises.
Au 31 décembre 2022, il y avait 82,6 millions de cartes SIM en France, dont 20,8 millions chez SFR.
Un numéro commençant par 01 peut recevoir jusqu'à 100 millions d'abonnés.
C'est largement suffisant sachant qu'il y a 37,89 millions d'abonnés en France, réparties sur cinq zones téléphoniques.
L'important est la taille du serveur en terme de points d'entrées.
Faisons un calcul de moyenne. 37,89 / 5 = 7,578 millions.
Et comme une communication se fait à deux, il y a au grand maximum 7,578 / 5 = 3,789 millions.
Je ne connais pas le nombre maximal de connexion simultanée en France, sur un serveur proxy, mais certainement pas 3,789 millions.
Le pic doit être atteint vers le nouvel an. Et en plus, il s'agit de SFR et non national, donc un nombre bien plus petit.
Mon hypothèse est que nous n'avons pas besoin de passer par "residential", "mitry" "corbas" ou trappes" pour obtenir l'adresse ip active.
Je ne sais pas si mon hypothèse est la bonne mais pour l'instant, elle fonctionne.
Oui, je suis bien inscrit (pjsip show registrations) mais je n'ai pas de communication (mon fameux Warning qui bug sur l'option outbound_proxy).
Car j'imagine qu'il va aller sur le raspberry une fois configuré ?
Non, mes raspberry servent pour mes bidouilles en électronique. Elle n'a pas vocation à servir de routeur.
Si je suis dans ce forum, j'ai en effet l'intention d'acheter un routeur bien plus complet que la Box SFR, et pourquoi pas sous OpenWrt.
Et je désire conserver le Triple Play.
@ Rooot : il est normal que ces adresses IP ont le port 5062 ouvert. Il semble que les ports de 5060 jusqu'à 5065 sont ouverts.
Mais comment savoir que mon numéro de téléphone sera reconnue ?
C'est peut être ça qu'il faut changer dans la config d'Asterisk, juste implémenter un check en fin d'appel pour ne pas voir un prochain appel en échec.
Non, Asterisk suit les recommandations de la VOIP/SIP. En principe, il y a qu'un seul serveur proxy qui doit être actif.
Mais rien n'empêche d'ajouter une option au cas où il faudrait vérifier si le serveur proxy est actif et qu'Asterisk doit conserver en mémoire cette adresse IP.
Fais une capture du trafic et tu seras fixé.
Si une recherche est faite, il doit y avoir plusieurs tentatives jusqu'à trouver la bonne adresse IP avant que la communication se fasse.
-
Mon hypothèse est que nous n'avons pas besoin de passer par "residential", "mitry" "corbas" ou trappes" pour obtenir l'adresse ip active.
Je ne sais pas si mon hypothèse est la bonne mais pour l'instant, elle fonctionne.
Oui, je suis bien inscrit (pjsip show registrations) mais je n'ai pas de communication (mon fameux Warning qui bug sur l'option outbound_proxy).
Oui donc c'est compliqué pour détecter ça, asterisk ne le fait pas de tout évidence. Enfin, il faudrait faire une capture pour voir ce que ça dit exactement, genre le proxy répond un forbidden ou un truc dans le genre, ce qui permet dans le cas des tel SIP de passer aux autres proxys jusqu'à trouver celui qui marche.
Ou alors on se fait iech depuis le début et la box reçoit simplement le (ou les) proxy qu'elle doit utiliser dans son fichier de conf au démarrage (ce qui serait logique en fait, genre chez orange on a la réponse dans le DHCP via les options 119/120)... on a vérifié cette piste ? M'en rappelle plus.
-
Ou alors on se fait iech depuis le début et la box reçoit simplement le (ou les) proxy qu'elle doit utiliser dans son fichier de conf au démarrage (ce qui serait logique en fait, genre chez orange on a la réponse dans le DHCP via les options 119/120)... on a vérifié cette piste ? M'en rappelle plus.
oui le fichier XML de config VOIP chargé au démarrage de la box, j'ai posté un screen ici : https://lafibre.info/remplacer-sfr/red-by-sfr-appels-sip-sortant-coupes-au-bout-de-32-secondes/msg1028804/#msg1028804
-
Regardez au niveau de Proxy :
(https://i.imgur.com/EYLJmy1.png)
Il y a une entrée :
dnstype="naptr"
-
Qui a vu ce topic ? -> https://lafibre.info/remplacer-sfr/et-si-on-progressait-sur-le-bypass-replay-et-telephone/
-
Cela fait maintenant une semaine que j'ai la même adresse IP et à chaque tentative, j'ai la communication avec le 1023.
Les cinq adresses IP actives que j'ai données précédemment sont stables et opérationnelles.
En ce qui me concerne, je vais en rester là sur la configuration d'Asterisk puisque ça fonctionne.
J'ai fait un test d'appel vers un mobile depuis Zoiper et la facturation téléphonique a bien été enregistrée.
Ou alors on se fait iech depuis le début et la box reçoit simplement le (ou les) proxy qu'elle doit utiliser dans son fichier de conf au démarrage (ce qui serait logique en fait, genre chez orange on a la réponse dans le DHCP via les options 119/120)... on a vérifié cette piste ? M'en rappelle plus.
Je ne suis pas certain que le fichier de configuration va nous apprendre quoi que ce soit sur le fonctionnement de l'attribution de la bonne adresse IP.
Merci rooot pour ton fichier voip.conf :
<proxy port="5060" id="1" dnstype="naptr">residential.p-cscf.sfr.net</proxy>
<proxy port="5060" id="2">residential.p-cscf.sfr.net</proxy>
<registrar port="5060">residential.p-cscf.sfr.net</registrar>
Merci pour le lien xp25. La différence se situe dans l'url qui n'est pas le même : "fixed.p-cscf.sfr.net".
Je constate aussi que le "realm" est "ims.mnc010.mcc208.3gppnetwork.org".
Si je mets ce "domain", j'ai des warnings mais cela ne m'empêche pas d'avoir la communication.
Chez moi, pour "realm", j'ai mis "sfr.sfr".
-
Regardez au niveau de Proxy :
Il y a une entrée :
dnstype="naptr"
Bien vu ! Mais je me demande si ce n'est pas utilisé que pour ENUM (https://fr.wikipedia.org/wiki/ENUM), car l'usage le plus courant est de retrouver les adresses de contact (URI SIP, mail...) à partir d'un N° (un peu comme un PTR classique avec l'IP).
D'où mon insistance pour capturer le fonctionnement de la box.
@artemus : À tout hasard, que donne un dig NAPTR residential.p-cscf.sfr.net ?
-
~> dig naptr residential.p-cscf.sfr.net
; <<>> DiG 9.16.42-Debian <<>> naptr residential.p-cscf.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29882
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;residential.p-cscf.sfr.net. IN NAPTR
;; AUTHORITY SECTION:
p-cscf.sfr.net. 746 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2023082100 10800 3600 1814400 86400
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug 31 20:39:45 CEST 2023
;; MSG SIZE rcvd: 120
~>
-
Merci pour les informations et recherches faites sur le sujet.
J'avais un serveur Asterisk il y a bien longtemps sur mon routeur OpenWrt (lorsque j'avais fait le tuto initial pour OpenWrt), et cela fonctionnait plus ou moins. Je n'avais à l'époque pas de problème de NAT puisque asterisk était directement sur le routeur.
Entre temps je suis passé sur un PfSense (virtualisé), et j'avais laissé tombé la téléphonie.
Je profite de ce sujet pour remonter un serveur Ubuntu (virtualisé) sur mon LAN, sur lequel j'ai installé un Asterisk et suivi la configuration telle que décrite ici (en PJSIP).
Je profite pour signaler devoir également spécifier manuellement l'IP d'un des serveur de Trappes, j'ai le même problème que décrit précédemment.
J'écris surtout ce message pour exposer le problème que j'ai actuellement et que je n'arrive pas à résoudre, visiblement à cause du NAT :
En faisant la même configuration de PJSIP que décrite ici, j'arrive bien à passer des appels, mais je n'ai pas de son.
Si je fais une capture réseau sur mon LAN, je n'ai aucun paquet RTP. Par contre si je fais une capture réseau pendant un appel sur le côté WAN de mon PfSense, j'ai bien les paquets RTP. Si j'ouvre cette capture avec Wireshark, en utilisant l'onglet "téléphonie", je peux même écouter la conversation.
Cela me fait penser à un problème de NAT.
Pourtant je pensais qu'avec cette configuration cela suffirait à passer le NAT :
external_media_address=XXX.XXX.XXX.XXX ; c'est l'adresse IP WAN ou publique
external_signaling_address=XXX.XXX.XXX.XXX ; c'est l'adresse IP WAN ou publique
local_net=192.168.1.0/24
Je veux absolument éviter de devoir ouvrir des ports (notamment le 5060) sur mon firewall.
J'ai même essayer de configurer STUN et TURN dans rtp.conf mais sans grand succès...
Une idée ??
Merci
-
J'apporte quelques précisions :
- les paquets SIP passent bien le firewall (la capture sur le WAN et le LAN montre le même nombre de paquets SIP)
- Aucun paquet RTP ne passe.
Je pense que je vais devoir utiliser siproxd sur mon routeur PfSense, mais il faut que je trouve comment le configurer
-
Salut maximushugus.
Je vous communique la toute dernière version de mon fichier "pjsip.conf" :
; -------------------------- ;
; Proxy Server SFR ;
; -------------------------- ;
; ;
; residential.p-cscf.sfr.net ;
; ;
; Mitry : 92.91.129.8 ;
; : 92.91.129.24 ;
; : 92.91.129.40 < ;
; : 92.91.129.56 ;
; : 92.91.129.72 ;
; ;
; Corbas : 92.91.179.8 ;
; : 92.91.179.24 ;
; : 92.91.179.40 ;
; : 92.91.179.56 ;
; : 92.91.179.72 < ;
; ;
; Trappes : 92.91.129.136 < ;
; : 92.91.129.152 < *;
; : 92.91.129.168 ;
; : 92.91.129.184 ;
; : 92.91.129.200 < ;
; ;
; -------------------------- ;
[registration]
auth_rejection_permanent=yes
[transport-udp-nat]
bind=0.0.0.0
external_media_address=XXX.XXX.XXX.XXX
external_signaling_address=XXX.XXX.XXX.XXX
local_net=192.168.1.0/24
protocol=udp
type=transport
[transport-udp-ipv6]
type=transport
protocol=udp
bind=::
; --------- ;
; Templates ;
; --------- ;
[my_codecs](!)
disallow=all
allow=alaw
allow=ulaw
allow=gsm
allow=g722
[aor_dynamic](!)
max_contacts=9999
remove_existing=yes
type=aor
[auth_userpass](!)
auth_type=userpass
type=auth
[endpoint_internal](!,my_codecs)
context=outgoing
direct_media=no
force_rport=yes
from_domain=ims.mnc010.mcc208.3gppnetwork.org
ice_support=yes
language=fr
;;rewrite_contact=yes
rtp_symmetric=yes
transport=transport-udp-ipv6
transport=transport-udp-nat
type=endpoint
; --------- ;
; Trunk SFR ;
; --------- ;
[sfr]
contact=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy=sip:92.91.129.152:5062\;lr
max_contacts=9999
type=aor
[sfr_auth]
auth_type=userpass
password=MOTDEPASSESFR
realm=sfr.fr
username=NDI0XXXXXXXXX.XXX.XXX@sfr.fr
type=auth
[sfr](my_codecs)
100rel=yes
aors=sfr
context=incoming
direct_media=no
force_rport=yes
from_domain=ims.mnc010.mcc208.3gppnetwork.org
from_user=+33XXXXXXXXX
ice_support=yes
outbound_auth=sfr_auth
outbound_proxy=sip:92.91.129.152:5062\;lr
rewrite_contact=yes
rtp_symmetric=yes
transport=transport-udp-nat
type=endpoint
[sfr]
endpoint=sfr
type=identify
match=sip:92.91.129.152:5062\;lr
[sfr]
client_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
server_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
contact_user=+33XXXXXXXXX
outbound_auth=sfr_auth
outbound_proxy=sip:92.91.129.152:5062\;lr
transport=transport-udp-nat
type=registration
; ------------------- ;
; Phone Line 'Zoiper' ;
; ------------------- ;
[zoiper](aor_dynamic)
[zoiper](auth_userpass)
password=zoiper
username=zoiper
[zoiper](endpoint_internal)
auth=zoiper
aors=zoiper
callerid=zoiperAinsi que le fichier "extensions.conf" :
[general]
autofallthrough=no
clearglobalvars=no
static=yes
writeprotect=no
[globals]
CONSOLE=Console/dsp
IAXINFO=guest
TRUNK=DAHDI/G2
TRUNKMSD=1
[outgoing]
exten => _X.,1,Dial(PJSIP/${EXTEN}@sfr)
exten => _X.,n,Hangup()
exten => 123,1,VoiceMailMain(${CALLERID(num)})
exten => 123,n,Hangup()
[incoming]
exten => +33XXXXXXXXX,1,Dial(PJSIP/zoiper)
exten => +33XXXXXXXXX,n,Hangup()Je peux effectuer une communication téléphonique sortante depuis mon ordinateur en passant par Zoiper5.
Comme je n'ai pas de mobile, je n'ai pas encore pu testé si je reçois une communication entrante vers Zoiper5.
Asterisk et Zoiper5 sont installés sous Debian version Bullseye.
Je n'ai aucune restriction en ce qui concerne le pare-feu et donc pas de règles NAT écrites.
Je peux passer des communications, soit en passant par la Box SFR, ou soit en reliant mon Debian à Mon ONT directement.
Pour l'ONT, la seule différence se trouve dans "local_net" où j'ai mis l'adresse WAN (ou IP publique).
Et bien sûr, la communication se fait en modifiant l'adresse du serveur Asterisk dans Zoiper5.
A part cela, je n'ai aucun problème dû, il me semble, à la configuration de mon Debian qui est sans aucune restriction.
Merci pour les informations et recherches faites sur le sujet.
Merci à vous d'avoir ouvert le chemin, dont je me suis grandement inspiré, de la configuration en bypassant la Box SFR.
Je profite pour signaler devoir également spécifier manuellement l'IP d'un des serveur de Trappes, j'ai le même problème que décrit précédemment.
Je profite de cette remarque pour signaler que je n'ai pas changé l'adresse IP du serveur Proxy de Trappes depuis quinze jours.
Dans mon tableau "pjsip.conf", j'ai cinq adresses IP opérationnelles. Celle avec l'étoile (*) et celle que j'utilise actuellement.
En faisant la même configuration de PJSIP que décrite ici, j'arrive bien à passer des appels, mais je n'ai pas de son.
J'ai eu ce même problème avec une mauvaise adresse IP du serveur Proxy. Je suis dans la zone téléphone de la nouvelle aquitaine. Il me semble que vous êtes dans le 69 (Rhône) et il est fort possible que l'adresse IP du serveur Proxy que j'utilise, ne soit pas la même en ce qui vous concerne. A vous de la tester jusqu'à ce que vous trouviez la bonne.
A moins que cela concerne l'option "realm". Je ne me souviens plus trop de l'origine de l'absence de son.
Cela me fait penser à un problème de NAT. Pourtant je pensais qu'avec cette configuration cela suffirait à passer le NAT :
Dans ma Box SFR, j'ai désactivé le "SIP ALG". Je ne fais aucune redirection de ports depuis la Box SFR.
En principe, le port utilisé par Asterisk est sous UDP : 5060 (SIP).
Je n'utilise pas IAX (port 4569) ni RTP (port 8000). J'ai coché dans Zoiper5 "Open Random Available Port".
Je n'utilise pas le STUN (stun.zoiper.com) qui utilise le port 3478 puisque c'est résolu par Asterisk.
Et bien sûr, ne pas oublier le port 5062 pour le serveur Proxy de Trappes.
Je veux absolument éviter de devoir ouvrir des ports (notamment le 5060) sur mon firewall.
Le jour où j'aurai un routeur sous OpenWrt, il est fort possible que je doive ouvrir le port 5060 (SIP), au moins pour les communications entrantes.
A priori, pour les communications sortantes, via la Box SFR, je ne rencontre aucun problème, d'autant que ce port n'est pas ouvert.
Si je passe par l'ONT, je récupère les adresses IPv4 & IPv6 du DHCP SFR avant de lancer Asterisk.
Je suis obligé de forcer l'adresse MAC de ma connexion éthernet pour obtenir l'IPv6. Je mets celle de ma Box SFR.
Je pense que je vais devoir utiliser siproxd sur mon routeur PfSense, mais il faut que je trouve comment le configurer
Je n'utilise pas SIPRODX.
Selon votre expérience, est qu'un routeur PFSENSE est facile à configurer ? Je veux dire plus ou moins facile vis-à-vis de OpenWrt ?
-
Merci pour la réponse détaillée :)
Je peux passer des communications, soit en passant par la Box SFR, ou soit en reliant mon Debian à Mon ONT directement.
à mon avis la solution est là : si le serveur asterisk est branché directement sur l'ONT il n'y a pas de NAT, et si on utilise la box SFR il doit y avoir un système qui laisse passer le RTP (même si SIP ALG désactivé).
En tout cas avec un bypass de la box par un routeur PfSense cela ne fonctionne pas.
Je vais quand même essayer avec les autres IP des serveur proxy mais le fait que sur mes captures réseaux WAN je reçoivent bien le trafique RTP mais qu'il ne passe pas sur le LAN me fait penser que le problème ne vient pas de là.
Selon votre expérience, est qu'un routeur PFSENSE est facile à configurer ? Je veux dire plus ou moins facile vis-à-vis de OpenWrt ?
Je trouve que PfSense est complètement différent.
La configuration se fait beaucoup plus en GUI.
La documentation est relativement claire
Et surtout le gros intérêt c'est que je fais tourner mon PfSense sur du matériel x86 (en virtualisation d'ailleurs), et donc avec la configuration matérielle sur mesure que je veux. Je sais qu'OpenWrt peut tourner sur x86 mais selon moins c'est plus de la bidouille, et tous les pilotes ne sont pas disponibles directement.
-
Comme je n'ai pas de routeur et que le sujet m'intéresse, j'ai dû m'adapter.
J'ai bypassé ma Box SFR en branchant l'ONT directement sur mon Debian version Bullseye.
J'ai configuré "dhclient.conf" afin d'avoir les adresses IPv4 & IPv6 issuent du DHCP de SFR.
Ça fonctionne et c'est ainsi que j'ai pu récupérer les identifiants de ma ligne téléphonique.
J'ai cherché un SoftPhone et avec l'aide de Rooot, j'ai installé MicroSIP sous Windows et Zoiper5 sous Debian.
Et c'est là que je constate le problème des 32 secondes. Impossible d'avoir une communication plus longue.
J'ai pris la décision d'installer Asterisk où en lisant dans ce forum, plusieurs membres dont toi, aviez pu obtenir une configuration opérationnelle.
J'ai envisagé d'installé Asterisk pour résoudre les problèmes des SoftPhones.
Je m'y suis repris plusieurs fois car j'avais oublié certaines choses. Entre autre prendre la version française des codecs.
J'ai repris les différentes configurations d'Asterisk que j'ai pu trouver, pour constater qu'elles étaient trop anciennes.
La version d'Asterisk que j'ai installé est la 20.4.0. C'est là que je découvre que je dois configurer pjsip.conf et non sip.conf.
J'ai pu résoudre le problème des 32 secondes grâce à l'option "rewrite_contact=yes".
L'autre problème concerne le serveur proxy "residential.p-cscf.sfr.net" qui donne une adresse IP pas toujours fonctionnelle.
J'ai mis du temps pour comprendre que je devais mettre une adresse IP en remplacement de l'url du serveur proxy.
à mon avis la solution est là : si le serveur asterisk est branché directement sur l'ONT il n'y a pas de NAT, et si on utilise la box SFR il doit y avoir un système qui laisse passer le RTP (même si SIP ALG désactivé).
J'ai préféré commencer par le plus simple (tout est relatif) en utilisant Debian.
Ainsi maintenant, je sais que le serveur Asterisk est opérationnel.
L'étape suivante est d'acheter un téléphone VOIP/SIP où il est possible que je n'aurai plus besoin d'Asterisk.
J'envisage quand même d'utiliser Zoiper5 depuis mon Debian, et je vais continuer à perfectionner mon Asterisk.
J'aurai Asterisk dans mon futur routeur, MicroSIP sous windows, Zoiper5 sous Debian et mon téléphone VOIP/SIP.
Je n'utilise jamais en même temps Windows et Debian puisque j'ai un seul ordinateur.
Windows 10 Pro est installé en interne dans mon Asus, et Debian sur un disque externe, ainsi que windows 11 Pro.
Je n'essaye pas de tout faire en même temps.
Zoiper5 & Asterisk ont été résolus du point de vue de la configuration sous Debian.
Il va falloir effectuer l'intégration dans le routeur en utilisant OpenWrt (ou autre chose comme PFSENSE que je ne rejette pas pour l'instant).
Mais avant de me procurer mon futur routeur, j'envisage de me procurer soit un ONT (ou ONU) ou un module optique SFP+ (voir mon autre sujet).
Tous mes tests ont été fait avec le 1023 (Service client SFR), vu que la communication est gratuite sur ma ligne téléphonique fixe.
Actuellement, je peux passer des communications sortantes sans aucune limitation de durée.
J'envisage de m'acheter un mobile car je n'en possède pas.
J'aimerai recevoir mes communications entrantes disons 10 secondes sur mon téléphone fixe avant de les basculer vers mon futur mobile.
A priori, c'est ce que j'envisage de faire pour la gestion de ma ligne téléphonique.
En tout cas avec un bypass de la box par un routeur PfSense cela ne fonctionne pas.
Il est possible qu'il y a soit un problème de NAT soit un problème de pare-feu dans PFSense.
Je dis cela car sous Debian, je n'ai aucun pare-feu.
Je sais qu'OpenWrt peut tourner sur x86 mais selon moins c'est plus de la bidouille, et tous les pilotes ne sont pas disponibles directement.
Je ne connais pas PFSense, ni OpenWrt. Mon but est de conserver le Triple Play.
Ce que je recherche par le remplacement de la Box SFR, est d'avoir un pare-feu matériel afin d'augmenter la sécurité de mon réseau local :
--> Interdire les accès à certains sites web.
--> Filtrage sur les adresses IP entrantes
--> Filtrage sur les emails reçus (Script Sieve).
--> QoS
Et bien sûr, le tout dans la technologie XGS-PON afin d'avoir un débit download de 8 gb/s et upload de 1 gb/s.
Vaste sujet ! :)
-
Je vais quand même essayer avec les autres IP des serveur proxy mais le fait que sur mes captures réseaux WAN je reçoivent bien le trafique RTP mais qu'il ne passe pas sur le LAN me fait penser que le problème ne vient pas de là.
Essaies à tout hasard de créer une règle de forward de la plage RTP vers ton asterisk. Apparemment, pas mal de monde a des problèmes de RTP avec pfsense... J'ai vu aussi le paramétrage en statique du mapping des ports qui pourrait peut-être aider (cocher hybrid outbound NAT) tiré de la doc de 3CX : https://www.3cx.com/docs/pfsense-firewall/
Sinon tu pourrais tester openwrt (vu que t'es en virtuel tu peux faire ce que tu veux). Chez moi, j'ai zéro soucis avec asterisk et OVH. Aucune règle à créer, c'est presque trop facile. Et j'ai la même config que toi.
Le NAT est bien défini sur le trunk également ? (force_rport = yes)
-
Essaies à tout hasard de créer une règle de forward de la plage RTP vers ton asterisk. Apparemment, pas mal de monde a des problèmes de RTP avec pfsense... J'ai vu aussi le paramétrage en statique du mapping des ports qui pourrait peut-être aider (cocher hybrid outbound NAT) tiré de la doc de 3CX : https://www.3cx.com/docs/pfsense-firewall/
Sinon tu pourrais tester openwrt (vu que t'es en virtuel tu peux faire ce que tu veux). Chez moi, j'ai zéro soucis avec asterisk et OVH. Aucune règle à créer, c'est presque trop facile. Et j'ai la même config que toi.
Le NAT est bien défini sur le trunk également ? (force_rport = yes)
Oui j'avais déjà fait un port forward des ports RTP vers asterisk sur mon PfSense et l'audio fonctionne bien dans ce cas. Néanmoin je me vois difficilement laisser autant de ports ouverts sur mon pare-feu...
Pour ce qui est de "force_rport = yes", comme tu peux le voir dans la configuration c'est bien spécifié :
; -------------------------- ;
; Proxy Server SFR ;
; -------------------------- ;
; ;
; residential.p-cscf.sfr.net ;
; ;
; Mitry : 92.91.129.8 ;
; : 92.91.129.24 ;
; : 92.91.129.40 < ;
; : 92.91.129.56 ;
; : 92.91.129.72 ;
; ;
; Corbas : 92.91.179.8 ;
; : 92.91.179.24 ;
; : 92.91.179.40 ;
; : 92.91.179.56 ;
; : 92.91.179.72 < ;
; ;
; Trappes : 92.91.129.136 < ;
; : 92.91.129.152 < *;
; : 92.91.129.168 ;
; : 92.91.129.184 ;
; : 92.91.129.200 < ;
; ;
; -------------------------- ;
[registration]
auth_rejection_permanent=yes
[transport-udp-nat]
bind=0.0.0.0
external_media_address=XXX.XXX.XXX.XXX
external_signaling_address=XXX.XXX.XXX.XXX
local_net=192.168.1.0/24
protocol=udp
type=transport
[transport-udp-ipv6]
type=transport
protocol=udp
bind=::
; --------- ;
; Templates ;
; --------- ;
[my_codecs](!)
disallow=all
allow=alaw
allow=ulaw
allow=gsm
allow=g722
[aor_dynamic](!)
max_contacts=9999
remove_existing=yes
type=aor
[auth_userpass](!)
auth_type=userpass
type=auth
[endpoint_internal](!,my_codecs)
context=outgoing
direct_media=no
force_rport=yes
from_domain=ims.mnc010.mcc208.3gppnetwork.org
ice_support=yes
language=fr
;;rewrite_contact=yes
rtp_symmetric=yes
transport=transport-udp-ipv6
transport=transport-udp-nat
type=endpoint
; --------- ;
; Trunk SFR ;
; --------- ;
[sfr]
contact=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy=sip:92.91.129.152:5062\;lr
max_contacts=9999
type=aor
[sfr_auth]
auth_type=userpass
password=MOTDEPASSESFR
realm=sfr.fr
username=NDI0XXXXXXXXX.XXX.XXX@sfr.fr
type=auth
[sfr](my_codecs)
100rel=yes
aors=sfr
context=incoming
direct_media=no
force_rport=yes
from_domain=ims.mnc010.mcc208.3gppnetwork.org
from_user=+33XXXXXXXXX
ice_support=yes
outbound_auth=sfr_auth
outbound_proxy=sip:92.91.129.152:5062\;lr
rewrite_contact=yes
rtp_symmetric=yes
transport=transport-udp-nat
type=endpoint
[sfr]
endpoint=sfr
type=identify
match=sip:92.91.129.152:5062\;lr
[sfr]
client_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
server_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
contact_user=+33XXXXXXXXX
outbound_auth=sfr_auth
outbound_proxy=sip:92.91.129.152:5062\;lr
transport=transport-udp-nat
type=registration
; ------------------- ;
; Phone Line 'Zoiper' ;
; ------------------- ;
[zoiper](aor_dynamic)
[zoiper](auth_userpass)
password=zoiper
username=zoiper
[zoiper](endpoint_internal)
auth=zoiper
aors=zoiper
callerid=zoiper
Pour contourner ce problème de NAT, sur le tuto pour le Gigaset C530 (https://lafibre.info/remplacer-sfr/probleme-dinstallation-bypass-voip-red-avec-gigaset-c530-ip/) et sur le Cisco SPA112 (https://lafibre.info/cisco/utilisation-dun-cisco-spa112-pour-la-telephone-voip-de-votre-abonnement-sfr/) il est décrit l'utilisation soit de :
- STUN server (j'ai essayé de le configurer dans rtp.conf avec un serveur STUN que je gère pour un autre projet) : si je ne configure que les paramètres pour STUN dans rtp.conf d'asterisk, je ne vois aucune requete dans les logs de mon serveur STUN. Par contre si je configure STUN et TURN serveur, je vois bien des requetes dans les logs de mon serveur STUN/TURN mais celà ne fonctionne pas pour autant....
- soit utilisation de "VIA" sur le SPA112
-
Pour moi, ça vient que de pfsense j'ai l'impression, sinon les paquets ne reviendraient sans doute pas. Asterisk fait correctement son boulot à priori, pas besoin de STUN.
Ou alors test sans le forward mais avec le mapping des ports en statique, des fois que ça soit juste ça qui fasse déconner...
À noter que chez moi, ma livebox est derrière un pfsense virtuel depuis quelques temps (faut que je remodifie mon openwrt pour pouvoir la reconnecter, mais toujours pas fait) et le RTP passe sans règle particulière.
EDIT : Je viens de faire une capture du trafic et dans mon cas les ports sont bien préservés, si ça se trouve c'est donc bien la randomization des ports par pfsense qui pose problème.
routeur :
18:42:41.571549 IP (tos 0xb8, ttl 63, id 45507, offset 0, flags [DF], proto UDP (17), length 200)
lfbn-lyo-1-xxx-xxx.w86-1xxx.abo.wanadoo.fr.11524 > 91.121.129.143.32336: [udp sum ok] UDP, length 172
18:42:41.573736 IP (tos 0x0, ttl 248, id 40510, offset 0, flags [DF], proto UDP (17), length 160)
91.121.129.143.32336 > lfbn-lyo-1-xxx-xxx.w86-xxx.abo.wanadoo.fr.11524: [udp sum ok] UDP, length 132
Asterisk :
20:42:41.577075 IP (tos 0xb8, ttl 64, id 45507, offset 0, flags [DF], proto UDP (17), length 200)
SIP.mondomaine.lan.11524 > 91.121.129.143.32336: [bad udp cksum 0xa07e -> 0xc9b2!] UDP, length 172
20:42:41.579658 IP (tos 0x0, ttl 247, id 40510, offset 0, flags [DF], proto UDP (17), length 160)
91.121.129.143.32336 > SIP.mondomaine.lan.11524: [udp sum ok] UDP, length 132
-
Ok je viens enfin de comprendre et résoudre mon problème de NAT.
Pour rappel, j'ai un serveur Asterisk branché sur mon LAN derrière un routeur PfSense (qui remplace complètement la neufbox), le tout sur une connexion SFR.
Le problème était que je parvenais bien à passer les appels, mais aucun son ne parvenait jusqu'à moi.
Lorsque je faisait une capture réseau, sur mon LAN la communication SIP passait correctement dans les 2 sens (Asterisk <--> serveur SFR).
Mais sur mon LAN je ne voyais que la communication RTP (qui contient l'audio) dans le sens montant (Asterisk --> SFR) mais rien en descendant. Si je lançais la capture réseau sur la patte WAN de mon PfSense, je vois bien les paquets RTP dans les 2 sens (Asterisk <--> SFR) et je peux même extraire l'audio de la conversation.
A partir de là je me doutais qu'il s'agissait d'un problème de NAT sur mon PfSense, qui ne transférait pas le flux RTP descendant sur le WAN vers l'adresse IP d'Asterisk sur mon LAN.
J'ai donc fais d'autres explorations : j'ai lancé 2 captures réseaux simultanément sur mon PfSense : une sur le WAN et une sur le LAN.
Je me suis rendu compte qu'au cours de l'échange, le NAT de PfSense changeait le port source duquel sortait les paquets RTP depuis mon IP WAN.
Du côté LAN le port source d'Asterisk n'avait pas changé, mais PfSense faisait un NAT de port source sur le WAN.
Néanmoins le serveur SFR continue d'envoyer dans le sens descendant les paquets RTP vers mon IP WAN (ce qui est normal) mais vers le port de destination qui était celui d'avant le changement effectué par Pfsense (et qui restait le même que le port source d'Asterisk sur le LAN, qui lui n'a pas changé). C'est pourquoi ces paquets n'étaient pas nattés du WAN vers mon Asterisk sur le LAN.
Pour corrigé le problème j'ai créé une règle de mappage dans la partie NAT sur PfSense avec comme port source l'adresse IP d'asterisk / 32 (pour ne spécifier que cette adresse), sur l'interface WAN, et en cochant "port statique", pour éviter la randomisation du port source.
Et là, miracle, tout fonctionne comme prévu, sans ouvrir de port ni de redirection dans le pare-feu.
Maintenant si quelqu'un est capable de m'expliquer pourquoi PfSense à ce problème de NAT, je suis preneur de l'explication. J'ai l'impression que c'est un problème de timing du NAT, mais je ne sais pas comment regarder celà.
-
À priori, c'est spécifique à pfsense et peut-être freeBSD ?
D'après ce que j'ai lu (et donc constaté avec ma capture ci-dessus), le parefeu d'openwrt ou iptables/nftables en général ne fait pas de randomisation des ports par défaut, il faut ajouter explicitement l'option : https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)#NAT_flags
D'où le fait que sur la plupart des Linux, il ne devrait pas y avoir de problème.
Faut que je regarde le cas de ma livebox alors voir si les ports sont changés.
EDIT : Je crois avoir compris ce que tu veux dire par timing : pfsense laisse "s’échapper" un ou plusieurs paquet RTP sans changer le port source, mais le fait bien sur les autres d'où l'envoi sur le mauvais port ?
-
Alors, j'ai regardé de mon côté le comportement de mon pfsense et ça à l'air d'être ok.
La livebox annonce le 8008 dans l'INVITE et démarre bien le flux avec. Pfsense, dès le premier paquet le change pour 4702. Le NAT de virtualbox le change à son tour vers 43103 et mon openwrt le transmet sans modif.
Ça nous fait donc : Livebox (8008) > Pfsense (4702) > Virtualbox (43103) > OpenWRT (43103) > Orange
Je tourne avec la 2.3.4, si tu veux essayer des fois que ce soit un bug avec les versions plus récentes : https://archive.org/download/linuxtracker.org_p1/pfSense-CE-2.3.4-RELEASE-amd64.iso.gz
-
Autre truc à prendre en compte : il ne faudrait pas que SFR ait une implémentation un peu bizarre et se base uniquement sur le contenu du INVITE/SDP... Dans ce cas, le mapping statique est la seule solution :-\
J'ai fait un test avec asterisk qui, lui, s'adapte : si au premier coup il détecte l'ip dernière le NAT avec le port original (donc le SDP) à la seconde où le flux RTP arrive il switch sur l'IP/port source du NAT :
== Using SIP RTP TOS bits 184
== Using SIP RTP TOS bits 184 in TCLASS field.
== Using SIP RTP CoS mark 5
> 0x7fc00c044550 -- Strict RTP learning after remote address set to: 10.0.2.15:4004 <<<< INVTE/SDP
-- Executing [123@internal:1] VoiceMailMain("SIP/304-00000042", "304@internal_vm") in new stack
-- <SIP/304-00000042> Playing 'vm-password.slin' (language 'fr_xivo')
> 0x7fc00c044550 -- Strict RTP learning after remote address set to: 10.0.2.15:4004
> 0x7fc00c044550 -- Strict RTP qualifying stream type: audio
> 0x7fc00c044550 -- Strict RTP switching source address to 192.168.1.11:50052 <<<< switch sur l'IP du NAT
-
Autre truc à prendre en compte : il ne faudrait pas que SFR ait une implémentation un peu bizarre et se base uniquement sur le contenu du INVITE/SDP... Dans ce cas, le mapping statique est la seule solution :-\
J'ai fait un test avec asterisk qui, lui, s'adapte : si au premier coup il détecte l'ip dernière le NAT avec le port original (donc le SDP) à la seconde où le flux RTP arrive il switch sur l'IP/port source du NAT :
== Using SIP RTP TOS bits 184
== Using SIP RTP TOS bits 184 in TCLASS field.
== Using SIP RTP CoS mark 5
> 0x7fc00c044550 -- Strict RTP learning after remote address set to: 10.0.2.15:4004 <<<< INVTE/SDP
-- Executing [123@internal:1] VoiceMailMain("SIP/304-00000042", "304@internal_vm") in new stack
-- <SIP/304-00000042> Playing 'vm-password.slin' (language 'fr_xivo')
> 0x7fc00c044550 -- Strict RTP learning after remote address set to: 10.0.2.15:4004
> 0x7fc00c044550 -- Strict RTP qualifying stream type: audio
> 0x7fc00c044550 -- Strict RTP switching source address to 192.168.1.11:50052 <<<< switch sur l'IP du NAT
Je pense que c'est ça : le serveur téléphonique de chez SFR ne doit se baser que sur le contenu de la communication SIP pour déterminer le port de destination dans le sens SFR -> chez moi. Or comme le port source depuis mon PfSense dans le sens moi -> SFR est modifié, randomisé, les 2 ports ne concordent plus et donc le pare-feu ne transfère pas le port en question sur Asterisk,en réponse au NAT comme c'est le cas normalement.
D'où le fait qu'en désactivant la randomisation de port sur le NAT cela fonctionne
Maintenant j'essaie de faire fonctionner les appels entrants.
Sans ouvrir le port 5060 de mon firewall vers Asterisk (avec une redirection), ce dernier ne voit aucune requete. Donc la connexion ne reste pas ouverte, même si j'ai effectué un appel sortant au préalable.
Si j'ouvre et redirige le port 5060 (uniquement depuis l'adresse source 92.91.129.152 par sécurité), et que je fais un appel entrant, cette fois Asterisk reçoit bien une requête mais ne sais pas quoi en faire :
NOTICE[1341]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'INVITE' from '<sip:+336XXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>' failed for '92.91.129.152:5062' (callid: LU-16941649088XX367-13536127@imsgroup-010.tng1asbc02.ims.sfr.net) - No matching endpoint foundEst ce que c'est du au fichier "extension.conf" ?
A suivre
-
@ maximushugus : je n'ai pas pu testé les appels entrants car je n'ai pas de mobile pour le faire.
Comment SFR est capable de rediriger un appel téléphonique entrant vers le serveur Asterisk qui se trouve dans mon ordinateur ?
Mon interrogation se porte plus sur le fait que mon ordinateur peut se trouver n'importe où dans le monde et pas nécessairement chez moi.
Est-ce dépendant du serveur Proxy "residential.p-cscf.sfr.net" ?
-
@artemus24 Chez toi asterisk est sur le routeur donc pas de NAT, comme la box SFR. si tu pouvais monter un asterisk sur une autre machine, avec la meme configuration, tu aurais certainement les meme problèmes.
-
@ Rooot : Asterisk se trouve dans mon Debian. J'ai deux configurations.
Soit le NAT est celui de la Box SFR quand Debian se trouve derrière celui-ci.
Soit Debian se trouve derrière l'ONT et dans ce cas, je n'ai pas de NAT.
-
Maintenant j'essaie de faire fonctionner les appels entrants.
Sans ouvrir le port 5060 de mon firewall vers Asterisk (avec une redirection), ce dernier ne voit aucune requete. Donc la connexion ne reste pas ouverte, même si j'ai effectué un appel sortant au préalable.
Si j'ouvre et redirige le port 5060 (uniquement depuis l'adresse source 92.91.129.152 par sécurité), et que je fais un appel entrant, cette fois Asterisk reçoit bien une requête mais ne sais pas quoi en faire :
NOTICE[1341]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'INVITE' from '<sip:+336XXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>' failed for '92.91.129.152:5062' (callid: LU-16941649088XX367-13536127@imsgroup-010.tng1asbc02.ims.sfr.net) - No matching endpoint foundEst ce que c'est du au fichier "extension.conf" ?
A suivre
J'ai un doute. Si ça venait de extensions.conf, y'aurait un truc plus comme ça je pense :
NOTICE[24392][C-00000001]: chan_sip.c:26695 handle_request_invite: Call from '00339XXXXXXXX' (91.121.129.29:5962) to extension '00339XXXXXXXX' rejected because extension not found in context 'from-ovh'.
En gros il ne trouve pas le numéro associé. Dans ton cas, ça fait penser au nom de domaine...
Je crois que tu t'es gouré dans la section identity, tu as mis la syntaxe du outbound proxy
Il faut renseigner juste l'ip (ou le sous réseau avec /24 par ex) :
[sfr]
endpoint=sfr
match=92.91.129.152
type=identify
-
Pour mise à jour :
J'ai réussi à faire fonctionner Asterisk pour les appel entrants comme sortants sur un serveur Ubuntu derrière un parefeu PfSense sans avoir à ouvrir aucun port depuis le WAN.
Pour cela :
1) J'ai utilisé les configurations pjsip.conf et extensions.conf telles que décrites précédemment
2) J'ai créé une règle de mappage dans la partie NAT sur PfSense avec comme port source l'adresse IP d'asterisk / 32 (pour ne spécifier que cette adresse), sur l'interface WAN, et en cochant "port statique", pour éviter la randomisation du port source
3) J'ai modifié la partie suivante du fichier pjsip.conf telle que [sfr]
contact=sip:+334XXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy=sip:92.91.129.152:5062\;lr
type=aor
max_contacts=9999
qualify_frequency=15La dernière ligne permet un keep_alive de la session UDP depuis le serveur Asterisk vers le serveur SFR et permet donc de recevoir les appels entrant sans ouvrir de port.
4) J'ai modifié la partie [incoming] de extensions.conf telle que :
[incoming]
exten => +334XXXXXXXX,1,Dial(PJSIP/zoiper)
exten => +334XXXXXXXX,n,Hangup()
Tout semble fonctionner correctement !!
-
Il y a un nouveau proxy chez SFR, Venissieux :
root~> host -t SRV _sip._udp.residential.p-cscf.sfr.net
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 corbas.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 mitry.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 venissieux.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 trappes.p-cscf.sfr.net.
root~>Et voici les adresses IP :
root~> dig venissieux.p-cscf.sfr.net
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> venissieux.p-cscf.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32335
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;venissieux.p-cscf.sfr.net. IN A
;; ANSWER SECTION:
venissieux.p-cscf.sfr.net. 46269 IN A 77.136.7.136
venissieux.p-cscf.sfr.net. 46269 IN A 77.136.7.168
venissieux.p-cscf.sfr.net. 46269 IN A 77.136.7.152
;; Query time: 28 msec
;; SERVER: 2a02:8400::1#53(2a02:8400::1) (UDP)
;; WHEN: Sat Dec 16 16:53:48 CET 2023
;; MSG SIZE rcvd: 102
root~>
-
Bonjour,
Voici quelques moiSS que je suis sur la configuration de asterisk sur un routeur maison sous OpenWRT pour me connecter au serveur SFR. J'ai un peu parsé toutes les documentations et forum...
A ce jour je suis encore sous chan_sip car les configurations au départ de mes recherches étaient faites sous ce driver de com.
Ma communication n'est pas vraiment opérationnelle car je perds la communication avec le serveur SFR, erreur CHANUNAVAIL je pense lié à un problème de désenregisrtrement du serveur.
J'ai souvent cette erreur qui apparait:
app_dial.c:2719 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Subscriber absent) == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'SIP/0002-00000000' status is 'CHANUNAVAIL'
J'ai tenté de paramétrer des tempo plus ou moins longues, des keepalive, de changer de serveur, etc... aujourd'hui j'étais vu ce post. Du coup je regarde un peu au niveau des DNS.
J'ai retiré depuis longtemps les DNS de SFR de ma box pour être en DoH/DoT sur Quad9 ou autre sous unbound. Je pense que ca peut être source de problème pour les résolutions.
Du coup je viens de configurer dans SIP.conf en dur l'adresse
outboundproxy=92.91.129.152au lieu de
outboundproxy=residential.p-cscf.sfr.net
ça n'a pas l'air de beaucoup mieux fonctionner, j'ai l'erreur "CHANUNAVAIL" qui revient lié chaque fois au status UNREACHABLE du serveur SFR.
Je pense qu'il faut l'écrire de cette manière sous le driver chan_sip. Est ce que vous avez des remarques pour m'aider ?
Il y a un nouveau proxy chez SFR, Venissieux :
root~> host -t SRV _sip._udp.residential.p-cscf.sfr.net
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 corbas.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 mitry.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 venissieux.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net has SRV record 10 0 5062 trappes.p-cscf.sfr.net.
root~>Et voici les adresses IP :
root~> dig venissieux.p-cscf.sfr.net
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> venissieux.p-cscf.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32335
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;venissieux.p-cscf.sfr.net. IN A
;; ANSWER SECTION:
venissieux.p-cscf.sfr.net. 46269 IN A 77.136.7.136
venissieux.p-cscf.sfr.net. 46269 IN A 77.136.7.168
venissieux.p-cscf.sfr.net. 46269 IN A 77.136.7.152
;; Query time: 28 msec
;; SERVER: 2a02:8400::1#53(2a02:8400::1) (UDP)
;; WHEN: Sat Dec 16 16:53:48 CET 2023
;; MSG SIZE rcvd: 102
root~>
-
Salut cedbouch et bienvenue dans le forum lafibre.info.
Tu peux lire le premier message de mon sujet où il est question de "CHANUNAVAIL". A partir de là, j'ai configuré Asterisk pour résoudre plusieurs problèmes que je cite, comme les 32 secondes. Actuellement, la configuration d'Asterisk est opérationnelle et je peux depuis Zoiper5 recevoir et prendre des communications téléphoniques avec les identifiants de SFR.
Bonne lecture. :)
@+