Trunk Keyyo

hb22

Joined
Nov 18, 2008
Messages
38
Likes
0
Points
0
#1
J'enregistre chaque trunk Keyyo directement sur l'adresse IP d'un des proxy SIP :
83.136.161.72 => prx1.sip.keyyo.net
83.136.161.75 => prx2.sip.keyyo.net
83.136.162.72 => prx3.sip.keyyo.net
Cela fonctionne parfaitement.
Cette manière de faire c'est pour éviter des rétro-appels.
Voir ce lien :
http://www.asterisk-france.net/showthread.php?t=7018

Mais un proxy peut tomber et je ne profite pas de l'architecture Keyyo avec un enregistrement sur keyyo.net et les trois proxy derrières.

Un utilisateur de Elastix a t'il réussi à utiliser Keyyo en s'enregistrant sur keyyo.net et sans problème de rétro-appels ?
 

danardf

Joined
Dec 3, 2007
Messages
8,069
Likes
10
Points
88
#2
Hmmmm. comment as tu créés tes trunks?
J'ai eu des surprises du temps de phonesystems (Ex Keyyo).
 

hb22

Joined
Nov 18, 2008
Messages
38
Likes
0
Points
0
#3
Code:
[Keyyo1]
type=peer
username=3397476AAAA
accountcode=3397476AAAA
fromuser=3397476AAAA
fromdomain=keyyo.net
secret=mot_de_passe_de_AAAA
host=83.136.161.72
qualify=300
insecure=port,invite
canreinvite=no
nat=yes
disallow=all
allow=alaw

[3397476AAAA]
type=user
secret=mot_de_passe_de_AAAA
qualify=no
nat=yes
host=dynamic
context=from-trunk
canreinvite=no
disallow=all
allow=alaw

register=3397476AAAA:mot_de_passe_de_AAAA@83.136.161.72/3397476AAAA

[Keyyo2]
type=peer
username=3397476BBBB
accountcode=3397476BBBB
fromuser=3397476BBBB
fromdomain=keyyo.net
secret=mot_de_passe_de_BBBB
host=83.136.161.75
qualify=300
insecure=port,invite
canreinvite=no
nat=yes
disallow=all
allow=alaw

[3397476BBBB]
type=user
secret=mot_de_passe_de_BBBB
qualify=no
nat=yes
host=dynamic
context=from-trunk
canreinvite=no
disallow=all
allow=alaw

register=3397476BBBB:mot_de_passe_de_BBBB@83.136.161.75/3397476BBBB
 

danardf

Joined
Dec 3, 2007
Messages
8,069
Likes
10
Points
88
#4
Je suis matinal, non? :)

Je pense que tu devrais laisser vide la 2em partie du trunk (la partie user detail). A part foutre la mouise, je ne voie pas. :huh:

J'ai fais comme çà du temps de phonesystems. Et ça avait l'air de fonctionner. Keyyo n'on pas due changer la méthode à mon avis!

  • [Keyyo1]
    type=peer
    username=3397476AAAA
    accountcode=3397476AAAA
    fromuser=3397476AAAA
    fromdomain=keyyo.net
    secret=mot_de_passe_de_AAAA
    host=83.136.161.72
    qualify=300
    insecure=port,invite = very non ?
    canreinvite=no
    nat=yes
    disallow=all
    allow=alaw
    context=from-trunk

Donc rajouter le context from-trunk dans la première partie.

Et je pense que tu devrais rajouter srvlookup=yes dans sip_general.custom.conf

Essayes çà et tiens mois au courant. ;)
 

danardf

Joined
Dec 3, 2007
Messages
8,069
Likes
10
Points
88
#5
As-tu résolu ton problème?
 

hb22

Joined
Nov 18, 2008
Messages
38
Likes
0
Points
0
#6
J'ai un peu avancé concernant les retours d'appel :

La configuration actuel d'un trunk :

Trunk Name : O-3397476AAAA
username=3397476AAAA
type=peer
secret=mot_de_passe_de_3397476AAAA
qualify=400
nat=yes
insecure=very
host=keyyo.net
fromuser=3397476AAAA
fromdomain=keyyo.net
disallow=all
allow=alaw
canreinvite=no
accountcode=3397476AAAA
context=from-trunk
Le register :
3397476AAAA:mot_de_passe_de_3397476AAAA@keyyo.net/3397476AAAA
1) Avec srvlookup=no.
Réception d'un appel sur 3397476AAAA.
Début des logs de la CLI :

-- Executing [3397476AAAA@from-sip-external:1] NoOp("SIP/2.b2bua.sip.internal-0a0afef0", "Received incoming SIP connection from unknown peer to 3397476AAAA") in new stack
le "sip show channel 6f" pendant la conversation :

