Présentation du N° suite à renvoi vers extérieur.

[Feden]

Bonjour !

J'ai fait un renvoi d'un poste de mon installation en utilisant la fonction FollowMe.
L'appel entre et ressort par un même T0.

Le renvoi fonctionne bien, mais j'aimerai faire suivre le numéro de l’appelant initial, alors qu'actuellement, c'est la sda de mon T0 qui est présentée.

Le FollowMe ne présente que très peu d'options, je ne vois pas trop dans quelle direction chercher.

[Feden]

Voilà quelque chose de plus précis. Ce n'est plus le FollowMe qui est utilisé ici.

Il y a quelques messages d'erreurs que je ne comprend pas très bien, mais le renvoi est tout de même fait. Malheureusement, c'est toujours le 432155 (N° du T0) qui est présenté. J'ai mis un noOp après le dial pour tenter de voir ce que j'envoie mais il ne fait plus rien après le Dial visiblement. Comme je reçoit l'appel sur le canal 1 et que j'émet ensuite sur le canal 2, je n'utilise pas le CALLERID que j'ai reçu je suppose ?

exten = 432155,1,answer()
exten = 432155,n,noOp(${CALLERID(num)})
exten = 432155,n,dial(DAHDI/g1/763337)
exten = 432155,n,noOp(${CALLERID(num)})

-- Accepting call from '414674' to '432155' on channel 0/1, span 1
-- Executing [432155@DID_span_1:1] Answer("DAHDI/1-1", "") in new stack
-- Executing [432155@DID_span_1:2] NoOp("DAHDI/1-1", "414674") in new stack
-- Executing [432155@DID_span_1:3] Dial("DAHDI/1-1", "DAHDI/g1/763337") in new stack
-- Requested transfer capability: 0x10 - 3K1AUDIO
-- Called g1/763337
-- DAHDI/2-1 is proceeding passing it to DAHDI/1-1
-- DAHDI/2-1 is ringing
-- DAHDI/2-1 answered DAHDI/1-1
-- Native bridging DAHDI/1-1 and DAHDI/2-1
[Dec 28 16:30:00] ERROR[25280]: chan_dahdi.c:12396 dahdi_pri_error: ROSE REJECT:
[Dec 28 16:30:00] ERROR[25280]: chan_dahdi.c:12396 dahdi_pri_error: INVOKE ID: 1
[Dec 28 16:30:00] ERROR[25280]: chan_dahdi.c:12396 dahdi_pri_error: PROBLEM: General: Badly Structured Component
-- Channel 0/2, span 1 got hangup request, cause 16
-- Hungup 'DAHDI/2-1'
== Spawn extension (DID_span_1, 432155, 3) exited non-zero on 'DAHDI/1-1'
-- Hungup 'DAHDI/1-1'
[Dec 28 16:32:50] NOTICE[25280]: chan_dahdi.c:12697 pri_dchannel: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1


J'aime bien le Native bridging, il est fort ce Dahdi quand même !

D'avance, merci pour vos idées,
François

[cedricscha]

As-tu tester avec un Set(Callerid(num) = XXXXXX) ?

Est-ce que ta ligne supporte l'affichage de numéro autre que ceux rattaché à ta ligne ?

[Feden]

Non, mon opérateur ne me laisse pas présenter des numéros qui ne sont pas chez moi, sauf dans le cas d'un renvoi.

[cedricscha]

Bon ben t'as la réponse à ta question.

[Feden]

Justement non,

Quand un poste est renvoyé, l'opérateur permet de faire suivre le N° de l’appelant initial.

J'ai un client qui a le même accès opérateur chez qui cela fonctionne avec un autocom Aastra. Il renvoi une sda de son T0 vers son GSM, quand on l'appelle c'est bien le N° de l'appelant et non la sda du T0 qui est présentée.

C'est ce que j'essaye de faire avec Asterisk.

J'ai vu que l'option "o" de la fonction Dial sert à faire quelque chose comme ça si j'ai bien compris, mais ma syntaxe n'est pas bonne..

Existe-t-il un moyen d'avoir des traces ISDN dans Asterisk ? De façon à voir le numéro que j'envoie quand je fait un appel sortant en BRI.


Merci,
François

[cedricscha]

Pour les carte pri, c'est

pri intense debug

essaie avec cela. Ou peut etre bri intense debug

Autrement, tu as les commandes dahdi debug ...

[ffossard]

Justement non,

Quand un poste est renvoyé, l'opérateur permet de faire suivre le N° de l’appelant initial.

