transfert interrompu avec BRI si dial sans option r

[fastm3]

Bon, j'ai trouvé la solution grace a je pense a un post que j'avais vu passer sur l'ancien forum ( je n'arrive pas a retrouver meme s'il me semble que c'etait exactement le meme probleme ) mais au cas ou quelqu'un pourrait m'aider a me coucher moins bete ce soir. ;)

Scenario et contexte:
Install avec 1 seul T0. Carte avec un seul acces T0 configurée avec dahdi 2.2.1 + patchs specifiques. Appel entrant sur T0 et tentative de transfert sur numero externe. Avec un dial simple, le channel pour le transfert s'interrompt immediatement. Avec l'option r, le transfert s'effectue bien et on voit bien alors le native bridging.
Un dial simple sans l'option r passe tres bien pour appeler un numero externe.

Les traces PRI et Dahdi n'indique rien si ce n'est le statut 111 de tete.
Une idee du pourquoi, je n'arrive pas a trouver de raison logique surtout que cette option "r" n'est pas necessaire sur toute mes installs il me semble.
( Je ne la mets jamais et j'aurais des retours si ca ne marchait pas )

Fastm3.

[Reaper]

Salut, une question interessante.

Pour trouver la raison il faut une approche systématique.

Effectué un tracé sip debug avec le schema suivant:

Appel entrant > asterisk > phone > renvoi > externe

1: Sur une installation ou ça fonctionne sans r
2: Sur une installation ou ça ne fonctionne pas sans r

3: Active le r sur l'installation ou ça ne fonctionne pas sans r.

Trois sip debug donc, attache les traces ici en txt.

[ffossard]

La nécessité de cette option "r" vient peut-être de cette raison "passing no audio from the called channel(s) until one answers" et pas de la génération de sonnerie :confused:

[Reaper]

r - Indicate ringing to the calling party. Pass no audio to the calling
party until the called channel has answered.

[quintana]

Normalement sur un t0 chez FT tu ne peux pas transférer un appel comme cela sans répondre. Le r répond à ta ligne implicitement.

[fastm3]

Normalement sur un t0 chez FT tu ne peux pas transférer un appel comme cela sans répondre. Le r répond à ta ligne implicitement.

Yep, je pense que c'etait ca. Je bypassais le dialplan par defaut ( avec le answer ) en direct par un agi maison. Je n'avais pas de soucis en SIP et je me focalisais juste sur l'endroit des traces. Et du coup, il ne devait pas y avoir de answer.
Reste que sur certaines lignes, et meme certains appels, ca semblait passer rendant incomprehensible le comportement ou du moins pour moi. Ca doit etre fonction des lignes FT.
J'aime bien trouver la cause logique d'un pb meme s'il est resolu.
Merci Quintana et les autres.
Fastm3.

Juste pour info, les traces ok et pas ok mais qui n'aident pas bcp. Pas de traces sip dans ca cas puisque cela n'intervient pas.

Trace HangUp


[Feb 2 21:10:15] VERBOSE[3155] logger.c: -- Executing [s@macro-dialout-trunk:19] Dial("DAHDI/1-1", "DAHDI/g0/062708XXXX|300|") in new stack
[Feb 2 21:10:15] DEBUG[3155] chan_dahdi.c: Using channel 2
[Feb 2 21:10:15] DEBUG[3155] rtp.c: Channel 'DAHDI/2-1' has no RTP, not doing anything
[Feb 2 21:10:15] VERBOSE[3155] logger.c: -- Requested transfer capability: 0x10 - 3K1AUDIO
[Feb 2 21:10:15] DEBUG[2456] channel.c: Avoiding initial deadlock for channel '0xa17b2a8'
[Feb 2 21:10:15] VERBOSE[3155] logger.c: -- Called g0/062708XXXX
[Feb 2 21:10:15] DEBUG[3155] chan_dahdi.c: Dropping frame since I'm still dialing on DAHDI/2-1...
[Feb 2 21:10:15] DEBUG[3155] chan_dahdi.c: Dropping frame since I'm still dialing on DAHDI/2-1...
[Feb 2 21:10:16] DEBUG[3155] chan_dahdi.c: Dropping frame since I'm still dialing on DAHDI/2-1...
[Feb 2 21:10:16] DEBUG[2479] chan_dahdi.c: Queuing frame from PRI_EVENT_PROCEEDING on channel 0/2 span 2
[Feb 2 21:10:16] VERBOSE[3155] logger.c: -- DAHDI/2-1 is proceeding passing it to DAHDI/1-1
[Feb 2 21:10:16] DEBUG[3155] rtp.c: Channel 'DAHDI/1-1' has no RTP, not doing anything
[Feb 2 21:10:16] DEBUG[3155] chan_dahdi.c: Requested indication 15 on channel DAHDI/1-1
[Feb 2 21:10:16] DEBUG[3155] chan_dahdi.c: Received AST_CONTROL_PROCEEDING on DAHDI/1-1
[Feb 2 21:10:19] VERBOSE[2479] logger.c: -- Channel 0/1, span 2 got hangup, cause 111
[Feb 2 21:10:19] WARNING[3155] app_dial.c: Unable to forward voice frame
[Feb 2 21:10:19] DEBUG[3155] rtp.c: Channel 'DAHDI/1-1' has no RTP, not doing anything
[Feb 2 21:10:19] DEBUG[3155] channel.c: Hanging up channel 'DAHDI/2-1'
[Feb 2 21:10:19] DEBUG[3155] chan_dahdi.c: dahdi_hangup(DAHDI/2-1)
Trace Ok


[Feb 2 21:30:00] VERBOSE[3757] logger.c: -- Executing [s@macro-dialout-trunk:19] Dial("DAHDI/1-1", "DAHDI/g0/062708XXXX|300|r") in new stack
[Feb 2 21:30:00] DEBUG[3757] chan_dahdi.c: Using channel 2
[Feb 2 21:30:00] DEBUG[3757] rtp.c: Channel 'DAHDI/2-1' has no RTP, not doing anything
[Feb 2 21:30:00] VERBOSE[3757] logger.c: -- Making new call for cr 32775
[Feb 2 21:30:00] VERBOSE[3757] logger.c: -- Requested transfer capability: 0x10 - 3K1AUDIO
[Feb 2 21:30:00] VERBOSE[3757] logger.c: q931.c:3134 q931_setup: call 32775 on channel 2 enters state 1 (Call Initiated)
[Feb 2 21:30:00] VERBOSE[3757] logger.c: -- Called g0/062708XXXX
[Feb 2 21:30:00] DEBUG[3757] chan_dahdi.c: Requested indication 3 on channel DAHDI/1-1
[Feb 2 21:30:00] VERBOSE[3757] logger.c: q931.c:2844 q931_alerting: call 12 on channel 1 enters state 7 (Call Received)
[Feb 2 21:30:00] DEBUG[2456] channel.c: Avoiding initial deadlock for channel '0xa3b97f0'
[Feb 2 21:30:01] DEBUG[2479] chan_dahdi.c: Queuing frame from PRI_EVENT_PROCEEDING on channel 0/2 span 2
[Feb 2 21:30:01] VERBOSE[3757] logger.c: -- DAHDI/2-1 is proceeding passing it to DAHDI/1-1
[Feb 2 21:30:01] DEBUG[2459] chan_sip.c: Allocating new SIP dialog for (No Call-ID) - NOTIFY (No RTP)
[Feb 2 21:30:01] DEBUG[2459] acl.c: ##### Testing 192.168.1.209 with 192.168.1.0
[Feb 2 21:30:06] DEBUG[2479] chan_dahdi.c: Enabled echo cancellation on channel 2
[Feb 2 21:30:06] DEBUG[2456] channel.c: Avoiding initial deadlock for channel '0xa3dc970'
[Feb 2 21:30:06] VERBOSE[3757] logger.c: -- DAHDI/2-1 is ringing