Tráfico RTP directo entre dos softphone
Laura
para conseguir que el tráfico RTP vaya directo entre dos softphones
sin pasar por asterisk con trixbox en interfaz web hay que poner en
Dial options "tr" y en cada extension sip canreinvite=yes. Alguien me
puede decir donde y como cambiar el Dial Options con ficheros de
configuración en lugar de con interfaz web.
Gracias
Laura
Si lo cambio de la forma
exten=>juan,1,Dial(SIP/troncal1/juan,30,tr)
para cada extensión SIP, no me funciona.
Iñaki Baz Castillo
No pongas la t:
t - Allow the called party to transfer the calling party by sending the
DTMF sequence defined in the blindxfer setting in the featuremap
section of features.conf.
Si pones la t el audio pasará SIEMPRE por Asterisk (salvo que hayas
ocnfigurado los peers/friends con rtfmode=info).
Si tus terminales soportan transferencia SIP te recomiendo que quites la t ya
sólo sirve para permitir la transferencia por DTMF nativa de Asterisk.
--
Iñaki Baz Castillo
<ib...@xtratelecom.es>
Jose Luis
t, no ponerla.
Iñaki Baz Castillo escribió:
Laura
softphone:
11:33:09.586 strm0x9c8656c Bad RTP pt 0 (expecting 3)
11:33:09.586 strm0x9c8656c Changed RTP peer SSRC 1674063364
(previously 754974826)
11:33:09.587 strm0x9c8656c Bad RTP pt 0 (expecting 3)
11:33:09.598 sound_port.c EC activated
11:33:09.618 strm0x9c8656c Bad RTP pt 0 (expecting 3)
11:33:09.631 ec0x9c51f98 Buffer size adjusted from 1249 to 770
(eff_cnt=741)
Jose Luis
Laura escribió:
Adrià Vidal
Si en lugar de "tr" pongo "r" me aparece el siguiente error en el
softphone:
El ring tampoco acostumbra a ser muy interesante ponerlo, acostumbra a ser una fuente de problemas más que de soluciones....
--
--
Adrià Vidal
adria...@gmail.com
Saúl Ibarra
La r genera un ringtone falso...
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
Germán Aracil Boned
Saúl Ibarra escribió:
> Porqué quieres la r?
>
> La r genera un ringtone falso...
>
>
>
--
-
-------------------------------------
Germán Aracil Boned
Director de Sistemas
Zoon Suite S.L.
www.zoonsuite.com
963146030 - General
963146031 - Asistencia de incidencias
963146032 - FAX
-------------------------------------
-
Laura
dejando el campo option del Dial con ninguna opción. Os cuento el
escenario con el que estoy trabajando haber si estoy cometiendo algún
otro error.
En mi escenario de trabajo cuento con distintas subredes. En cada
subred existen distintos softphones (pjsua) que se registran en
opensips. Opensips redirige el tráfico a asterisk que se encuentra en
otra subred aislado. Y quiero que el tráfico RTP entre dos softphones
de distintas subredes sea directo sin pasar por asterisk. Para ello en
cada extension sip he puesto canreinvite=yes y en las opciones del
Dial no he puesto nada. Es posible abordar esta solución.
Elproblema es que en cuanto quito la "t" del Dial option me aparece el
error anteriormente mencionado. Que otra opción me podría ayudar a
realizar lo que quiero.
Saúl Ibarra
probado a poner directrtpsetup=yes? Ten en cuenta de que para que el
audio vaya directo Asterisk tiene que saber llegar a las 2
extensiones...
Jose Luis
por el * ambos han de utilizar el mismo codec. En el momento que hay
codecs diferentes interviene el *. Comprueba esto...
No conozco como funciona el opensips, pero mira primero lo que te he
comentado.
Saludos.
Laura escribió:
Laura
He probado con directrtpsetup=yes pero tampoco funciona.
En principio yo creo que no hay ningún problema para que el audio sepa
llegar a las dos extensiones y que el codec utilizado es el mismo en
los dos teléfonos.
Iñaki Baz Castillo
> No hay manera de solucionarlo, me sigue dando el mismo error aún
> dejando el campo option del Dial con ninguna opción. Os cuento el
> escenario con el que estoy trabajando haber si estoy cometiendo algún
> otro error.
Asegúrate de que no haya problema de codecs. Puesto que Asterisk no debe
intervenir en el RTP por "allow=all" en ambos peers/friends.
> En mi escenario de trabajo cuento con distintas subredes. En cada
> subred existen distintos softphones (pjsua) que se registran en
> opensips. Opensips redirige el tráfico a asterisk que se encuentra en
> otra subred aislado. Y quiero que el tráfico RTP entre dos softphones
> de distintas subredes sea directo sin pasar por asterisk. Para ello en
> cada extension sip he puesto canreinvite=yes y en las opciones del
> Dial no he puesto nada. Es posible abordar esta solución.
Sí.
> Elproblema es que en cuanto quito la "t" del Dial option me aparece el
> error anteriormente mencionado.
Debe ser tema de codecs.
Laura
prioridad, eso me ahce pensar que no tengo problema de codecs, pero a
lo mejor estoy equivocada. Como aparece a continuación:
List of codecs:
130 speex/16000/1
129 speex/8000/1
128 speex/32000/1
128 iLBC/8000/1
128 GSM/8000/1
128 PCMU/8000/1
128 PCMA/8000/1
128 G722/16000/1
0 L16/44100/1
0 L16/44100/2
0 L16/8000/1
0 L16/8000/2
0 L16/11025/1
0 L16/11025/2
0 L16/16000/1
0 L16/16000/2
0 L16/22050/1
0 L16/22050/2
0 L16/32000/1
0 L16/32000/2
0 L16/48000/1
0 L16/48000/2
Iñaki Baz Castillo
> En ambos teléfonos tengo los codecs situados en el mismo orden de
> prioridad, eso me ahce pensar que no tengo problema de codecs, pero a
> lo mejor estoy equivocada. Como aparece a continuación:
Asterisk es un B2BUA que se entromete en el SDP y la negociación de codecs.
NO basta con que los tfnos soporten los mismos codecs, también debes
configurar los respectivos friends/peers en Asterisk para que los soporten,
por eso te decía que pongas "allow=all" en los friends de los usuarios en
Asterisk.
Germán Aracil Boned
Prueba un disallow=all y un allow=elquequierasusar.
Laura escribió:
Iñaki Baz Castillo
> El problema de codecs te lo dará asterisk.
> Prueba un disallow=all y un allow=elquequierasusar.
puesto que Asterisk no va a intervenir en el audio, mejor que no meta la zarpa
y no limite innecesariamente. Por ello yo propongo:
allow=all
y a correr :)
Laura
Estaba equivocada, aunque están en la misma posición de prioridad los
codecs cada teléfono está eligiendo un condec, como se muestra a
continuación:
Teléfono llamanate:
v=0
o=- 3449212550 3449212551 IN IP4 192.168.0.55
s=pjmedia
c=IN IP4 192.168.0.55
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 3 101
a=rtcp:4001 IN IP4 192.168.0.55
a=rtpmap:3 GSM/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Teléfono llamado:
v=0
o=- 3449212550 3449212552 IN IP4 192.168.0.53
s=pjmedia
c=IN IP4 192.168.0.53
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 0 101
a=rtcp:4001 IN IP4 192.168.0.53
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Ahora tendré que averiguar como hacer que los dos teléfonos se queden
con el mismo codec.
Admito sugerencias.
Gracias
Laura
Tengo puesto allow=all
Germán Aracil Boned
luego reload, registras de nuevo los teléfonos, llamas y me cuentas..
Laura escribió:
Germán Aracil Boned
g729, para probar.
Iñaki Baz Castillo escribió:
> El Monday 20 April 2009 12:50:19 Germán Aracil Boned escribió:
>> El problema de codecs te lo dará asterisk.
>> Prueba un disallow=all y un allow=elquequierasusar.
>
> puesto que Asterisk no va a intervenir en el audio, mejor que no meta la zarpa
> y no limite innecesariamente. Por ello yo propongo:
>
> allow=all
>
> y a correr :)
>
>
--
Laura
Germán Aracil Boned
Laura escribió:
Germán Aracil Boned
Pero quiero advertirte de alguna cosa, o aconsejar un poco:
Nunca dejes que asterisk tenga demasiados codecs con los que negociar.
Lo hace FATAL. Por tanto, te recomendaría no poner nunca allow=all eso
es un problema potencial.
Puedes usar varios codecs, pero hazlo con "sigilo", por ejemplo:
disallow=all
allow=gsm
allow=alaw
allow=ulaw
..
en orden y bien posicionados en todos los peers/friends. Es más yo lo
pondría en el apartado general, y solo en los peers/friends donde
quieras algo diferente, lo indicas poniendo el orden/codecs que requiera
ese peer.
Cualquier otra forma de hacerlo, es un problema.
Si los teléfonos tienen g729, no tiene porque tenerlo asterisk, puedes
poner allow=g729, mientras no haga transcoding, todo te funcionará a la
perfección. Includidas versiones más avanzadas del g729a que es el único
que soporta asterisk. El simplemente deja pasar el audio, o en tu caso,
in cluso ni pasa por el, pero debe saber que ese codec es negociable.
Esto son mis resultados prácticos sobre el tema, y la verdad es que no
tengo ningún problema de codecs.
Laura escribió:
Iñaki Baz Castillo
> Perdona.. estaba haciendo ternera guisada :)
>
> Pero quiero advertirte de alguna cosa, o aconsejar un poco:
>
> Nunca dejes que asterisk tenga demasiados codecs con los que negociar.
> Lo hace FATAL. Por tanto, te recomendaría no poner nunca allow=all eso
> es un problema potencial.
Vaya, me lo creo totalmente pero no alcanzo a entenderlo...
Si pones "allow=all", ¿no se supoen que Asterisk debería molestar mucho menos?
(sobre todo teniendo en cuenta que va a ser audio directo)
Saúl Ibarra
Laura
El caso es que ahora se hace el establecimiento normal de la llamada,
y luego realiza otro reestablecimiento con el llamante y dos con el
llamado. El que haga un reestablecimiento puedo más o menos entenderlo
pero el que haga dos???
Ahora lo que me ocurre es que no aparece tráfico RTP aún teniendo los
teléfonos desactivada la supresión de silencios. Estos teléfonos
(pjsua) además, tienen la posibilidad de que cuando reciben una
llamada reproduzcan un fichero de audio de caracteristicas: File MUST
be single channel/mono, 16bit signed PCM, with any sampling rate. Si
quiero que se reproduzca este fichero tendré que usar algún codec en
especial como PCM o valdrá cualquiera?? He provado con PCM pero me da
error en asterisk: bad codec.
Laura
Raúl Alexis Betancor Santana
Te voy a contar un pequeño, pequeño secreto a cerca de la negociación de
codecs de Asterisk ... NO FUNCIONA.
Si la pata A dice ...
1 GSM
2 PCMU
3 G729
Y cuando Asterisk "crea" la pata B en el Dial, por el orden que tenga de carga
de los módulos de los codecs, etc, etc, manda :
1 G729
2 PCMU
3 GSM
¿Adivinas lo que pasa, aunque tengas canreinvite y ostias?
Saludos
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Iñaki Baz Castillo
> > Vaya, me lo creo totalmente pero no alcanzo a entenderlo...
> > Si pones "allow=all", ¿no se supoen que Asterisk debería molestar mucho
> > menos? (sobre todo teniendo en cuenta que va a ser audio directo)
>
> Te voy a contar un pequeño, pequeño secreto a cerca de la negociación de
> codecs de Asterisk ... NO FUNCIONA.
>
> Si la pata A dice ...
>
> 1 GSM
> 2 PCMU
> 3 G729
>
> Y cuando Asterisk "crea" la pata B en el Dial, por el orden que tenga de
> carga de los módulos de los codecs, etc, etc, manda :
>
> 1 G729
> 2 PCMU
> 3 GSM
>
Ilústrame... ¿¿qué pasa??
> aunque tengas canreinvite y ostias?
Que yaha canreinvite o no da igual, ya que durante el establecimiento de
*ambos* canales Asterisk interviene en el media path (aunque tras el
establecimiento envíe un re-INVITE a cada pata con el SPD del respectivo
remoto).
Pero "se supone" que con la opción "directrtp" (la única vez que me dio por
probarla cascaba Asterisk al instante) Asterisk no debería ni investigar los
codecs... mucho me temo que no es así...
Iñaki Baz Castillo
Llegados a este punto te sugiero que hagas capturas SIP e inspecciones las
direcciones en los SDP, a ver "qué pasa".
Germán Aracil Boned
Iñaki Baz Castillo escribió:
--
Raúl Alexis Betancor Santana
> Un transcoding como la copa de un pino, me temo.
¡Premio para el caballero! ... puede usted elegir ente le perrito piloto o la
bailarina de la caja de música ...
Raúl Alexis Betancor Santana
> El Monday 20 April 2009 14:22:29 Raúl Alexis Betancor Santana escribió:
> > > Vaya, me lo creo totalmente pero no alcanzo a entenderlo...
> > > Si pones "allow=all", ¿no se supoen que Asterisk debería molestar mucho
> > > menos? (sobre todo teniendo en cuenta que va a ser audio directo)
> >
> > Te voy a contar un pequeño, pequeño secreto a cerca de la negociación de
> > codecs de Asterisk ... NO FUNCIONA.
> >
> > Si la pata A dice ...
> >
> > 1 GSM
> > 2 PCMU
> > 3 G729
> >
> > Y cuando Asterisk "crea" la pata B en el Dial, por el orden que tenga de
> > carga de los módulos de los codecs, etc, etc, manda :
> >
> > 1 G729
> > 2 PCMU
> > 3 GSM
> >
> > ¿Adivinas lo que pasa?
>
> Ilústrame... ¿¿qué pasa??
Que Asterisk como "genera" un SDP "nuevo", se la suda el orden de los codecs
en el SDP A, y claro .. si luego la pata B contesta que "200 OK, G729" ...
Asterisk "inspecciona" el SDP A y manda GSM en la respuesta a la pata A,
porque Asterisk tiene "transcoding path" entre GSM y G729
Y da igual que luego mande el "re-INVITE", si el dispositivo no acepta el re-
INVITE (y los hay que no lo aceptan), Asterisk ya se ha quedado en el media-
path .. te guste o nó, y encima haciendo transcoding.
Esto lo he visto en varias instalaciones .. y se montan unos pifostios de
cuidado.
Laura
No entiendo que es eso del transcoding, me lo podeís explicar? y cómo
se puede solucionar?
Saúl Ibarra
configuras ambos terminales para que usen el mismo codec esto no será
necesario y ahorraras recursos en tu sistema, ademas de permitir el
RTP directo...
2009/4/20 Laura <lebo...@gmail.com>:
>
> No entiendo que es eso del transcoding, me lo podeís explicar? y cómo
> se puede solucionar?
> >
>
Laura
On 20 abr, 16:49, Saúl Ibarra <sag...@gmail.com> wrote:
> El transcoding significa la conversión de un codec a otro. Si
> configuras ambos terminales para que usen el mismo codec esto no será
> necesario y ahorraras recursos en tu sistema, ademas de permitir el
> RTP directo...
>
Yo, como me han dicho anteriormente, he configurado asterisk para que
use un codec determinado:
disallow=all
allow=GSM
Y los teléfonos, eligen ese codec bien
v=0
o=- 3449226506 3449226499 IN IP4 192.168.0.53
c=IN IP4 192.168.0.53
t=0 0
a=X-nat:0
a=rtcp:4005 IN IP4 192.168.0.53
Germán Aracil Boned
Eso sucede con la excelente negociación de asterisk, cuando por ejemplo
pones allow=all
Porque como dice raúl, no funciona.
Vas mejorando la situación ?¿ Sigues con problemas ?¿?
Laura escribió:
Laura
El problema que tengo ahora mismo es que si en dial options no pongo
ninguna opción el tráfico RTP no aparece, sólo aparece el RTPD. Y no
sé que opción poner para que me funcione todo bien.
Paco Gil
El problema que tengo ahora mismo es que si en dial options no pongo
ninguna opción el tráfico RTP no aparece, sólo aparece el RTPD. Y no
sé que opción poner para que me funcione todo bien.
--
http://ualtech.wordpress.com
Saúl Ibarra
Laura
Si que he hecho capturas, de echo por eso sé que no existe tráfico
RTP.
El problemas es la opeciones del Dial options, porque si pongo la "t"
ese tráfico aparece pero no a sin pasar por asterisk que es lo que
quiero. Anteriormente, ya me han dicho que no use la "t" pues me
impone que el tráfico no pase por asterisk. Entonces no sé que opción
poner para que todo vaya correctamente, estoy haciendo pruebas con
algunas opciones, pero por ahora no me soluciona el problema ninguna.
Saúl Ibarra
por asterisk, no?
Entonces cual es el problema? No se oye nada entre los pjsuas?
Laura
puedo comprobar que se oye algo o no porque estoy trabajando con
remoto en un servidor al que no tengo acceso real, pero en las
capturas si que puedo comprobarlo viendo el tráfico RTP. Y en cuanto
no pongo la "t" en dial options ese tráfico desaparece. Y si pongo la
t, el tráfico pasa por asterisk. Entonces, no sé cuál puede ser la
solución. He probado a poner en cada extension sip, rtfmode=info, como
anteriormente me habían dicho pero no me soluciona nada.
Saúl Ibarra
hosts con PJSUA?
Captura el tráfico SIP en el asterisk para ver los SDP...
Iñaki Baz Castillo
Hola, era dtmfmode=info, y no rtfmode.
Por otra parte, eso sólo sirve para que si llamas con la "t" en el Dial,
entonces Asterisk NO obligue al audio a pasar por él. Si usases
dtmfmode=rfc2833 o inband, entonces al poner la "t" Asterisk se come el audio
sí o sí. Nada más.
Como te comentaba, NO pongas la "t", que sólo sirve para la transferencia ñapa
de Asterisk usando DTMF. En su lugar haz transferencia SIP de los tfnos.
Dices que los endpoints son PJsua, por lo que corren (entiendo) en un Linux
(con mala suerte en un Windows). Si es Linux instala en cada equipo el
paquete iftop que sirve para ver el tráfico de red en "bonito".
Raúl Alexis Betancor Santana
La cuestión que has de hacer las capturas en los "lugares extratégicos",
dicese en los UAC's ó en routers intermedios por lo que pase ese tráfico.
Es normal que si le quitas las dial options no veas el RTP, al fin y al cabo
es el objetivo que perseguías, que el RTP no pasase por el Asterisk.
Ahora te falta verificar que el RTP vá directo del UAC1 al UAC2
Saludos
Iñaki Baz Castillo
por cierto, ¿no estarán los UA detrás de NAT's diferentes?
Laura
- Los pjsua que utilizo son Linux.
- ¿Hay alguan opción para hacer transferencia SIP de los tfnos?
- La captura no la estoy realizando en asterisk, sino en puntos por
los que pasaría el tráfico RTP aunque este no pasase por asterisk.
- Únicamente en cada teléfono aparece una regla iptables para que todo
el tráfico SIP lo redirija a su opensip correspondiente.
Raúl Alexis Betancor Santana
No me la compliques antes de tiempo ... según uno de sus primeros mails .. las
sedes estaban interconectadas "sin problemas" ...
Raúl Alexis Betancor Santana
> Vayamos por partes.
> - Los pjsua que utilizo son Linux.
Ok
> - ¿Hay alguan opción para hacer transferencia SIP de los tfnos?
Si es un dispositivo SIP y tiene "botón" de transfer ... pues ya
> - La captura no la estoy realizando en asterisk, sino en puntos por
> los que pasaría el tráfico RTP aunque este no pasase por asterisk.
Ok, ¿estas segura de que son los sitios adecuados?
> - Únicamente en cada teléfono aparece una regla iptables para que todo
> el tráfico SIP lo redirija a su opensip correspondiente.
Esto ma matao ... ¿para que necesitas reglas de iptables para redigir
tráfico? ... eso tiene pinta de que tu escenario SIP global no está bien
diseñado.
Germán Aracil Boned
prueba progressinband=yes
Laura .. ahora que releo, no querías precisamente que no apareciera por
asterisk y fuera entre los teléfonos ?
Laura escribió:
>
> El problema que tengo ahora mismo es que si en dial options no pongo
> ninguna opción el tráfico RTP no aparece, sólo aparece el RTPD. Y no
> sé que opción poner para que me funcione todo bien.
> >
>
Laura
>
> > - La captura no la estoy realizando en asterisk, sino en puntos por
> > los que pasaría el tráfico RTP aunque este no pasase por asterisk.
>
> Ok, ¿estas segura de que son los sitios adecuados?
> > - Únicamente en cada teléfono aparece una regla iptables para que todo
> > el tráfico SIP lo redirija a su opensip correspondiente.
>
> Esto ma matao ... ¿para que necesitas reglas de iptables para redigir
> tráfico? ... eso tiene pinta de que tu escenario SIP global no está bien
> diseñado.
>
por el opensip que está registrado y yo quiero que primero pase por el
opensip que está registrado y después al asterisk para después ir al
opensips del llamado.
Laura
On 20 abr, 19:27, Germán Aracil Boned <ger...@tecnoxarxa.com> wrote:
> Te refieres a los tonos de llamada ?
>
> prueba progressinband=yes
>
> Laura .. ahora que releo, no querías precisamente que no apareciera por
> asterisk y fuera entre los teléfonos ?
asterisk ni por los softphones, es decir, por ningún sitio.
En fin, que jaleo.
Raúl Alexis Betancor Santana
Ergo tu escenario SIP está tremendamente mal montado, por lo menos para el
routing SIP que quieres montar
Raúl Alexis Betancor Santana
Tendrás que comprobar los SDP y ver por donde se está yendo el RTP
Laura
On 20 abr, 20:05, Raúl Alexis Betancor Santana <r...@dimension-
>
> - Mostrar texto de la cita -
Germán Aracil Boned
- Mirar esquema del escenario físico, detallado: Puestos y distribución.
- Conectividad existente entre redes ya existentes, con datos detallados
como flujo de datos y su estabilidad.
De ahí, podemos sacar:
- Necesidad de ampliar/modificar redes existentes para coexistir con voip.
- Dimensionar, servidores para dar servicio
- Estudio de la configuración software de los mismos más idónea:
Openser, asterisk ¿ donde y por qué ?
Pero lo siguiente sería un presu jajajaja ;)
es coña.
Laura escribió:
Saúl Ibarra
Deberías comprobar la configuración de los OpenSIPS... haces
record-routing de los INVITE/SUBSCRIBE? De esta manera el OpenSIPS que
hace de registrar para el pjsua A se quedará en medio del path de
señalización cuando llames al openSIPS del pjsua B...
Laura
REGISTER|MESSAGE, es equivalente al INVITE|SUBSCRIBE o no? Con esto,
los mensajes no iban al opensips donde esta registrado a menos que
pusiese la regla iptables que redirige el tráfico del teléfono al
opensips donde se registra. A lo mejor este es el problema.
A continuación adjunto mi fichero de configuración de opensips.
####### Global Parameters #########
debug=3
log_stderror=no
log_facility=LOG_LOCAL0
fork=yes
children=4
port=5060
####### Modules Section ########
#set module path
mpath="/usr/local/lib/opensips/modules/"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "mi_fifo.so"
loadmodule "uri_db.so"
loadmodule "uri.so"
loadmodule "xlog.so"
loadmodule "acc.so"
# ----------------- setting module-specific parameters ---------------
# ----- mi_fifo params -----
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
# ----- rr params -----
# add value to ;lr param to cope with most of the UAs
modparam("rr", "enable_full_lr", 1)
# do not append from tag to the RR (no need for this script)
modparam("rr", "append_fromtag", 0)
# ----- rr params -----
modparam("registrar", "method_filtering", 1)
# ----- uri_db params -----
/* by default we disable the DB support in the module as we do not
need it
in this configuration */
modparam("uri_db", "use_uri_table", 0)
modparam("uri_db", "db_url", "")
# ----- acc params -----
/* what sepcial events should be accounted ? */
modparam("acc", "early_media", 1)
modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
/* by default ww do not adjust the direct of the sequential requests.
if you enable this parameter, be sure the enable "append_fromtag"
in "rr" module */
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "log_flag", 1)
modparam("acc", "log_missed_flag", 2)
/* uncomment the following lines to enable DB accounting also */
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
# ----- usrloc params -----
modparam("usrloc", "db_mode", 0)
####### Routing Logic ########
# main request routing logic
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction fails
}
route(1);
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful ACK; must be an ACK after a 487
or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction ... ignore and discard.\n");
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
#initial requests
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
t_check_trans();
# record routing
if (!is_method("REGISTER|MESSAGE"))
record_route();
# account only INVITEs
if (is_method("INVITE")) {
setflag(1); # do accounting
}
if (!uri==myself)
route(1);
}
if (is_method("PUBLISH"))
{
sl_send_reply("503", "Service Unavailable");
exit;
}
if (is_method("REGISTER"))
{
if (!save("location"))
sl_reply_error();
exit;
}
if ($rU==NULL) {
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
if (!lookup("location")) {
switch ($retcode) {
case -1:
case -3:
t_newtran();
t_reply("404", "Not Found");
exit;
case -2:
sl_send_reply("405", "Method Not Allowed");
exit;
}
}
# when routing via usrloc, log the missed calls also
setflag(2);
route(1);
route(3);
}
route[1] {
# for INVITEs enable some additional helper routes
if (is_method("INVITE")) {
t_on_branch("2");
t_on_reply("2");
t_on_failure("1");
}
if (!t_relay()) {
sl_reply_error();
};
exit;
}
branch_route[2] {
xlog("new branch at $ru\n");
}
onreply_route[2] {
xlog("incoming reply\n");
}
failure_route[1] {
if (t_was_cancelled()) {
exit;
}
}
Saúl Ibarra
una captura SIP en el lado de un pjsua: ngrep -d any W byline -T -P ''
port 5060
Raúl Alexis Betancor Santana
> En el fichero de configuración de opensips hago record-route de los
> REGISTER|MESSAGE, es equivalente al INVITE|SUBSCRIBE o no? Con esto,
> los mensajes no iban al opensips donde esta registrado a menos que
> pusiese la regla iptables que redirige el tráfico del teléfono al
> opensips donde se registra. A lo mejor este es el problema.
> A continuación adjunto mi fichero de configuración de opensips.
Esta no es una lista sobre opensips/kamailio ... pero respondiendo a tu
pregunta, NO, REGISTER y MESSAGE no son equivalentes a INVITE y SUBSCRIBE,
cada tipo de mensaje tiene su significado y su utilidad.
En respuesta a lo otro que preguntas, SI, tienes mal el archivo de
configuración de opensips, puesto que los mensajes INVITE SI debes de
pasarlos por record-route y loose_route, por eso tienes que hacer la "ñapa"
del iptables.
Si quieres aprender a configurar correctamente un proxy SIP como opensips, te
recomiendo encarecidamente que primero aprendas los fundamentos de SIP, tipos
de mensajes, call-flow's de cada uno, etc. sino lo vas a sufrir de lo lindo.
Saludos
Raúl Alexis Betancor Santana
> En principio no veo nada raro en esa configuración de OpenSIPS... haz
> una captura SIP en el lado de un pjsua: ngrep -d any W byline -T -P ''
> port 5060
Ale que no tiene "cosas raras" ... XDD
Iñaki Baz Castillo
> - ¿Hay alguan opción para hacer transferencia SIP de los tfnos?
PJsip lo implementa a nivel de librería, desde luego.
> - La captura no la estoy realizando en asterisk, sino en puntos por
> los que pasaría el tráfico RTP aunque este no pasase por asterisk.
¿¿Pero el audio no era directo entre los terminales??
> - Únicamente en cada teléfono aparece una regla iptables para que todo
> el tráfico SIP lo redirija a su opensip correspondiente.
Esto no tiene sentido y sólo puede fallar.
Iñaki Baz Castillo
> > Esto ma matao ... ¿para que necesitas reglas de iptables para redigir
> > tráfico? ... eso tiene pinta de que tu escenario SIP global no está bien
> > diseñado.
>
> Si no hago eso el teléfono busca el opensips del llamante sin pasar
> por el opensip que está registrado y yo quiero que primero pase por el
> opensip que está registrado y después al asterisk para después ir al
> opensips del llamado.
Para cosas como éstas, cualquier tfno SIP que se precie tiene la
opción "outboundproxy". Pon ahí la dirección del proxy al que quieres que el
terminal envíe *siempre* el tráfico SIP y allí lo mandará sea el dominio que
sea.
Iñaki Baz Castillo
> Germán, creo que se refiere al routing SIP mayormente...
>
> Deberías comprobar la configuración de los OpenSIPS... haces
> record-routing de los INVITE/SUBSCRIBE? De esta manera el OpenSIPS que
> hace de registrar para el pjsua A se quedará en medio del path de
> señalización cuando llames al openSIPS del pjsua B...
No no, 100% seguro de que lo que necesita es configurar la
opción "outboundproxy" en los tfnos.
Saúl Ibarra
registrado, by default...
Laura
>
> No no, 100% seguro de que lo que necesita es configurar la
> opción "outboundproxy" en los tfnos.
>
así consigo ahora lo del tráfico directo entre teléfonos sin ningún
problema.
En fin, cuando no te funcionan las cosas haces apaños para arreglarlo
pero que luego te dan problemas por otros lados.
Gracias a todos.
Germán Aracil Boned
Estupendo !!!!!!!!!!
Laura escribió:
Iñaki Baz Castillo
Un consejo: NUNCA trates de hacer ñapas con Iptables para "solucionar" temas
de routing SIP.
Laura
Al capturar con tcpdump no veo el tráfico rtp al establecer una
llamada, y en los teléfonos tengo desactivada la supresión de
silencios para que aunque no hable nadie haya tráfico.
En asterisk tengo la siguiente configuración:
sip.conf
[general]
disallow=all
allow=GSM
[troncal1]
type=friend
host=192.168.1.54
context=from-opensip
insecure=invite
canreinvite=yes
[troncal2]
type=friend
host=192.168.2.56
context=from-opensip
insecure=invite
canreinvite=yes
;#Usuarios registrados en opensips
[pepe](troncal2)
username=pepe
fromuser=pepe
[juan](troncal1)
username=juan
fromuser=juan
extensions.conf
[default]
[from-opensip]
;usuarios opensip1
exten=>juan,1,Dial(SIP/troncal1/juan,30)
exten=>juan,2,Hangup
;usuarios opensip2
exten=>pepe,1,Dial(SIP/troncal2/pepe,30)
exten=>pepe,2,Hangup
Las direcciones corresponden a:
192.168.1.53 y 192.168.2.55 son pjsuas
192.168.1.54 y 192.168.2.56 son opensips
192.168.9.52 es asterisk
El problema esta en la configuración del dial options, porque si pongo
como opción "t", si que hay tráfico RTP pero, como ya dijimos
anteriormente, este tráfico pasa a través de asterisk. Esto me esta
volviendo de cabeza, porque no sé como resolverlo.
Adrià Vidal
El problema esta en la configuración del dial options, porque si pongo
como opción "t", si que hay tráfico RTP pero, como ya dijimos
anteriormente, este tráfico pasa a través de asterisk. Esto me esta
volviendo de cabeza, porque no sé como resolverlo.
--
--
Adrià Vidal
Laura
> --
> --
> Adrià Vidal
Iñaki Baz Castillo
> El problema esta en la configuración del dial options, porque si pongo
> como opción "t", si que hay tráfico RTP pero, como ya dijimos
> anteriormente, este tráfico pasa a través de asterisk.
Laura, esto ya le he explicado 3 veces en este hilo: Si pones "t" al Dial y
los peers no están configurados con "dtmfmode=info" el audio pasa por
Asterisk sí o sí.
Insisto, olvida la opción "t", hace lo que no quieres, no le des más vueltas y
céntrate en solucionar el problema del RTP directo que por alguna razón no
funciona.
Iñaki Baz Castillo
Pero en los Linux de los *clientes*, ¿verdad?
Laura
Ya se que me has repetido muchas veces lo de quitar la "t", pero lo
que no entiendo es porque tiene ese efecto el ponerla o no.
>
> Pero en los Linux de los *clientes*, ¿verdad?
>
> --
> Iñaki Baz Castillo
> <i...@xtratelecom.es>
Analizando las capturas no logro entender que está pasando.
Adjunto una captura en un pjsua con ngrep, para ver si alguien
encuentra la respuesta.
[root@ape53 src]# ngrep -d eth1 -W byline -T
interface: eth1 (192.168.1.0/255.255.255.0)
#
U +5.015214 192.168.1.53:5060 -> 192.168.1.54:5060
.
#
U +0.000065 192.168.1.53:5060 -> 192.168.1.54:5060
.
#
U +12.556520 192.168.9.52:5060 -> 192.168.1.54:5060
INVITE sip:ju...@192.168.1.54 SIP/2.0.
Via: SIP/2.0/UDP 192.168.9.52:5060;branch=z9hG4bK0916bb71;rport.
Max-Forwards: 70.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>.
Contact: <sip:pe...@192.168.9.52>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 1.6.0.1.
Date: Tue, 21 Apr 2009 10:12:39 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 262.
.
v=0.
o=root 1617842375 1617842375 IN IP4 192.168.9.52.
s=Asterisk PBX 1.6.0.1.
c=IN IP4 192.168.9.52.
t=0 0.
m=audio 15292 RTP/AVP 3 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
#
U +0.000215 192.168.1.54:5060 -> 192.168.9.52:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.9.52:5060;branch=z9hG4bK0916bb71;rport=5060.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 102 INVITE.
Server: OpenSIPS (1.4.4-notls (i386/linux)).
Content-Length: 0.
.
#
U +0.000257 192.168.1.54:5060 -> 192.168.1.53:5060
INVITE sip:ju...@192.168.1.53:5060;transport=UDP SIP/2.0.
Record-Route: <sip:192.168.1.54;lr=on>.
Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bK4231.6c1d2925.0.
Via: SIP/2.0/UDP
192.168.9.52:5060;received=192.168.9.52;branch=z9hG4bK0916bb71;
rport=5060.
Max-Forwards: 69.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>.
Contact: <sip:pe...@192.168.9.52>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 1.6.0.1.
Date: Tue, 21 Apr 2009 10:12:39 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 262.
.
v=0.
o=root 1617842375 1617842375 IN IP4 192.168.9.52.
s=Asterisk PBX 1.6.0.1.
c=IN IP4 192.168.9.52.
t=0 0.
m=audio 15292 RTP/AVP 3 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
#
U +0.000375 192.168.1.53:5060 -> 192.168.1.54:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
192.168.1.54;received=192.168.1.54;branch=z9hG4bK4231.6c1d2925.
0.
Via: SIP/2.0/UDP
192.168.9.52:5060;rport=5060;received=192.168.9.52;branch=z9hG4
bK0916bb71.
Record-Route: <sip:192.168.1.54;lr>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>.
CSeq: 102 INVITE.
Content-Length: 0.
.
#
U +0.000223 192.168.1.53:5060 -> 192.168.1.54:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.9.52:5060;rport=5060;received=192.168.9.52;branch=z9hG4
bK0916bb71.
Record-Route: <sip:192.168.1.54;lr>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
CSeq: 102 INVITE.
Contact: <sip:ju...@192.168.1.53:5060;transport=UDP>.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAG
E, OPTIONS.
Supported: replaces, 100rel, norefersub.
Content-Type: application/sdp.
Content-Length: 250.
.
v=0.
o=- 3449297557 3449297558 IN IP4 192.168.0.53.
s=pjmedia.
c=IN IP4 192.168.0.53.
t=0 0.
a=X-nat:0.
m=audio 4004 RTP/AVP 3 101.
a=rtcp:4005 IN IP4 192.168.0.53.
a=rtpmap:3 GSM/8000.
a=sendrecv.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U +0.001009 192.168.1.54:5060 -> 192.168.9.52:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.9.52:5060;rport=5060;received=192.168.9.52;branch=z9hG4
bK0916bb71.
Record-Route: <sip:192.168.1.54;lr>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
CSeq: 102 INVITE.
Contact: <sip:ju...@192.168.1.53:5060;transport=UDP>.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAG
E, OPTIONS.
Supported: replaces, 100rel, norefersub.
Content-Type: application/sdp.
Content-Length: 250.
.
v=0.
o=- 3449297557 3449297558 IN IP4 192.168.0.53.
s=pjmedia.
c=IN IP4 192.168.0.53.
t=0 0.
a=X-nat:0.
m=audio 4004 RTP/AVP 3 101.
a=rtcp:4005 IN IP4 192.168.0.53.
a=rtpmap:3 GSM/8000.
a=sendrecv.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U +0.002628 192.168.9.52:5060 -> 192.168.1.54:5060
ACK sip:ju...@192.168.1.53:5060;transport=UDP SIP/2.0.
Via: SIP/2.0/UDP 192.168.9.52:5060;branch=z9hG4bK7db5844b;rport.
Route: <sip:192.168.1.54;lr>.
Max-Forwards: 70.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
Contact: <sip:pe...@192.168.9.52>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 102 ACK.
User-Agent: Asterisk PBX 1.6.0.1.
Content-Length: 0.
.
#
U +0.000002 192.168.1.54:5060 -> 192.168.1.53:5060
ACK sip:ju...@192.168.1.53:5060;transport=UDP SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bK4231.6c1d2925.2.
Via: SIP/2.0/UDP
192.168.9.52:5060;received=192.168.9.52;branch=z9hG4bK7db5844b;
rport=5060.
Max-Forwards: 69.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
Contact: <sip:pe...@192.168.9.52>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 102 ACK.
User-Agent: Asterisk PBX 1.6.0.1.
Content-Length: 0.
.
#
U +0.000941 192.168.1.53:4005 -> 192.168.9.52:15293
..........3837b@pjca03d0.org....
#
U +0.000003 192.168.1.53:4004 -> 192.168.9.52:15292
..nd......... ..ZP.I$.I$P.I$.I$P.I$.I$P.I$.I$
#
U +0.025693 192.168.9.52:5060 -> 192.168.1.54:5060
INVITE sip:ju...@192.168.1.53:5060;transport=UDP SIP/2.0.
Via: SIP/2.0/UDP 192.168.9.52:5060;branch=z9hG4bK5b0d2274;rport.
Route: <sip:192.168.1.54;lr>.
Max-Forwards: 70.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
Contact: <sip:pe...@192.168.9.52>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 103 INVITE.
User-Agent: Asterisk PBX 1.6.0.1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=root 1617842375 1617842376 IN IP4 192.168.0.55.
s=Asterisk PBX 1.6.0.1.
c=IN IP4 192.168.0.55.
t=0 0.
m=audio 4000 RTP/AVP 3 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
#
U +0.001707 192.168.1.54:5060 -> 192.168.9.52:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.9.52:5060;branch=z9hG4bK5b0d2274;rport=5060.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 103 INVITE.
Server: OpenSIPS (1.4.4-notls (i386/linux)).
Content-Length: 0.
.
#
U +0.000003 192.168.1.54:5060 -> 192.168.1.53:5060
INVITE sip:ju...@192.168.1.53:5060;transport=UDP SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bK5231.ca0a9055.0.
Via: SIP/2.0/UDP
192.168.9.52:5060;received=192.168.9.52;branch=z9hG4bK5b0d2274;
rport=5060.
Max-Forwards: 69.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
Contact: <sip:pe...@192.168.9.52>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 103 INVITE.
User-Agent: Asterisk PBX 1.6.0.1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=root 1617842375 1617842376 IN IP4 192.168.0.55.
s=Asterisk PBX 1.6.0.1.
c=IN IP4 192.168.0.55.
t=0 0.
m=audio 4000 RTP/AVP 3 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
#
U +0.000234 192.168.1.53:4005 -> 192.168.9.52:15293
........
#
U +0.000218 192.168.1.53:5060 -> 192.168.1.54:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.1.54;received=192.168.1.54;branch=z9hG4bK5231.ca0a9055.
0.
Via: SIP/2.0/UDP
192.168.9.52:5060;rport=5060;received=192.168.9.52;branch=z9hG4
bK5b0d2274.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
CSeq: 103 INVITE.
Contact: <sip:ju...@192.168.1.53:5060;transport=UDP>.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAG
E, OPTIONS.
Supported: replaces, 100rel, norefersub.
Content-Type: application/sdp.
Content-Length: 250.
.
v=0.
o=- 3449297557 3449297559 IN IP4 192.168.0.53.
s=pjmedia.
c=IN IP4 192.168.0.53.
t=0 0.
a=X-nat:0.
m=audio 4004 RTP/AVP 3 101.
a=rtcp:4005 IN IP4 192.168.0.53.
a=rtpmap:3 GSM/8000.
a=sendrecv.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U +0.002417 192.168.1.54:5060 -> 192.168.9.52:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.9.52:5060;rport=5060;received=192.168.9.52;branch=z9hG4
bK5b0d2274.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
CSeq: 103 INVITE.
Contact: <sip:ju...@192.168.1.53:5060;transport=UDP>.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAG
E, OPTIONS.
Supported: replaces, 100rel, norefersub.
Content-Type: application/sdp.
Content-Length: 250.
.
v=0.
o=- 3449297557 3449297559 IN IP4 192.168.0.53.
s=pjmedia.
c=IN IP4 192.168.0.53.
t=0 0.
a=X-nat:0.
m=audio 4004 RTP/AVP 3 101.
a=rtcp:4005 IN IP4 192.168.0.53.
a=rtpmap:3 GSM/8000.
a=sendrecv.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U +0.001966 192.168.9.52:5060 -> 192.168.1.54:5060
ACK sip:ju...@192.168.1.53:5060;transport=UDP SIP/2.0.
Via: SIP/2.0/UDP 192.168.9.52:5060;branch=z9hG4bK080169fc;rport.
Route: <sip:192.168.1.54;lr>.
Max-Forwards: 70.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
Contact: <sip:pe...@192.168.9.52>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 103 ACK.
User-Agent: Asterisk PBX 1.6.0.1.
Content-Length: 0.
.
#
U +0.000375 192.168.1.54:5060 -> 192.168.1.53:5060
ACK sip:ju...@192.168.1.53:5060;transport=UDP SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bK5231.ca0a9055.2.
Via: SIP/2.0/UDP
192.168.9.52:5060;received=192.168.9.52;branch=z9hG4bK080169fc;
rport=5060.
Max-Forwards: 69.
From: "pepe" <sip:pe...@192.168.9.52>;tag=as4f74ec79.
To: <sip:ju...@192.168.1.54>;tag=sgUiw7znSbKJwwp5D4.n-x185MLKDyQz.
Contact: <sip:pe...@192.168.9.52>.
Call-ID: 76bfc97b54a0a855...@192.168.9.52.
CSeq: 103 ACK.
User-Agent: Asterisk PBX 1.6.0.1.
Content-Length: 0.
.
#
U +2.406016 192.168.1.53:5060 -> 192.168.1.54:5060
.
#
U +0.000038 192.168.1.53:5060 -> 192.168.1.54:5060
.
exit
En fin, al final me voy a tener que olvidar del tema y hacerlo con el
tráfico RTP a través de asterisk, porque no veo cuál es el problema.
Iñaki Baz Castillo
> Ya se que me has repetido muchas veces lo de quitar la "t", pero lo
> que no entiendo es porque tiene ese efecto el ponerla o no.
Veamos: Si tienes los peers con "dtmfmode=rfc2833" (o inband) entonces
significa que los DTMF se envían por el RTP.
Así mismo, si tienes pues "t" en el Dial significa que permites al llamado
transferir la llamada enviando un *DTMF*. Puesto que el DTMF se envía por
RTP, Asterisk *DEBE* estar en el path, y da igual que pongas canreinite=yes.
En cambio si pones dtmfmode=info, los DTMF se envían por SIP y no por el RTP,
así que aunque pongas "t" en el Dial, Asterisk no require comerse el RTP para
interceptar los DTMF, ya que los recibirá vía SIP INFO request.
PD: Pero insisto, olvida la transferencia por DTMF de Asterisk (quita la
opción "t") y usa la transferencia nativa de SIP (REFER request) que
implementa cualquier cosa SIP que se precie (y PJsip se precia mucho).
Saludos.
Raúl Alexis Betancor Santana
> Ya se que me has repetido muchas veces lo de quitar la "t", pero lo
> que no entiendo es porque tiene ese efecto el ponerla o no.
Ya te lo ha explicado Iñaki como una 4 veces.
> > Pero en los Linux de los *clientes*, ¿verdad?
>
> Efectivamente, capturo en los PCs donde se encuentran los teléfonos
Pues deberías de ver RTP salir, otra cosa es que vaya o nó a donde debe, pero
deberías de verlo salir.
> Analizando las capturas no logro entender que está pasando.
Que tienes un potaje montado de cuidado.
> Adjunto una captura en un pjsua con ngrep, para ver si alguien
> encuentra la respuesta.
Lo siento, los servicios de consultoría no son gratis. Te vuelvo a recomendar
que primero pintes en un folio lo que quieres conseguir, veas los elementos
que intervienen y aprendas como funciona cada uno, hacer ñapas a ciegas solo
te va a producir más dolores de cabeza y perdida de tiempo.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Raúl Alexis Betancor Santana
> Las direcciones corresponden a:
> 192.168.1.53 y 192.168.2.55 son pjsuas
> 192.168.1.54 y 192.168.2.56 son opensips
> 192.168.9.52 es asterisk
>
>
>
> El problema esta en la configuración del dial options, porque si pongo
> como opción "t", si que hay tráfico RTP pero, como ya dijimos
> anteriormente, este tráfico pasa a través de asterisk. Esto me esta
> volviendo de cabeza, porque no sé como resolverlo.
En las trazas que mandaste en el otro email aparecían más IP's que esas que
tienes ahí, así que creo que tu escenario no está correctamente descrito.
Aparecían IP's del rango 192.168.0.X
Laura
On 21 abr, 12:57, Raúl Alexis Betancor Santana <r...@dimension-
Laura
On 21 abr, 12:54, Raúl Alexis Betancor Santana <r...@dimension-
> El Tuesday 21 April 2009 11:18:47 Laura escribió:
>
> > Ya se que me has repetido muchas veces lo de quitar la "t", pero lo
> > que no entiendo es porque tiene ese efecto el ponerla o no.
>
> Ya te lo ha explicado Iñaki como una 4 veces.
>
> > > Pero en los Linux de los *clientes*, ¿verdad?
>
> > Efectivamente, capturo en los PCs donde se encuentran los teléfonos
>
> Pues deberías de ver RTP salir, otra cosa es que vaya o nó a donde debe, pero
> deberías de verlo salir.
>
Laura
>
> PD: Pero insisto, olvida la transferencia por DTMF de Asterisk (quita la
> opción "t") y usa la transferencia nativa de SIP (REFER request) que
> implementa cualquier cosa SIP que se precie (y PJsip se precia mucho).
hecho referencia al DMTF en la configuración.
¿Dónde puedo obtener información acerca de configuración de la
transferncia nativa de SIP (REFER request)?
Germán Aracil Boned
Laura escribió:
Saúl Ibarra
modo network-bridge? O network-route?
Creo que tienes demasiados puntos de fallo...
Laura
On 21 abr, 15:04, Saúl Ibarra <sag...@gmail.com> wrote:
> Joder, menudo cristo que tienes montado... Tienes la red de xen en
> modo network-bridge? O network-route?