J'ai un client qui a le même accès opérateur chez qui cela fonctionne avec un autocom Aastra. Il renvoi une sda de son T0 vers son GSM, quand on l'appelle c'est bien le N° de l'appelant et non la sda du T0 qui est présentée.

C'est ce que j'essaye de faire avec Asterisk.

...
Merci,
François

Ça ressemble à du "call deflection", cherche ce que c'est tu comprendra.

[Feden]

Merci Cedric !
Terrible la commande, il faut juste rajouter le nom du trunk derrière, pour moi ça donne ça :
pri intense debug span 1
On peut ensuite rediriger la sortie dans un fichier de cette façon :
pri set debug file /fichier

Ça m'a permit de voir que j'envoie bien le N° de l'appelant initial, c'est donc mon opérateur qui le modifie.

Oui Florent, call deflection ou deviation, j'appelle ça un renvoi


Si ça intéresse quelqu'un, voici un extrait de ce que je vois avec pri debug :

< [ 02 ff 03 08 01 41 05 a1 04 03 90 90 a3 18 01 89 1e 02 80 83 6c 08 21 81 34 31 34 36 37 34 70 07 a1 34 33 32 31 35 35 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 127        EA: 1
<   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
< 36 bytes of data
< Protocol Discriminator: Q.931 (8)  len=36
< TEI=75 Call Ref: len= 1 (reference 65/0x41) (Sent from originator)
< Message Type: SETUP (5)
< [a1]
< Sending Complete (len= 1)
< [04 03 90 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: 3.1kHz audio (16)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                                User information layer 1: A-Law (35)
< [18 01 89]
< Channel ID (len= 3) [ Ext: 1  IntID: Implicit  BRI  Spare: 0  Exclusive  Dchan: 0
<                       ChanSel: B1 channel
<                     ]
< [1e 02 80 83]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: User (0)
<                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
< [6c 08 21 81 34 31 34 36 37 34]
< Calling Number (len=10) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation permitted, user number passed network screening (1)  '414674' ]
< [70 07 a1 34 33 32 31 35 35]
< Called Number (len= 9) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '432155' ]
-- Making new call for cref 65
Received message for call 0x92dfb48 on 0xb7423718 TEI/SAPI 75/0, call->pri is 0xb7420350 TEI/SAPI 127/63
-- Processing Q.931 Call Setup
-- Processing IE 161 (cs0, Sending Complete)
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 30 (cs0, Progress Indicator)
-- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number)
q931.c:6789 post_handle_q931_message: Call 65 enters state 6 (Call Present).  Hold state: Idle
Handling message for SAPI/TEI=0/127
q931.c:4442 q931_call_proceeding: Call 65 enters state 9 (Incoming Call Proceeding).  Hold state: Idle
-- T203 requested to stop when not started
-- Restarting T200 timer
TEI: 75 State 4
V(S) 3 V(A) 3 V(R) 1
K 1, RC 0, l3initiated 0, reject_except 0 ack_pend 0
T200 1, N200 3, T203 0

> [ 00 97 7f ]

> Unnumbered frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 075        EA: 1
>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
Changing from state 4 to 5
> Protocol Discriminator: Q.931 (8)  len=7
> TEI=127 Call Ref: len= 1 (reference 65/0x41) (Sent to originator)
> Message Type: CALL PROCEEDING (2)
> [18 01 89]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit  BRI  Spare: 0  Exclusive  Dchan: 0
>                       ChanSel: B1 channel
>                     ]
-- Making new call for cref 32771
> Protocol Discriminator: Q.931 (8)  len=35
> TEI=127 Call Ref: len= 1 (reference 3/0x3) (Sent from originator)
> Message Type: SETUP (5)
> [04 03 90 90 a3]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: 3.1kHz audio (16)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                                User information layer 1: A-Law (35)
> [18 01 82]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit  BRI  Spare: 0  Preferred  Dchan: 0
>                       ChanSel: B2 channel
>                     ]
> [1e 02 80 83]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: User (0)
>                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
> [6c 08 21 81 34 31 34 36 37 34]
> Calling Number (len=10) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number passed network screening (1)  '414674' ]
> [70 07 a1 37 36 33 33 33 37]
> Called Number (len= 9) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '763337' ]
q931.c:4877 q931_setup: Call 32771 enters state 1 (Call Initiated).  Hold state: Idle
TEI: 75 State 5
V(S) 3 V(A) 3 V(R) 1
K 1, RC 0, l3initiated 1, reject_except 0 ack_pend 0
T200 1, N200 3, T203 0