* SIP Call
Curr. trans. direction: Incoming
Call-ID: 6f47e79869b7128756b809440f065803@2.b2bua.sip.internal
Owner channel ID: SIP/2.b2bua.sip.internal-0a0afef0
Our Codec Capability: 8
Non-Codec Capability (DTMF): 1
Their Codec Capability: 8
Joint Codec Capability: 8
Format: 0x8 (alaw)
MaxCallBR: 384 kbps
Theoretical Address: 83.136.162.72:5060
Received Address: 83.136.162.72:5060
SIP Transfer mode: open
NAT Support: Always
Audio IP: 193.252.13.231 (local)
Our Tag: as0767b644
Their Tag: bb2d4e6ad7
SIP User agent: Keyyo B2BUA
Original uri: sip:3395489CCCC@192.168.21.54
Caller-ID: 3395489CCCC
Need Destroy: 0
Last Message: Rx: ACK
Promiscuous Redir: No
Route: sip:83.136.162.72;r2=on;lr;rb=1;rc=1;ie=1
DTMF Mode: rfc2833
SIP Options: replaces replace
Pas de Username et de Peername dans le "sip show channel"
Si l'appelé raccroche, La conversation continue du coté appelant.
L'appelant raccroche et un retour d'appel arrive sur l'appelé.

2) Avec srvlookup=yes.
Réception d'un appel sur 3397476AAAA.
Début des logs de la CLI :

-- Executing [3397476AAAA@from-trunk:1] Set("SIP/O-3397476AAAA-0896bfa0", "__FROM_DID=3397476AAAA") in new stack
le "sip show channel 64" pendant la conversation :

* SIP Call
Curr. trans. direction: Incoming
Call-ID: 64cd83d84cd50990766ca8ed4b86f8fa@2.b2bua.sip.internal
Owner channel ID: SIP/O-3397476AAAA-0896bfa0
Our Codec Capability: 8
Non-Codec Capability (DTMF): 1
Their Codec Capability: 8
Joint Codec Capability: 8
Format: 0x8 (alaw)
MaxCallBR: 384 kbps
Theoretical Address: 83.136.162.72:5060
Received Address: 83.136.162.72:5060
SIP Transfer mode: open
NAT Support: Always
Audio IP: 193.252.13.231 (local)
Our Tag: as159472f4
Their Tag: bb008be389
SIP User agent: Keyyo B2BUA
Username: 3397476AAAA
Peername: O-3397476AAAA
Original uri: sip:3395489CCCC@192.168.21.54
Caller-ID: 3395489CCCC
Need Destroy: 0
Last Message: Rx: ACK
Promiscuous Redir: No
Route: sip:83.136.162.72;r2=on;lr;rb=1;rc=1;ie=1
DTMF Mode: rfc2833
SIP Options: replaces replace
Il y a un Username et Peername dans le "sip show channel".
La conversation s'arrête du coté appelant si l'appelé raccroche.
L'appelant raccroche et aucun retour d'appel arrive sur l'appelé.
Donc c'est ok.

Mais aléatoirement j'ai la première ligne suivante dans la CLI :

-- Executing [3397476AAAA@from-trunk:1] Set("SIP/O-3397476BBBB-b770a208", "__FROM_DID=3397476AAAA") in new stack
C'est comme si un autre trunk Keyyo reçoit l'appel.
Dans ce cas, le Username et le Peername du "sip show channel" sont ceux de l'autre trunk.
Avant ce cas générait aussi des retours d'appel, ce n'est plus le cas de mes derniers essais.

Keyyo m'avait envoyé cette information :
Pour ce qui est du problème des rétro-appels, nous avons procédé à une évolution sur notre infrastructure (alignement des secrets sur les différents proxys). Un des effets de bords de cette upgrade pourrait être la résolution des problèmes de rétro-appels. Nous n'avons pas les moyens de valider ou non cette hypothèse.

Voilà mes derniers tests. J'ai laissé cette config chez un client. A suivre...
 

danardf

Joined
Dec 3, 2007
Messages
8,069
Likes
10
Points
88
#7
Bon ben si tu n'as plus de rétro-appel, c'est déjà bien.
Je vois que Keyyo par rapport à phonesystems n'a pas changer beaucoup.
J'ai galéré un max.
Lors que j'appelais un n° externe, su mon compte phonesystems j'avais 2 comm de décomptées sur ma facture (techniquement impossible), mais ça ne gênait pas le logiciel de taxation! Et le fait de mettre un context dand la première partie de la config du trunk, plus de problème.

Autre problème; des déconnexions de l'opérateur due au proxy SIP qui basculait de serveur de temps en temps. Et là, Asterisk n'aimait pas du tout. Le fait de relancer asterisk, ça refonctionnait.
 

hb22

Joined
Nov 18, 2008
Messages
38
Likes
0
Points
0
#8
Voilà mes derniers tests. J'ai laissé cette config chez un client. A suivre...
Et bien cela n'a pas fonctionné.
J'ai remis les IPs fixes.

Je suis en relation avec Keyyo pour monter une maquette Elastix chez eux afin de valider une configuration.
A suivre...
 

danardf

Joined
Dec 3, 2007
Messages
8,069
Likes
10
Points
88
#9
OK hb22.

C'est cool que tu puisses être en relation avec keyyo pour mettre en place une config seine.
Il y a des opérateurs qui ne feraient pas çà!

Merci et teins nous au courant.
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,902
Messages
130,887
Members
17,565
Latest member
omarmenichetti
Top