Trunk SIP, Appels Sortants : Son dans un seul Sens

[ffossard]

Pas si bizarre que ça, le fournisseur voip est l'opérateur, c'est même plutôt idéal !

Je ne vois pas de NAT non plus là-dedans, par contre les 2 ip sur le serveur Asterisk, c'est certainement ça qui pose problème, on a des ip en 192.168.4. dans les paquets SIP emis par les téléphones (et peut-être aussi asterisk malgré sa deuxième ip), qui viennent d'une ip en 37.1.1., on retrouve la problématique du nat.
Le fournisseur ne peut pas non plus mettre une ip en 192.168.4.x/24 sur le routeur du client, ça serait ingérable dans les tables de routage (si un autre client a un réseau en 192.168.4.0/24, ils font comment ?), ou alors il faudrait retomber sur un routeur NAT classique.

Un essai à faire: monte un petit asterisk avec un seul téléphone, tout ça en 37.1.1.x (serveur et téléphone), la même config pour le provider, et fait un essai.

Une question aussi, pourquoi impossible de faire évoluer le réseau, qu'est-ce qui bloque à côté de ça ?

[xre]

Merci pour votre aide.

- vérifier le bridiging : OK. C'est bon.
- "nat=no" : testé, ça change rien.

Voici deux tcpdump effectués sur le PABX, un sur l'interface locale (192.168.4) et un sur l'interface d'interco (37.1.1).

stream_lan.txt
stream_interco.txt

Toute la séquence est couverte : appel, sonnerie, décroche, raccroche.

J'ai du mal à voir ce qui cloche... Par contre on peut retrouver quelques codes de retour étranges, 401 ou bien 501. Cela peut-il être lié ?

Merci.

[jean]

le 501, c'est normal, c'est la réponse à un message option (probablement parce que qualify=yes)

effectivement, rien de choquant à priori


ce qu'il te faut, c'est déterminer d'abord si le son arrive sur ton serveur asterisk. il faut soit connecter un softphone sur le réseau 37, soit essayer de capturer les trames rtp sur le serveur, ou enregistrer sur le serveur (mixmonitor).

