Bonjour L’équipe,
J’ai de nouveau besoin de votre aide.
Je rencontre un soucis lors des transferts d’appels vers l’extérieur, je m’explique :
- mon appel arrive de manière classique sur une SDA depuis un 06 par exemple
- le téléphone sonne, tout fonctionne parfaitement
Maintenant, lorsque je part du bureau, je souhaiterais mettre un renvoi d’appel sur un portable. J’active le renvoi d’appel inconditionnel par le téléphone (un Yealink T53) vers un 06 et là ça ne fonctionne plus.
- le téléphone sonne
- je peut décrocher mais j’ai pas de son dans aucun sens
J’ai essayé d’activer le renvoi par l’utilisateur du Wazo, idem. Mis un appel vers une extension directement sur la SDA, idem.
Et mon wazo est derrière un routeur, je pense avoir fait les règles de NAT nécessaires.
J’aimerais donc que vous puissiez me guider dans les tests à faire pour debugger la chose.
J’ai déjà fait un “pjsip set logger on” mais je n’ai rien vu de spécial. Que faut-il regarder en particulier ?
Voilà voilà, j’attends vos idées avec impatience 
Merci d’avance à ceux qui liront ce post 
Salut, il faut que tu utilises sngrep et que tu regardes ton sdp sur ton invite du transfert pour voir par où passe ton media.
Sylvain
Salut Sylvain,
Super, merci pour ton retour
Bon…ça ne m’étonne qu’à moitié mais je vois rien de spécial 
mis à part l’IP privée de mon wazo qui traine dans l’invite du renvoi mais je pense que c’est normal…
Tu peux me dire si tu vois quelque chose ?
ça c’est l’invite de l’appel entrant
2024/04/16 10:27:38.656975 ipTrunkProvider:5060 → ipPrivéeWazo:5060
INVITE sip:SDAappelée@IPPubliqueWazo:5060;transport=udp;line=stdmvcv SIP/2.0
Call-ID: 29205-EI-016c5b41-3b924f241@FQDNProvider
Contact: sip:ipTrunkProvider:5060
Content-Type: application/sdp
CSeq: 23328223 INVITE
From: “SDAappelant” sip:SDAappelant@FQDNProvider;user=phone;tag=29205-MN-016c5b42-3b74568b3
Max-Forwards: 28
Record-Route: sip:ipTrunkProvider:5060;lr;session=9767
To: sip:SDAappelée@ipTrunkProvider:5060;user=phone
Via: SIP/2.0/UDP ipTrunkProvider:5060;branch=z9hG4bK-FOST-02024eec-4236ebc7
Allow: REFER,INVITE,NOTIFY,INFO,ACK,UPDATE,OPTIONS,REGISTER,SUBSCRIBE,NOTIFY
User-Agent: Cirpack/v4.88
P-Asserted-Identity: "SDAappelant"sip:SDAappelant@ipTrunkProvider:5060;user=phone
Content-Length: 246
v=0
o=anonymous 171325605865 171325605865 IN IP4 ipTrunkProvider
s=SIP Call
c=IN IP4 ipProviderInconnue
t=0 0
m=audio 32370 RTP/AVP 8 101
b=AS:82
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
et ça c’est l’invite du transfert
2024/04/16 10:27:40.951511 ipPrivéeWazo:5060 → ipTrunkProvider:5060
INVITE sip:NumDestTransfert@FQDNProvider SIP/2.0
Via: SIP/2.0/UDP IPPubliqueWazo:5060;rport;branch=z9hG4bKPj97a03818-083f-402a-ab3c-862c67af53c5
From: “SDAappelée” sip:SDAappelée@ipPrivéeWazo;tag=797ccd90-35f1-458b-93a6-65d8399a16ce
To: sip:NumDestTransfert@FQDNProvider
Contact: sip:asterisk@IPPubliqueWazo:5060
Call-ID: 015695c0-c184-48d0-b46a-834490481f25
CSeq: 16839 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 600
Min-SE: 90
Max-Forwards: 70
User-Agent: Wazo PBX
Proxy-Authorization: Digest username=“trkUsername”, realm=“FQDNProvider”, nonce=“016c5b14792d9f5722d1fca429cf367b”, uri=“sip:NumDestTransfert@FQDNProvider”, response=“92ad9bc71ca2136e0358f78c0defc345”, algorithm=MD5, opaque=“016c2a2c3657b48”
Diversion: “Bastien” sip:100@ipPrivéeWazo;reason=unknown
Content-Type: application/sdp
Content-Length: 235
v=0
o=- 920435868 920435868 IN IP4 IPPubliqueWazo
s=Asterisk
c=IN IP4 IPPubliqueWazo
t=0 0
m=audio 12248 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
Dis-moi si il y a d’autres tests à faire, je continu de creuser de mon côté et revient vers toi entre temps si j’ai quelque chose
Merci en tout cas
Va falloir que tu sniffes les paquets de ton réseau pour comprendre où ça s’en va. Comme ça vite fait le SDP me semble correcte.
Salut Sylvain,
J’ai capté les paquets et je vois rien de spécial.
12:10:04.297235 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: INVITE sip:SDAappelée@IPPubliqueWazo:5060;transport=udp;line=stdmvcv SIP/2.0
12:10:04.297768 IP ipPrivéeWazo.sip > a-csbc-f.as39305.net.sip: SIP: SIP/2.0 100 Trying
12:10:04.860172 IP ipPrivéeWazo.sip > a-csbc-f.as39305.net.sip: SIP: SIP/2.0 200 OK
12:10:04.870948 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: ACK sip:IPPubliqueWazo:5060 SIP/2.0
12:10:06.527413 IP ipPrivéeWazo.sip > a-csbc-f.as39305.net.sip: SIP: INVITE sip:NumDestTransfert@FQDNProvider SIP/2.0
12:10:06.536394 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: SIP/2.0 100 Trying
12:10:06.570912 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: SIP/2.0 407 authentication required
12:10:06.571294 IP ipPrivéeWazo.sip > a-csbc-f.as39305.net.sip: SIP: ACK sip:NumDestTransfert@FQDNProvider SIP/2.0
12:10:06.571556 IP ipPrivéeWazo.sip > a-csbc-f.as39305.net.sip: SIP: INVITE sip:NumDestTransfert@FQDNProvider SIP/2.0
12:10:06.579388 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: SIP/2.0 100 Trying
12:10:07.452754 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: SIP/2.0 183 Progress
12:10:08.712922 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: SIP/2.0 180 Ringing
12:10:11.567612 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: SIP/2.0 200 OK
12:10:11.568239 IP ipPrivéeWazo.sip > a-csbc-f.as39305.net.sip: SIP: ACK sip:ipTrunkProvider:5060 SIP/2.0
12:10:13.852621 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: BYE sip:asterisk@IPPubliqueWazo:5060 SIP/2.0
12:10:13.853049 IP ipPrivéeWazo.sip > a-csbc-f.as39305.net.sip: SIP: SIP/2.0 200 OK
12:10:13.855157 IP ipPrivéeWazo.sip > a-csbc-f.as39305.net.sip: SIP: BYE sip:ipTrunkProvider:5060 SIP/2.0
12:10:13.864498 IP a-csbc-f.as39305.net.sip > ipPrivéeWazo.sip: SIP: SIP/2.0 200 OK
J’ai testé avec la sous-routine suivante sur l’utilisateur et dans ce cas l’appel vers l’extérieur fonctionne bien et l’invite et tout les autres messages sont similaire avec ceux que j’avais jusqu’à présent
[pre-mobility]
exten = s,1,NoOp()
same = n,GotoIf(${XIVO_MOBILEPHONENUMBER}?:return)
same = n,NoOp(Mobile Phone : ${XIVO_MOBILEPHONENUMBER})
same = n,Set(XIVO_INTERFACE=${XIVO_INTERFACE}&Local/${XIVO_MOBILEPHONENUMBER}@${WAZO_DST_USER_CONTEXT})
same = n(return),Return()
Est-ce qu’il y aurait pas un soucis avec le dialplan du renvoi d’appel du coup ?
Est-ce que tu penses à d’autres tests sinon ?
J’ai remarqué une petite différence entre la sous-routine et le transfert, juste avant que l’appel soit émis donc à l’étape dial@outcall:8 dans la sous-routine la ligne est :
[2024-04-17 18:59:56.1488] – Executing [dial@outcall:8] Dial(“Local/numDestTransfert@ctx-bastien-internal-2ba38df3-6980-4412-a966-04ba3ce235ed-0000019a;2”, “PJSIP/numDestTransfert@trk-bastien,o(numDestTransfert)”) in new stack
alors que par le transfert la ligne est :
[2024-04-17 19:01:13.9890] – Executing [dial@outcall:8] Dial(“PJSIP/trk-bastien-000003c3”, “PJSIP/numDestTransfert@trk-bastien,o(numDestTransfert)b(wazo-pre-dial-hooks^s^1)”) in new stack
Pourquoi avec la sous-routine il y a Local/ et avec le transfert PJSIP/, c’est quoi la différence ?
J’attends ton retour pour continuer
Merci beaucoup pour ton aide en tout cas
Je sais pas si ça peut aider par contre mais sur un transfert vers un numéro interne ça fonctionne
Bon, j’ai trouvé le problème je pense…
C’est un soucis de RTP, quand je fait des appels, j’ai aucun paquets RTP qui passent et j’ai les logs suivants quand je passe l’asterisk en debug
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] chan_pjsip.c: PJSIP/trk-bbastien-000003d9 Native formats (alaw)
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] chan_pjsip.c:
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] chan_pjsip.c: PJSIP/trk-bastien-000003da Native formats (alaw)
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] chan_pjsip.c:
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] bridge_native_rtp.c: Symmetric ptimes on the two call legs (20). May be able to native bridge in RTP
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] bridge_native_rtp.c: Bridge ‘66d6f4a0-334e-4ae4-953d-2687a68b8638’: Packetization comparison success between RTP streams (read_ptime0:20 == write_ptime1:20 and read_ptime1:20 == write_ptime0:20).
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] bridge.c: Bridge technology simple_bridge has less preference than native_rtp (50 <= 90). Skipping.
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] bridge.c: Bridge technology softmix does not have any capabilities we want.
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] bridge.c: Chose bridge technology native_rtp
[2024-04-17 23:14:48.6986] DEBUG[3628600][C-0000016d] bridge.c: Bridge 66d6f4a0-334e-4ae4-953d-2687a68b8638 is already using the new technology.
Par contre je ne sais pas comment corriger le problème maintenant
Je ne comprends pas pourquoi il n’y a que sur les transferts que ça fait ça, sur les autres appels j’ai pas de soucis
T’aurais une idée ?
Ouuuuuh je crois que j’ai trouvé la solution !!! 
;rtp_keepalive= ; Interval, in seconds, between comfort noise RTP packets if
; RTP is not flowing. This setting is useful for ensuring that
; holes in NATs and firewalls are kept open throughout a call.
ça te parles ?
J’ai ajouté ça dans dans le “SIP Templates” → “Global” → “Endpoint”
J’ai mis une valeur de 5 et ça c’est mis à fonctionner.
Tu pense que c’est un coup de bol ou c’est viable comme solution ?
Salut, intéressant je comprends pourquoi, cela veut dire que tu as de quoi sur ton firewall qui drop dans tes sessions Nat.
Salut Sylvain,
Oui c’est ça, mais aucun indice pour en arrivait à cette option là, ni sur le wazo ni sur le routeur, je n’ai trouvé aucun indice rien (peut-être que j’ai pas regardé au bon endroit non plus)
Pour d’autre qui aurait le même soucis, je travaille avec du Pfsense, sachez qu’il faut cette option du coup.
Aller, juste une dernière question pour vraiment aller plus loin et bien comprendre si ça te dérange pas
Vu que c’était mon routeur qui bloquait au niveau du NAT et qu’on est sur de l’UDP, comme ça se fait que je ne voyais pas de paquets RTP partir quand même ? Ils étaient bloqué OK mais c’est pas du mode connecté l’UDP, les paquets auraient au moins du partir ou je dis des bétises ?
Parce que là c’est vraiment en lisant la doc et en testant l’option que j’ai trouvé la solution, je n’avais aucun indice allant dans ce sens…
Je ne peux pas te répondre sans vraiment tout connaître ton architecture mais y a rien de magique, tu devais avoir des paquets qui partaient quelque part. Le mieux quand tu as des problèmes de ce genre est de desinner ton architecture et comprendre ton trafic, par où passent tes paquets et suivre en sniffant ce qu’il se passe.
Sylvain
Oui oui c’est sûr, je ferais ça la prochaine fois mais là rien qu’en sniffant le Xivo je voyais pas de paquets RTP partir c’est ça que je trouvais bizarre mais bon…le tout c’est d’avoir trouver on va dire
Encore merci pour ton aide en tout cas c’est super sympa