Transfert vers un numero ovh Received response: "Forbidden" from '"Anonymous"

Bonjour,

J'utilise asterisk de avec la configuration suivante :

Sip.conf

Code:

---

[general]
language=fr
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
canreinvite=no
defaultexpiry=3600
registertimeout=30
registerattempts=0
disallow=all
allow=ulaw
allowguest=yes
nat=yes

register => 00339XXXXXXXX:XXX@sip.ovh.fr

[template](!)
disallow=all
type=friend
host=sip.ovh.fr
fromdomain=sip.ovh.fr
nat=yes
insecure=invite,port
qualify=yes
dtmfmode=inband
allow=ulaw

[ovh1](template)
fromuser=00339XXXXXXXX
username=00339XXXXXXXX
secret=<XXX>
context=depuis-ovh
insecure=port,invite

---

Extensions.conf

Code:

---

[general]
static=yes
writeprotect=no
autofallthrough=yes
clearglobalvars=no
priorityjumping=no

[globals]
CONSOLE=Console/dsp
IAXINFO=guest
TRUNK=Zap/g2
TRUNKMSD=1

[depuis-ovh]
exten => s,1,Answer
exten => s,2,Playback(hello-world)
exten => s,3,Dial(SIP/00336XXX@ovh1, 30)
exten => s,4,Hangup(16)

---

Erreur Console

Code:

---

[Aug  7 07:50:04] WARNING[22111][C-00000000]: chan_sip.c:23597 handle_response_invite: Received response: "Forbidden" from '"Anonymous" <sip:00339XXXXXXXX@sip.ovh.fr>;tag=as754fe7e1'

---

J'essaie de tranferer vers l'exterieur un appel depuis l'exterieur.

Le transfert marche (avec la config du sip insecure=very) quand j'appel connecté en user local avec un softphone vers l'extérieur (appel passé avec le numero ovh).
Il affiche l'erreur Forbidden quand j'appel mon numero de l'extérieur et que j'essaie de transférer en passant l'appel avec le même numero ovh, mais j'entend le hello-world (seulement avec insecure=port,invite).

Pour info j'ai un compte ovh avec qui autorise 2 appels simultanés donc normalement pas de soucis de ce côté là.

Merci de votre soutient :)

je pense qu'il faut que tu change ton callerid avant de transferer vers l'exterieur.
OVH n'accepte pas n'importe quel callerid.

Citation:

---

Envoyé par _AK_

je pense qu'il faut que tu change ton callerid avant de transferer vers l'exterieur.
OVH n'accepte pas n'importe quel callerid.

---

C'est mon numero ovh le callerid je peux pas le changer du coup ?

Citation:

---

Envoyé par _AK_

je pense qu'il faut que tu change ton callerid avant de transferer vers l'exterieur.
OVH n'accepte pas n'importe quel callerid.

---

J'ai assayé en appelant avec un autre caller id que Anonymous, je pense que c'est ce que tu voulais dire mais même erreur.

Code:

---

[Aug  7 21:20:52] WARNING[15315][C-00000002]: chan_sip.c:23597 handle_response_invite: Received response: "Forbidden" from '"00689XXX" <sip:00339XXX@sip.ovh.fr>;tag=as01e9e657'

---

Vous avez bien mis:

callerid=<00339XXX>
username=00339XXX
defaultuser=00339XXX

Dans le peer par lequel vous êtes entrain de composer ?

Citation:

---

Envoyé par Reaper

Vous avez bien mis:

callerid=<00339XXX>
username=00339XXX
defaultuser=00339XXX

Dans le peer par lequel vous êtes entrain de composer ?

---

Oui je viens de retester en ajoutant callerid=<00339XXX> dans la config sip du num qui appel et toujours la même erreur.

Je vois vraiment pas de quoi ca peut venir.

Merci de votre aide en tout cas.

ovh est super casse-c....lle (limite inutilisable) sur les numéros de port udp envoyés. pour un peu que le routeur/fw change le numéro de port, comme bcp le font, cette erreur se produit.

il faudrait refaire le test avec un autre serveur (asterisk par exemple) et tracer les numéros de ports reçus de ton install.

aussi, j'y pense, un sip set debug, ou mieux, un ngrep / tcpdump depuis l'os permet de voir le contenu des paquets, et des fois, il y a des messages supplémentaires dans le paquet (genre la raison...) qui ne remonte pas dans le protocole sip

Citation:

---

Envoyé par jean

ovh est super casse-c....lle (limite inutilisable) sur les numéros de port udp envoyés. pour un peu que le routeur/fw change le numéro de port, comme bcp le font, cette erreur se produit.