egalement, au niveau de ton archi, pourquoi ne mets tu pas un routeur nat (j'suis sérieux !). en effet, tu fais faire deux fonctions à ton serveur: voip pbx et routage. si tu déporte la fonction routage, tu te retrouves dans un schéma classique.

tjs en réflechissant au fur & à mesure que je tape, un test de softphone sur le réseau 192, avec les params directs du compte voip de ton fournisseur permettra de voir si le routage est bon

[xre]

Pas mieux avec un softphone.

J'ai l'impression qu'il y a un problème de routage entre 192.168.4.107 et 212.39.140.250. Comme on ne fait pas de NAT, comment est-ce que la réponse peut me revenir ?

Le téléphone a pour passerelle par défaut 192.168.4.1. Mais quid de la réponse ?

/edit Quelques infos supplémentaires :

pabx*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry
192.168.4.107    toto          7507cfee-ade0d5  0x100004 (ulaw|  No       Rx: ACK
212.39.140.250   0601020304       0f25884a715eee0  0x4 (ulaw)       No       Tx: ACK

pabx*CLI> sip show channel 7507cfee-ade0d5

  * SIP Call
  Curr. trans. direction:  Incoming
  Call-ID:                7507cfee-ade0d541@192.168.4.107
  Owner channel ID:       SIP/toto-0000a523
  Our Codec Capability:   209715199
  Non-Codec Capability (DTMF):   1
  Their Codec Capability:   1051917
  Joint Codec Capability:   1051917
  Format:                 0x100004 (ulaw|h263p)
  T.38 support            Yes
  Video support           No
  MaxCallBR:              384 kbps
  Theoretical Address:    192.168.4.107:5060
  Received Address:       192.168.4.107:5060
  SIP Transfer mode:      open
  NAT Support:            RFC3581
  Audio IP:               192.168.4.1 (local)
  Our Tag:                as2fca1e7c
  Their Tag:              ad75d80ae3cf0bd5o0
  SIP User agent:         Linksys/SPA942-5.2.8
  Username:               toto
  Peername:               toto
  Original uri:           sip:toto@192.168.4.107:5060
  Caller-ID:              133
  Need Destroy:           No
  Last Message:           Rx: ACK
  Promiscuous Redir:      No
  Route:                  sip:toto@192.168.4.107:5060
  DTMF Mode:              rfc2833
  SIP Options:            replaces replace
  Session-Timer:          Inactive

* SIP Call
  Curr. trans. direction:  Outgoing
  Call-ID:                0f25884a715eee0e6cbce51116f92936@37.1.1.1
  Owner channel ID:       SIP/altitude-output-0000a524
  Our Codec Capability:   4
  Non-Codec Capability (DTMF):   1
  Their Codec Capability:   4
  Joint Codec Capability:   4
  Format:                 0x4 (ulaw)
  T.38 support            Yes
  Video support           No
  MaxCallBR:              384 kbps
  Theoretical Address:    212.39.140.250:5060
  Received Address:       212.39.140.250:5060
  SIP Transfer mode:      open
  NAT Support:            RFC3581
  Audio IP:               37.1.1.1 (local)
  Our Tag:                as13cb5fe4
  Their Tag:              00-07211-091afcfc-6699cf882
  SIP User agent:
  Username:               0601020304
  Peername:               altitude-output
  Original uri:           sip:212.39.140.250:5060
  Need Destroy:           No
  Last Message:           Tx: ACK
  Promiscuous Redir:      No
  Route:                  sip:212.39.140.250:5060
  DTMF Mode:              rfc2833
  SIP Options:            (none)
  Session-Timer:          Inactive

Le problème : "toto" peut entendre la personne extérieure, mais la personne extérieure n'entend pas "toto".

C'est normal que "Audio IP" soit l'IP du PABX dans les deux cas ?

Merci beaucoup.

[jean]

si pbm de softphone sur le réseau 192 avec les param de ton provider sip, c'est donc du routage a mon sens et asterisk est inocent pour le coup !

just in case, tu peux faire un test d'écho entre ton client en 192 et ton asterisk, avec l'appli echo()

les chemins se font entre les deux machines (192 et sip provider) par du routage ip classique....

http://www.amazon.fr/D-Link-Ethernet...2507573&sr=8-2 ou un truc approchant

ne serait ce pas la solution ?

[xre]

Je me suis mal exprimé.

J'ai enregistré mon softphone auprès de notre Asterisk et j'ai tenté de passer un appel. Même résultat qu'avec un téléphone physique.

Il ne va pas m'être possible de tester avec les paramètres du fournisseur (en mettant mon softphone en 37.x) puisqu'il n'y a pas d'enregistrement auprès du fournisseur. Il n'est donc pas possible d'enlever notre Asterisk de la boucle.

Est-ce que le sip show channel sur le flux sortant ne nous aide pas ?

[ffossard]

Je me suis mal exprimé.

J'ai enregistré mon softphone auprès de notre Asterisk et j'ai tenté de passer un appel. Même résultat qu'avec un téléphone physique.

Il ne va pas m'être possible de tester avec les paramètres du fournisseur (en mettant mon softphone en 37.x) puisqu'il n'y a pas d'enregistrement auprès du fournisseur. Il n'est donc pas possible d'enlever notre Asterisk de la boucle.

Est-ce que le sip show channel sur le flux sortant ne nous aide pas ?

Et en testant avec un autre asterisk (même dans une vm) en 37.1.1.x et un téléphone en 37.1.1.x lui aussi ?

[ffossard]

Pas mieux avec un softphone.

J'ai l'impression qu'il y a un problème de routage entre 192.168.4.107 et 212.39.140.250. Comme on ne fait pas de NAT, comment est-ce que la réponse peut me revenir ?

Le téléphone a pour passerelle par défaut 192.168.4.1. Mais quid de la réponse ?

C'est ce que je pense, le réseau 192.168.4.0 est inconnu du fournisseur, il est possible que la réponse ne revienne pas.
Y'a-t-il du "192.168.4.x" dans des paquets envoyés par Asterisk au fournisseur voip ?