Dans cet extrait on voit bien l'appel entrer et ressortir avec le même N° présenté (si mon analyse est correcte )

[ffossard]

Merci Cedric !
Terrible la commande, il faut juste rajouter le nom du trunk derrière, pour moi ça donne ça :
pri intense debug span 1
On peut ensuite rediriger la sortie dans un fichier de cette façon :
pri set debug file /fichier

Ça m'a permit de voir que j'envoie bien le N° de l'appelant initial, c'est donc mon opérateur qui le modifie.

Oui Florent, call deflection ou deviation, j'appelle ça un renvoi


Si ça intéresse quelqu'un, voici un extrait de ce que je vois avec pri debug :

< [ 02 ff 03 08 01 41 05 a1 04 03 90 90 a3 18 01 89 1e 02 80 83 6c 08 21 81 34 31 34 36 37 34 70 07 a1 34 33 32 31 35 35 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 127        EA: 1
<   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
< 36 bytes of data
< Protocol Discriminator: Q.931 (8)  len=36
< TEI=75 Call Ref: len= 1 (reference 65/0x41) (Sent from originator)
< Message Type: SETUP (5)
< [a1]
< Sending Complete (len= 1)
< [04 03 90 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: 3.1kHz audio (16)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                                User information layer 1: A-Law (35)
< [18 01 89]
< Channel ID (len= 3) [ Ext: 1  IntID: Implicit  BRI  Spare: 0  Exclusive  Dchan: 0
<                       ChanSel: B1 channel
<                     ]
< [1e 02 80 83]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: User (0)
<                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
< [6c 08 21 81 34 31 34 36 37 34]
< Calling Number (len=10) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation permitted, user number passed network screening (1)  '414674' ]
< [70 07 a1 34 33 32 31 35 35]
< Called Number (len= 9) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '432155' ]
-- Making new call for cref 65
Received message for call 0x92dfb48 on 0xb7423718 TEI/SAPI 75/0, call->pri is 0xb7420350 TEI/SAPI 127/63
-- Processing Q.931 Call Setup
-- Processing IE 161 (cs0, Sending Complete)
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 30 (cs0, Progress Indicator)
-- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number)
q931.c:6789 post_handle_q931_message: Call 65 enters state 6 (Call Present).  Hold state: Idle
Handling message for SAPI/TEI=0/127
q931.c:4442 q931_call_proceeding: Call 65 enters state 9 (Incoming Call Proceeding).  Hold state: Idle
-- T203 requested to stop when not started
-- Restarting T200 timer
TEI: 75 State 4
V(S) 3 V(A) 3 V(R) 1
K 1, RC 0, l3initiated 0, reject_except 0 ack_pend 0
T200 1, N200 3, T203 0

> [ 00 97 7f ]

> Unnumbered frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 075        EA: 1
>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
Changing from state 4 to 5
> Protocol Discriminator: Q.931 (8)  len=7
> TEI=127 Call Ref: len= 1 (reference 65/0x41) (Sent to originator)
> Message Type: CALL PROCEEDING (2)
> [18 01 89]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit  BRI  Spare: 0  Exclusive  Dchan: 0
>                       ChanSel: B1 channel
>                     ]
-- Making new call for cref 32771
> Protocol Discriminator: Q.931 (8)  len=35
> TEI=127 Call Ref: len= 1 (reference 3/0x3) (Sent from originator)
> Message Type: SETUP (5)
> [04 03 90 90 a3]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: 3.1kHz audio (16)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                                User information layer 1: A-Law (35)
> [18 01 82]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit  BRI  Spare: 0  Preferred  Dchan: 0
>                       ChanSel: B2 channel
>                     ]
> [1e 02 80 83]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: User (0)
>                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
> [6c 08 21 81 34 31 34 36 37 34]
> Calling Number (len=10) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number passed network screening (1)  '414674' ]
> [70 07 a1 37 36 33 33 33 37]
> Called Number (len= 9) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '763337' ]
q931.c:4877 q931_setup: Call 32771 enters state 1 (Call Initiated).  Hold state: Idle
TEI: 75 State 5
V(S) 3 V(A) 3 V(R) 1
K 1, RC 0, l3initiated 1, reject_except 0 ack_pend 0
T200 1, N200 3, T203 0

Dans cet extrait on voit bien l'appel entrer et ressortir avec le même N° présenté (si mon analyse est correcte )

Le renvoi par déviation est différent du renvoi effectué ici par un dial suite au décrochage de l'appel, qu'on appelle renvoi par "aboutement"