il faudrait refaire le test avec un autre serveur (asterisk par exemple) et tracer les numéros de ports reçus de ton install.

aussi, j'y pense, un sip set debug, ou mieux, un ngrep / tcpdump depuis l'os permet de voir le contenu des paquets, et des fois, il y a des messages supplémentaires dans le paquet (genre la raison...) qui ne remonte pas dans le protocole sip

---

Ok merci Jean, je vais voir pour tester si ca viens de là, je te tiens au courant.

Citation:

---

Envoyé par jean

aussi, j'y pense, un sip set debug, ou mieux, un ngrep / tcpdump depuis l'os permet de voir le contenu des paquets, et des fois, il y a des messages supplémentaires dans le paquet (genre la raison...) qui ne remonte pas dans le protocole sip

---

Merci de ton aide en tout cas Jean.

Du coup avec le sip debug set on j'ai pas l'impression que le port change.
J'ai joint la trace si a peut aidé à trouver une piste :

Code:

---

<--- SIP read from UDP:91.121.129.20:5060 --->
INVITE sip:s@46.105.162.3:5060;transport=udp SIP/2.0
Call-ID: 32434-QB-0adef605-010f09d03@sip.ovh.fr
Contact: <sip:10.7.1.68:5060>
Content-Type: application/sdp
CSeq: 146757632 INVITE
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=32434-SS-0adef606-578c9cdf0
Max-Forwards: 27
Record-Route: <sip:91.121.129.20:5060;lr>
To: <sip:04XXXXXX98@10.7.1.68;user=phone>
Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-CMOD-40782f69-72780c1c
Allow: REFER,INVITE,NOTIFY,ACK,UPDATE,OPTIONS,REGISTER,SUBSCRIBE,NOTIFY,CANCEL,BYE,PRACK
User-Agent: Cirpack/v4.56 (gw_sip)
Content-Length: 445

v=0
o=cp10 140847264592 140847264592 IN IP4 10.7.1.122
s=SIP Call
c=IN IP4 91.121.129.146
t=0 0
m=audio 37100 RTP/AVP 18 4 0 8 125 111 101
b=AS:21
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000/1
a=fmtp:4 annexa=no
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:125 CLEARMODE/8000/1
a=rtpmap:111 iLBC/8000/1
a=fmtp:111 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv
<------------->
--- (13 headers 20 lines) ---
Sending to 91.121.129.20:5060 (NAT)
Sending to 91.121.129.20:5060 (NAT)
Using INVITE request as basis request - 32434-QB-0adef605-010f09d03@sip.ovh.fr
Found peer 'ovh1' for 'anonymous' from 91.121.129.20:5060
Found RTP audio format 18
Found RTP audio format 4
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 125
Found RTP audio format 111
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format G723 for ID 4
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found unknown media description format CLEARMODE for ID 125
Found audio description format iLBC for ID 111
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw), peer - audio=(g723|ulaw|alaw|g729|ilbc)/video=(nothing)/text=(nothing), combined - (ulaw)
Non-codec capabilities (dtmf): us - 0x0 (nothing), peer - 0x1 (telephone-event|), combined - 0x0 (nothing)
Peer audio RTP is at port 91.121.129.146:37100
Looking for s in depuis-ovh (domain 46.105.162.3)
list_route: route/path hop: <sip:91.121.129.20:5060;lr>

<--- Transmitting (NAT) to 91.121.129.20:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-CMOD-40782f69-72780c1c;received=91.121.129.20;rport=5060
Record-Route: <sip:91.121.129.20:5060;lr>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=32434-SS-0adef606-578c9cdf0
To: <sip:04XXXXXX98@10.7.1.68;user=phone>
Call-ID: 32434-QB-0adef605-010f09d03@sip.ovh.fr
CSeq: 146757632 INVITE
Server: Asterisk PBX 12.4.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:s@46.105.162.3:5060>
Content-Length: 0


<------------>
Audio is at 10948
Adding codec 100003 (ulaw) to SDP

<--- Reliably Transmitting (NAT) to 91.121.129.20:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-CMOD-40782f69-72780c1c;received=91.121.129.20;rport=5060
Record-Route: <sip:91.121.129.20:5060;lr>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=32434-SS-0adef606-578c9cdf0
To: <sip:04XXXXXX98@10.7.1.68;user=phone>;tag=as79aea362
Call-ID: 32434-QB-0adef605-010f09d03@sip.ovh.fr
CSeq: 146757632 INVITE
Server: Asterisk PBX 12.4.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:s@46.105.162.3:5060>
Content-Type: application/sdp
Content-Length: 193

