Despues tengo otro problemita con tos mi debug: Unable to set TOS to 184. Tengo en sip.conf bajo [general] tos=0×68. pero Asterisk parece que no quiere saber nada
De todas maneras Julian te agradesco mucho por predisposicion. Suerte

Johnny

Ahora bien, hay varios tipos de bridging:

Packet2packet es un modo light (en lo referente a recursos de CPU), en el que asterisk simplemente reenvía al otro peer los paquetes RTP que llegan, pero sin “procesarlos”… Es decir, no decodifica el audio.

Luego está el native bridge. Si los dos peers son SIP, y no hay nada que lo prohiba (canreinvite=no), asterisk intentará que los dispositivos se envíen audio directamente entre ellos.

Pero ojo, canreinvite=no tiene que estar definido en los dos peers si quieres que todo el audio pase por asterisk.

[peerA]
canreinvite=yes
…
[peerB]
canreinvite=no

Si asterisk conecta estos dos peers, lo que probablemente ocurrirá es que B enviará siempre su tráfico RTP a asterisk, pero recibirá directamente el tráfico RTP del peer A, ya que este tiene canreinvite=yes.

Tráfico RTP en ambos sentidos:
A-> B
B -> Asterisk -> A

Julian J. M.

patching file channels/chan_sip.c
Hunk #1 succeeded at 570 (offset 8 lines).
Hunk #2 succeeded at 1537 (offset 15 lines).
Hunk #3 succeeded at 15985 (offset 458 lines).
Hunk #4 succeeded at 17051 (offset 510 lines).
Hunk #5 succeeded at 17296 (offset 512 lines).
Hunk #6 succeeded at 17689 (offset 520 lines).
Hunk #7 succeeded at 17717 (offset 520 lines).
patching file include/asterisk/rtp.h
patching file main/rtp.c
Hunk #1 succeeded at 1551 (offset 10 lines).
Hunk #2 succeeded at 1622 (offset 10 lines).
Hunk #3 succeeded at 2861 (offset 53 lines).
Hunk #4 succeeded at 2869 (offset 53 lines).
Hunk #5 succeeded at 2892 with fuzz 1 (offset 54 lines).
Hunk #6 succeeded at 2924 (offset 54 lines).
Hunk #7 succeeded at 2938 (offset 54 lines).
Hunk #8 succeeded at 2948 (offset 54 lines).
Hunk #9 succeeded at 2971 (offset 54 lines).
Hunk #10 succeeded at 2985 with fuzz 2 (offset 55 lines).
Hunk #11 succeeded at 3032 (offset 65 lines).

De todas formas, el parche te aplicó sin problemas?

chan_sip.c:3814: error: too few arguments to function ’sip_set_rtp_peer’
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2

Gracias.

Estoy de acuerdo en que sería mucho más sencillo que asterisk se encargase de detectar el nat automáticamente, y en lo casos complicados, poder ponerselo a mano.

Personalmente me gustaría que hubiese algún método como en OpenSer, en el que detectas si el llamante/llamado están tras NAT (y comparas IP’s públicas) para decidir si el audio es directo o no.

Es decir, me gustaría que fuese algo dinámico en vez de tener que asumir en qué escenario va a estar permanentemente cada teléfono SIP.

Por lo demás, a ver si saco un rato esta semana y pruebo el parche.

Saludos.

A ver si alguien más lo prueba con éxito y lo subo al bugzilla.

Ahora bien, se podría además comparar las IP’s privadas de cada teléfono, y ver si pertenecen a la misma red. Podríamos suponer que están en una red de clase C (máscara de red 255.255.255.0, por ejemplo).

De todas formas, para escenarios complicados, lo mejor es un canreinvite=no

Muy interesante el parche! Pero tengo una dudilla: tu has planteado que si ambos están detrás de NAT, y si las IPs externas coinciden, podríamos haces que el audio fuese de uno a otro… Pero y si son subredes distintas no visibles entre ellas? y si hay “algo” en medio haciendo otro NAT, por ejemplo un AP WiFi o algo así?

No se, se me ocurre que en esos casos podría fallar la cosa, pero no se me ocurre como podría detectarse…