v=0
o=root 316558813 316558813 IN IP4 46.105.162.3
s=Asterisk PBX 12.4.0
c=IN IP4 46.105.162.3
t=0 0
m=audio 10948 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=maxptime:150
a=sendrecv

<------------>

<--- SIP read from UDP:91.121.129.20:5060 --->
ACK sip:s@46.105.162.3:5060 SIP/2.0
Call-ID: 32434-QB-0adef605-010f09d03@sip.ovh.fr
Contact: <sip:10.7.1.68:5060>
CSeq: 146757632 ACK
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=32434-SS-0adef606-578c9cdf0
Max-Forwards: 27
To: <sip:04XXXXXX98@10.7.1.68;user=phone>;tag=as79aea362
Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-LZEM-40783019-1004fb02
User-Agent: Cirpack/v4.56 (gw_sip)
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
Scheduling destruction of SIP dialog '32434-QB-0adef605-010f09d03@sip.ovh.fr' in 6400 ms (Method: ACK)
Reliably Transmitting (NAT) to 91.121.129.20:5060:
BYE sip:10.7.1.68:5060 SIP/2.0
Via: SIP/2.0/UDP 46.105.162.3:5060;branch=z9hG4bK0b9af941;rport
Route: <sip:91.121.129.20:5060;lr>
Max-Forwards: 70
From: <sip:04XXXXXX98@10.7.1.68;user=phone>;tag=as79aea362
To: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=32434-SS-0adef606-578c9cdf0
Call-ID: 32434-QB-0adef605-010f09d03@sip.ovh.fr
CSeq: 102 BYE
User-Agent: Asterisk PBX 12.4.0
X-Asterisk-HangupCause: Unknown
X-Asterisk-HangupCauseCode: 0
Content-Length: 0


---

<--- SIP read from UDP:91.121.129.20:5060 --->
SIP/2.0 200 OK
Call-ID: 32434-QB-0adef605-010f09d03@sip.ovh.fr
CSeq: 102 BYE
From: <sip:04XXXXXX98@10.7.1.68;user=phone>;tag=as79aea362
Record-Route: <sip:91.121.129.20:5060;transport=udp;lr>
To: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=32434-SS-0adef606-578c9cdf0
Via: SIP/2.0/UDP 46.105.162.3:5060;received=46.105.162.3;rport=5060;branch=z9hG4bK0b9af941
Server: Cirpack/v4.56 (gw_sip)
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---
SIP Response message for INCOMING dialog BYE arrived
Really destroying SIP dialog '32434-QB-0adef605-010f09d03@sip.ovh.fr' Method: ACK

---

Hello,

Je te conseille de forcer le alaw (on est en europe ici !)

Tu as une trace sip d'un appel qui marche ?

++

- la trace sip sur ton serveur ne sert qu'à voir si le paquet de rejet contient des infos supplémentaires
- pour vérifier si le port ne change pas, il faut impérativement faire le test sur un serveur externe - si c'est ton rotueur qui change le port, tu ne le verras pas sans cette manip

Citation:

---

Envoyé par jean

- la trace sip sur ton serveur ne sert qu'à voir si le paquet de rejet contient des infos supplémentaires
- pour vérifier si le port ne change pas, il faut impérativement faire le test sur un serveur externe - si c'est ton rotueur qui change le port, tu ne le verras pas sans cette manip

---

Ok je vais voir ca avec ngrep ..

Par contre si je fais un transfert au lieu du dial, ça marche, ça appel bien mon num externe.

je dois avouer commencer à sécher.... à mon avis...

1/ vérifier que le callerid(num) est bien positionné lors dans l'INVITE vers ovh (via sip set debug ou ngrep)
2/ vérifier que le no de port ne change avec une config de test qui remplace OVH et qui permet de voir ces numéros de ports tels que vus de l'extérieur
3/ contacter le support ovh !

Citation:

---

Envoyé par jean

je dois avouer commencer à sécher.... à mon avis...

1/ vérifier que le callerid(num) est bien positionné lors dans l'INVITE vers ovh (via sip set debug ou ngrep)
2/ vérifier que le no de port ne change avec une config de test qui remplace OVH et qui permet de voir ces numéros de ports tels que vus de l'extérieur
3/ contacter le support ovh !

---

Du coup ça marche avec un transfert(SIP/04XXXXX), je vois pas trop la différence avec Dial(), je vais voir si ça va dans mon cas, mais à l'air de pas faire une grande différence dans mon cas.

Pour Ovh je les ai appelé quand tu m'as dis que ça pouvait venir d'eux si le port change, mais ils se protègent en disant que j'utilise pas un de leur service et que le problème peut se situé dans ma configuration Asterisk, donc ils ne veulent rien savoir.