Hold - Reinvite
elguillote
SIP A llama a SIP B
SIP B deja onHOLD a SIP A
SIP B reinvita a SIP A
SIP A no escucha a SIP B por un tiempo aleatoreo, pero el sonido
vuelve.
Tengo configurado el canreinvite en NO, ademas de marcar con un dial y
la opcion T y t.
Cuando el que deja onHOLD es el que llamo (SIP A) este problema no
sucede.
Estoy usando PJSUA como cliente SIP, y el problema se presenta cuando
se establece una comunicacion entre DOS de ellos y cuando el que
transfiere es el que atendio.
Si uso un Xlite y un SUA el problema no sucede.
* Puse sip debug y las diferencias entre lo que manda un xlite y un
sua son: codecs de audio, nseq de hold y reinvite (xlite siempre manda
nseq 2 y 3 y sua siempre manda un numero aleatoreo alto, consecutivo
de todas formas)
Lo que me llama la atencion, es que ANDA, pero hay un tiempo
aleatoreo, a veces largo a veces corto para que vuelva el sonido del
que atendio al que llamo.
Ayuda por favor!!!!
Gracias.
Iñaki Baz Castillo
> SIP A llama a SIP B
> SIP B deja onHOLD a SIP A
> SIP B reinvita a SIP A
>
> SIP A no escucha a SIP B por un tiempo aleatoreo, pero el sonido
> vuelve.
¿Pero durante esos instantes B sí que escucha a A?
> Lo que me llama la atencion, es que ANDA, pero hay un tiempo
> aleatoreo, a veces largo a veces corto para que vuelva el sonido del
> que atendio al que llamo.
Monitoriza con tcpdump (por ejemplo) el RTP. Como tienes canreinvite=no
Asterisk está en medio todo el rato, por lo que:
SIP A llama a SIP B
SIP B deja onHOLD a SIP A
SIP B reinvita a SIP A
Monitoriza cuándo B empieza a enviar RTP de nuevo a Asterisk. ¿Lo hace justo
después del re-INVITE? ¿tarda un rato? Si tarda un rato es problema del UA.
~~~~~~ uso de NGREP (captura traza SIP) ~~~~~~
En el servidor Asterisk:
~$ ngrep -d any -P ' ' -W byline -T port 5060
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Iñaki Baz Castillo
i...@in.ilimit.es
elguillote
> ¿Pero durante esos instantes B sí que escucha a A?
> Monitoriza cuándo B empieza a enviar RTP de nuevo a Asterisk. ¿Lo hace justo
después del re-INVITE? ¿tarda un rato? Si tarda un rato es problema
del UA.
evidentemente esta en asterisk y por eso posteo aqui.
Por algun motivo, tarda en "devolver" el canal.
Hice dos debugs del sip con problemas, de rtp (que aparentemente esta
OK porque manda ni bien aprieto reinvite) y el SIP DEBUG.
Al llamador (que en este caso no tiene problemas) tambien le hice
estos debugs pero mi conclusion es que el siempre queda escuchando el
canal con la musica de espera, no debe recibir nada del sip.
Esto es correcto?
Por otro lado, mis pruebas me llevan a pensar que es asterisk quien no
reinvita de forma adecuada. Alguna idea?
Saúl Ibarra
esas interrupciones en el audio.
Tu problema me suena, y en mi caso era que un determinado softphone
(Bria) cortaba la llamada cuando estaba on hold, por 'supuesta'
inactividad RTP...
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
elguillote
Cuando la llamada esta activa se ven las dos ips mandando y recibiendo
paquetes a lo loco.
Cuando B pone en espera a A, se ve la ip de A mandando paquetes.
Cuando B reinvita a A, se vuelven a ver las dos ips mandando paquetes.
Lo que me llama mucho la atencion, es que si estas pruebas indican que
el problema no esta en asterisk, ya que manda perfectamente los
paquetes, el problema esta en el cliente, en el llamador, quien es el
que no se rescata de que hay audio nuevamente.
Pero... si mi cliente Sua, llamada a un Xlite, el comportamiento RTP
es exactamante el mismo que describi arriba, y todo anda a la
PERFECCION. Por lo que me deja muy mal parado, porque ya no se de
donde viene el problema.
Alguna sugerencia de donde atacar?
Raúl Alexis Betancor Santana
> Gracias Saul por la respuesta. Hice el rtp debug y parece estar ok.
> Cuando la llamada esta activa se ven las dos ips mandando y recibiendo
> paquetes a lo loco.
> Cuando B pone en espera a A, se ve la ip de A mandando paquetes.
> Cuando B reinvita a A, se vuelven a ver las dos ips mandando paquetes.
>
> Lo que me llama mucho la atencion, es que si estas pruebas indican que
> el problema no esta en asterisk, ya que manda perfectamente los
> paquetes, el problema esta en el cliente, en el llamador, quien es el
> que no se rescata de que hay audio nuevamente.
> Pero... si mi cliente Sua, llamada a un Xlite, el comportamiento RTP
> es exactamante el mismo que describi arriba, y todo anda a la
> PERFECCION. Por lo que me deja muy mal parado, porque ya no se de
> donde viene el problema.
>
> Alguna sugerencia de donde atacar?
Alguno de los dos UAC está detrás de un NAT ¿?, puede que el router de turno
haya cerrado el puerto por inactividad durante el hold.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
elguillote
> haya cerrado el puerto por inactividad durante el hold.
medio.
Gracias.
Saúl Ibarra
lo 'solucioné' yo una vez...
Iñaki Baz Castillo
> Gracias Saul por la respuesta. Hice el rtp debug y parece estar ok.
> Cuando la llamada esta activa se ven las dos ips mandando y recibiendo
> paquetes a lo loco.
> Cuando B pone en espera a A, se ve la ip de A mandando paquetes.
> Cuando B reinvita a A, se vuelven a ver las dos ips mandando paquetes.
>
> Lo que me llama mucho la atencion, es que si estas pruebas indican que
> el problema no esta en asterisk, ya que manda perfectamente los
> paquetes, el problema esta en el cliente, en el llamador, quien es el
> que no se rescata de que hay audio nuevamente.
> Pero... si mi cliente Sua, llamada a un Xlite, el comportamiento RTP
> es exactamante el mismo que describi arriba, y todo anda a la
> PERFECCION. Por lo que me deja muy mal parado, porque ya no se de
> donde viene el problema.
>
> Alguna sugerencia de donde atacar?
Haz la misma prueba con todos los tfnos y softphones que puedas, con la misma
configuración (sin STUN, sin RTP keepalive, sin nada "raro").
Si sólo falla un modelo ya sabes ;)
elguillote
era de inactividad, lo aumente a infinito pero el comportamiento es el
mismo.
Respondiendo a Iñaqui, ya no me quedan dudas que el problema es el
softphone. Me gustaria entender un poco que es lo que esta pasando, y
tal vez me puedan ayudar.
Podria decir que es el cliente llamador sua quien tiene el problema,
quien al debuguearlo en el reinvite que ejecuta la otra parte, empieza
a recibir paquetes pero no de audio, hasta que se "reacomoda" y
comienza a andar.
Pero quien quiebra esta conclusion, es que si del otro lado hay un
xlite, funciona SIEMPRE. Por lo que el cliente evidentemente no tiene
mucho que ver, pues no tiene inconvenientes si el reinvite lo hace un
xlite.
Por lo que ahora mi conclusion, es que el problema esta en la forma en
que se ejecuta el reinvite, o la forma de dejar onHold.
Puede que tengan que ver los codecs que utiliza un softphone y el
otro?
Puede que tenga que ver el protocolo sip con el cual ejecuta el
reinvite el cliente?
Como hago para subir los debug de SIP asi los pueden ver? hay unas
pequeñas diferencias entre lo que ejecuta uno y el otro.
Desde ya muchas gracias.
>
> - Mostrar texto de la cita -
Iñaki Baz Castillo
> Respondiendo a saul, el unico timeout que encontre en el softphone,
> era de inactividad, lo aumente a infinito pero el comportamiento es el
> mismo.
> Respondiendo a Iñaqui, ya no me quedan dudas que el problema es el
> softphone. Me gustaria entender un poco que es lo que esta pasando, y
> tal vez me puedan ayudar.
>
> Podria decir que es el cliente llamador sua quien tiene el problema,
> quien al debuguearlo en el reinvite que ejecuta la otra parte, empieza
> a recibir paquetes pero no de audio, hasta que se "reacomoda" y
> comienza a andar.
>
> Pero quien quiebra esta conclusion, es que si del otro lado hay un
> xlite, funciona SIEMPRE. Por lo que el cliente evidentemente no tiene
> mucho que ver, pues no tiene inconvenientes si el reinvite lo hace un
> xlite.
>
> Por lo que ahora mi conclusion, es que el problema esta en la forma en
> que se ejecuta el reinvite, o la forma de dejar onHold.
>
> Puede que tengan que ver los codecs que utiliza un softphone y el
> otro?
> Puede que tenga que ver el protocolo sip con el cual ejecuta el
> reinvite el cliente?
> Como hago para subir los debug de SIP asi los pueden ver? hay unas
> pequeñas diferencias entre lo que ejecuta uno y el otro.
Haz una captura SIP limpia (mira abajo en mi firma) de un caso y el otro.
Seguramente habrá alguna diferencia en el SDP que hace que uno de los
softphones se indigeste.
elguillote
unico que esta logueado (creo) es desde que sip B deja onHold a sip A
y lo vuelve a reinvitar.
Usando un programa de comparacion de archivos (tipo beyond compare)
puedo señalar las diferencias que veo entre el xlite y el sua:
(En este contexto, la ip 192.168.2.16 es del sip que hace el hold y
reinvite, la ip 192.168.2.166 es del servidor asterisk)
1) Sua: Via: SIP/2.0/UDP
192.168.2.16:5060;rport;branch=z9hG4bKPjb495747143114778b41617f0232d89a0
Xlite: Via: SIP/2.0/UDP 192.168.2.16:5000;branch=z9hG4bK-
d87543-9116f246727c0265-1--d87543-
En este punto, veo que sua utiliza siempre el puerto 5060 mientas
que xlite no, y sua siempre agrega el parametro "rport"
2) Sua: From: <sip:
70...@192.168.2.16>;tag=13d3e978589d400681e919603af8c7eb
Xlite: From: <sip:
70...@192.168.2.16:5000;rinstance=8317a2c7c570e6d5>;tag=3551f305
Punto similar al de arriba, xlite le agrega el puerto 5000 y sua
nada.
3) Sua: Contact: <sip:192.168.2.16:5060;transport=UDP>
Xlite: Contact: <sip:
70...@192.168.2.16:5000;rinstance=8317a2c7c570e6d5>
Aqui la diferencia se ve clara, ademas del puerto, sua define el
transporte y xlite otra cosa :s
4) Sua: CSeq: 2705444 INVITE
Xlite: CSeq: 2 INVITE
En este punto sua, siempre manda un numero aleatoreo y xlite
siempre el 2. (en el ack sua manda numeroAleatoreo + 1 y xlite siempre
3)
5) Sua:
v=0
o=- 3422874179 3422874179 IN IP4 192.168.2.16
s=pjmedia
c=IN IP4 0.0.0.0
t=0 0
m=audio 4000 RTP/AVP 103 102 104 117 3 0 8 101
a=rtcp:4001 IN IP4 192.168.2.16
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:104 speex/32000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendonly
Xlite:
v=0
o=- 4 3 IN IP4 192.168.2.16
s=CounterPath X-Lite 3.0
c=IN IP4 0.0.0.0
t=0 0
m=audio 5002 RTP/AVP 0 101
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendonly
En este punto, veo que sua mete mas codecs que xlite a mi
entender. Y una diferencia por ahi importante es
a=rtcp:4001 IN IP4 192.168.2.16 de sua contra c=IN IP4 0.0.0.0
de xlite
Estas son las diferencias mas importantes que he notado. Si alguien le
quiere echar un ojo a los archivos completos, les dejo el link porque
no se como hacer para subirlos.
www.aplay.com.ar/xlite.txt1
www.aplay.com.ar/sua.txt1
(le puse txt1 asi no lo interpreta el explorador, que deforma todo
el formato)
Desde ya muchas gracias.
Raúl Alexis Betancor Santana
> Bueno, aqui estan las comparaciones. Hice como me dijiste iñaqui, lo
> unico que esta logueado (creo) es desde que sip B deja onHold a sip A
> y lo vuelve a reinvitar.
> Usando un programa de comparacion de archivos (tipo beyond compare)
> puedo señalar las diferencias que veo entre el xlite y el sua:
> (En este contexto, la ip 192.168.2.16 es del sip que hace el hold y
> reinvite, la ip 192.168.2.166 es del servidor asterisk)
>
> 1) Sua: Via: SIP/2.0/UDP
> 192.168.2.16:5060;rport;branch=z9hG4bKPjb495747143114778b41617f0232d89a0
> Xlite: Via: SIP/2.0/UDP 192.168.2.16:5000;branch=z9hG4bK-
> d87543-9116f246727c0265-1--d87543-
>
> En este punto, veo que sua utiliza siempre el puerto 5060 mientas
> que xlite no, y sua siempre agrega el parametro "rport"
Nada que se salga del estandar.
> 2) Sua: From: <sip:
> 70...@192.168.2.16>;tag=13d3e978589d400681e919603af8c7eb
> Xlite: From: <sip:
> 70...@192.168.2.16:5000;rinstance=8317a2c7c570e6d5>;tag=3551f305
>
> Punto similar al de arriba, xlite le agrega el puerto 5000 y sua
> nada.
Idem, nada raro
> 3) Sua: Contact: <sip:192.168.2.16:5060;transport=UDP>
> Xlite: Contact: <sip:
> 70...@192.168.2.16:5000;rinstance=8317a2c7c570e6d5>
>
> Aqui la diferencia se ve clara, ademas del puerto, sua define el
> transporte y xlite otra cosa :s
Tampoco nada raro.
> 4) Sua: CSeq: 2705444 INVITE
> Xlite: CSeq: 2 INVITE
>
> En este punto sua, siempre manda un numero aleatoreo y xlite
> siempre el 2. (en el ack sua manda numeroAleatoreo + 1 y xlite siempre
> 3)
Sigue estando ok.
En lo de xlite no hay codecs, lo que hay es un telephone-event
> Y una diferencia por ahi importante es
> a=rtcp:4001 IN IP4 192.168.2.16 de sua contra c=IN IP4 0.0.0.0
> de xlite
Eso es simplemente porque el Xlite ha puesto al otro UAC en Hold, cuando se
pone a alguien en Hold, se manda esa IP 0.0.0.0
> Estas son las diferencias mas importantes que he notado. Si alguien le
> quiere echar un ojo a los archivos completos, les dejo el link porque
> no se como hacer para subirlos.
>
> www.aplay.com.ar/xlite.txt1
> www.aplay.com.ar/sua.txt1
>
> (le puse txt1 asi no lo interpreta el explorador, que deforma todo
> el formato)
Esos archivos sirve de poco, sino explicas como y donde has capturado ese
tráfico.
A ver .. si tu esquema es:
UAC A <-> Asterisk <-> UAC B
Estando A y B en la misma red (para simplificar y olvidarnos de temas de NAT),
haz la captura en el asterisk, pon a capturar, haz una llamada en la que
reproduzcas el problema, corta la captura y envíala, así se podrá ver lo que
manda A a Asterisk para el Invite Incial, el Invite de Asterisk a B, y toda
la operativa de on-Hold y re-Invite cuando la hagas.
elguillote
El contexto del debug es:
sip A ip: 192.168.2.67
sip B ip: 192.168.2.16
Servidor Asterisk ip: 192.168.2.166
Configuracion de asterisk:
canreinvite=no (ademas de hacer dial con opcion t y T) , o sea que el
audio pasa por asterisk - lo necesito asi -
Caso de falla:
SIP A (sua) llama SIP B (sua)
SIP B atiende a SIP A
--- pongo el sip debug
SIP B deja onHold a SIP A
--- apago sip debug y lo copio en texto mas abajo
--- prendo sip debug
SIP debug:
CUANDO APRIETO ONHOLD
<--- SIP read from 192.168.2.16:5060 --->
INVITE sip:aste...@192.168.2.166 SIP/2.0
Via: SIP/2.0/UDP
192.168.2.16:5060;rport;branch=z9hG4bKPjd9a53134a3144fb3b4bd1b8b8842a4be
Max-Forwards: 70
From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
CSeq: 1041373769 INVITE
Allow: INVITE, ACK, BYE, CANCEL, SUBSCRIBE, NOTIFY, PUBLISH, REFER,
MESSAGE, OPTIONS
Supported: replaces, norefersub
User-Agent: PJSUA v0.5.10.4/win32
Content-Type: application/sdp
Content-Length: 419
v=0
o=- 3422880933 3422880933 IN IP4 192.168.2.16
c=IN IP4 0.0.0.0
t=0 0
m=audio 4000 RTP/AVP 103 102 104 117 3 0 8 101
a=rtcp:4001 IN IP4 192.168.2.16
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:104 speex/32000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendonly
--- (13 headers 18 lines) ---
Sending to 192.168.2.16 : 5060 (NAT)
Found RTP audio format 103
Found RTP audio format 102
Found RTP audio format 104
Found RTP audio format 117
Found RTP audio format 3
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 101
Peer audio RTP is at port 0.0.0.0:4000
Found description format speex for ID 103
Found description format speex for ID 102
Found description format speex for ID 104
Found description format iLBC for ID 117
Found description format GSM for ID 3
Found description format PCMU for ID 0
Found description format PCMA for ID 8
Found description format telephone-event for ID 101
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x60e
(gsm|ulaw|alaw|speex|ilbc)/video=0x0 (nothing), combined - 0xe (gsm|
ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1
(telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 0.0.0.0:4000
Audio is at 192.168.2.166 port 13666
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
<--- Transmitting (NAT) to 192.168.2.16:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.2.16:5060;branch=z9hG4bKPjd9a53134a3144fb3b4bd1b8b8842a4be;received=192.168.2.16;rport=5060
From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
Call-ID: 54c1a2da11aec810...@192.168.2.166
CSeq: 1041373769 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:aste...@192.168.2.166>
Content-Type: application/sdp
Content-Length: 289
v=0
o=root 12996 12997 IN IP4 192.168.2.166
s=session
c=IN IP4 192.168.2.166
t=0 0
m=audio 13666 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=ptime:20
a=recvonly
<------------>
-- Started music on hold, class 'default', on SIP/7034-08223f18
localhost*CLI>
<--- SIP read from 192.168.2.16:5060 --->
ACK sip:aste...@192.168.2.166 SIP/2.0
Via: SIP/2.0/UDP
192.168.2.16:5060;rport;branch=z9hG4bKPjb422d58761cf4392a17e92b001c1be84
Max-Forwards: 70
From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
Call-ID: 54c1a2da11aec810...@192.168.2.166
CSeq: 1041373769 ACK
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
localhost*CLI>
<--- SIP read from 192.168.2.16:5060 --->
ACK sip:aste...@192.168.2.166 SIP/2.0
Via: SIP/2.0/UDP
192.168.2.16:5060;rport;branch=z9hG4bKPj88e371a89f9641cab7b0bee3602ddad8
Max-Forwards: 70
From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
Call-ID: 54c1a2da11aec810...@192.168.2.166
CSeq: 1041373769 ACK
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
Really destroying SIP dialog
'1206af0d43c15acd...@192.168.2.166' Method: INVITE
Retransmitting #5 (no NAT) to 192.168.2.16:5060:
NOTIFY sip:70...@192.168.2.16:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.2.166:5060;branch=z9hG4bK3e23aaa4;rport
From: "asterisk" <sip:aste...@192.168.2.166>;tag=as3e9ac936
To: <sip:70...@192.168.2.16:5060;transport=UDP>
Contact: <sip:aste...@192.168.2.166>
Call-ID: 09f1dc2552f4ac77...@192.168.2.166
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 93
Messages-Waiting: no
Message-Account: sip:aste...@192.168.2.166
Voice-Message: 0/0 (0/0)
---
Retransmitting #4 (no NAT) to 192.168.2.67:5060:
NOTIFY sip:70...@192.168.2.67:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.2.166:5060;branch=z9hG4bK57f31061;rport
From: "asterisk" <sip:aste...@192.168.2.166>;tag=as34a95a7c
To: <sip:70...@192.168.2.67:5060;transport=UDP>
Contact: <sip:aste...@192.168.2.166>
Call-ID: 7365a6c85111c35c...@192.168.2.166
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 93
Messages-Waiting: no
Message-Account: sip:aste...@192.168.2.166
Voice-Message: 0/0 (0/0)
CUANDO APRIETO REINVITE
Retransmitting #3 (no NAT) to 192.168.2.67:5060:
NOTIFY sip:70...@192.168.2.67:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.2.166:5060;branch=z9hG4bK0ad35202;rport
From: "asterisk" <sip:aste...@192.168.2.166>;tag=as02076c56
To: <sip:70...@192.168.2.67:5060;transport=UDP>
Contact: <sip:aste...@192.168.2.166>
Call-ID: 2f184c8b217d8fa7...@192.168.2.166
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 93
Messages-Waiting: no
Message-Account: sip:aste...@192.168.2.166
Voice-Message: 0/0 (0/0)
---
localhost*CLI>
<--- SIP read from 192.168.2.16:5060 --->
INVITE sip:aste...@192.168.2.166 SIP/2.0
Via: SIP/2.0/UDP
192.168.2.16:5060;rport;branch=z9hG4bKPjead84b01ba2f4d08942520e616859f64
Max-Forwards: 70
From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
CSeq: 1041373770 INVITE
Allow: INVITE, ACK, BYE, CANCEL, SUBSCRIBE, NOTIFY, PUBLISH, REFER,
MESSAGE, OPTIONS
Supported: replaces, norefersub
User-Agent: PJSUA v0.5.10.4/win32
Content-Type: application/sdp
Content-Length: 424
v=0
o=- 3422881042 3422881042 IN IP4 192.168.2.16
s=pjmedia
c=IN IP4 192.168.2.16
m=audio 4000 RTP/AVP 103 102 104 117 3 0 8 101
a=rtcp:4001 IN IP4 192.168.2.16
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:104 speex/32000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=fmtp:101 0-15
--- (13 headers 18 lines) ---
Sending to 192.168.2.16 : 5060 (NAT)
Found RTP audio format 103
Found RTP audio format 102
Found RTP audio format 104
Found RTP audio format 117
Found RTP audio format 3
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 101
Peer audio RTP is at port 192.168.2.16:4000
Found description format speex for ID 103
Found description format speex for ID 102
Found description format speex for ID 104
Found description format iLBC for ID 117
Found description format GSM for ID 3
Found description format PCMU for ID 0
Found description format PCMA for ID 8
Found description format telephone-event for ID 101
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x60e
(gsm|ulaw|alaw|speex|ilbc)/video=0x0 (nothing), combined - 0xe (gsm|
ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1
(telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 192.168.2.16:4000
Audio is at 192.168.2.166 port 13666
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
<--- Transmitting (NAT) to 192.168.2.16:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.2.16:5060;branch=z9hG4bKPjead84b01ba2f4d08942520e616859f64;received=192.168.2.16;rport=5060
From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
Call-ID: 54c1a2da11aec810...@192.168.2.166
CSeq: 1041373770 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:aste...@192.168.2.166>
Content-Type: application/sdp
Content-Length: 289
v=0
o=root 12996 12998 IN IP4 192.168.2.166
s=session
c=IN IP4 192.168.2.166
t=0 0
m=audio 13666 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------>
-- Stopped music on hold on SIP/7034-08223f18
localhost*CLI>
<--- SIP read from 192.168.2.16:5060 --->
ACK sip:aste...@192.168.2.166 SIP/2.0
Via: SIP/2.0/UDP
192.168.2.16:5060;rport;branch=z9hG4bKPj2ceb245fe2494f698e8dd3e9473950a9
Max-Forwards: 70
From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
Call-ID: 54c1a2da11aec810...@192.168.2.166
CSeq: 1041373770 ACK
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
localhost*CLI>
<--- SIP read from 192.168.2.16:5060 --->
ACK sip:aste...@192.168.2.166 SIP/2.0
Via: SIP/2.0/UDP
192.168.2.16:5060;rport;branch=z9hG4bKPj22ca683cf2e2432997d2df8fe999ab2f
Max-Forwards: 70
From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
Call-ID: 54c1a2da11aec810...@192.168.2.166
CSeq: 1041373770 ACK
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
Retransmitting #5 (no NAT) to 192.168.2.16:5060:
NOTIFY sip:70...@192.168.2.16:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.2.166:5060;branch=z9hG4bK2181f96e;rport
From: "asterisk" <sip:aste...@192.168.2.166>;tag=as7944bc29
To: <sip:70...@192.168.2.16:5060;transport=UDP>
Contact: <sip:aste...@192.168.2.166>
Call-ID: 5019270247b9b78d...@192.168.2.166
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 93
Messages-Waiting: no
Message-Account: sip:aste...@192.168.2.166
Voice-Message: 0/0 (0/0)
Muchas gracias.
Raúl Alexis Betancor Santana
Esto es B diciendole a Asterisk que ponga a A en hold (no es correcto decirlo
así .. pero ese es el efecto obtenido)
Asterisk contestando a B que Ok a su Hold (que en realidad es un re-invite)
> <------------>
> -- Started music on hold, class 'default', on SIP/7034-08223f18
^^^^ Se supone que Asterisk a puesto a A a escuchar "el lago de los
cisnes" ;-)
> localhost*CLI>
> <--- SIP read from 192.168.2.16:5060 --->
> ACK sip:aste...@192.168.2.166 SIP/2.0
> Via: SIP/2.0/UDP
> 192.168.2.16:5060;rport;branch=z9hG4bKPjb422d58761cf4392a17e92b001c1be84
> Max-Forwards: 70
> From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
> To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
> Call-ID: 54c1a2da11aec810...@192.168.2.166
> CSeq: 1041373769 ACK
> Content-Length: 0
B ACKea el 200 de Asterisk
> <------------->
> --- (8 headers 0 lines) ---
> localhost*CLI>
> <--- SIP read from 192.168.2.16:5060 --->
> ACK sip:aste...@192.168.2.166 SIP/2.0
> Via: SIP/2.0/UDP
> 192.168.2.16:5060;rport;branch=z9hG4bKPj88e371a89f9641cab7b0bee3602ddad8
> Max-Forwards: 70
> From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
> To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
> Call-ID: 54c1a2da11aec810...@192.168.2.166
> CSeq: 1041373769 ACK
> Content-Length: 0
Umm .. retransmisión de un ACK .. buff .. ese UAC no está fino, los ACK no se
retransmiten, son terminación de dialogo.
> <------------->
> --- (8 headers 0 lines) ---
> Really destroying SIP dialog
> '1206af0d43c15acd...@192.168.2.166' Method: INVITE
Lo que tienes a continuación y que elimino para simplificar es NOTIFY's del
MWI de Asterisk a A y B
> CUANDO APRIETO REINVITE
>
> Retransmitting #3 (no NAT) to 192.168.2.67:5060:
> NOTIFY sip:70...@192.168.2.67:5060;transport=UDP SIP/2.0
> Via: SIP/2.0/UDP 192.168.2.166:5060;branch=z9hG4bK0ad35202;rport
> From: "asterisk" <sip:aste...@192.168.2.166>;tag=as02076c56
> To: <sip:70...@192.168.2.67:5060;transport=UDP>
> Contact: <sip:aste...@192.168.2.166>
> Call-ID: 2f184c8b217d8fa7...@192.168.2.166
> CSeq: 102 NOTIFY
> User-Agent: Asterisk PBX
> Max-Forwards: 70
> Event: message-summary
> Content-Type: application/simple-message-summary
> Content-Length: 93
>
> Messages-Waiting: no
> Message-Account: sip:aste...@192.168.2.166
> Voice-Message: 0/0 (0/0)
Jejej .. el re-INVITE empieza ahora .. lo de antes era otro notify.
^^^
B ha mandado su re-INVITE para que Asterisk le vuelva a conectar con A
> <------------->
> --- (13 headers 18 lines) ---
> Sending to 192.168.2.16 : 5060 (NAT)
UMMMM .... ^^^^ algo raro ... ese NAT sobra, se supone que estan todos en la
misma red, pero tampoco debería de pasar nada.
^^^ Asterisk acepta el re-INVITE de B
> <------------>
> -- Stopped music on hold on SIP/7034-08223f18
> localhost*CLI>
> <--- SIP read from 192.168.2.16:5060 --->
> ACK sip:aste...@192.168.2.166 SIP/2.0
> Via: SIP/2.0/UDP
> 192.168.2.16:5060;rport;branch=z9hG4bKPj2ceb245fe2494f698e8dd3e9473950a9
> Max-Forwards: 70
> From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
> To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
> Call-ID: 54c1a2da11aec810...@192.168.2.166
> CSeq: 1041373770 ACK
> Content-Length: 0
^^^^ B ACKea a Asterisk
> <------------->
> --- (8 headers 0 lines) ---
> localhost*CLI>
> <--- SIP read from 192.168.2.16:5060 --->
> ACK sip:aste...@192.168.2.166 SIP/2.0
> Via: SIP/2.0/UDP
> 192.168.2.16:5060;rport;branch=z9hG4bKPj22ca683cf2e2432997d2df8fe999ab2f
> Max-Forwards: 70
> From: <sip:70...@192.168.2.16>;tag=1249adc7c5794458a147147689d22a1c
> To: "7034|3827" <sip:aste...@192.168.2.166>;tag=as2d7e847b
> Call-ID: 54c1a2da11aec810...@192.168.2.166
> CSeq: 1041373770 ACK
> Content-Length: 0
En serio .. esto es un mal rollo, ¿dobles ACKeos? .. eso no es correcto. Pero
tampoco deberían de afectar a nada.
> <------------->
> --- (8 headers 0 lines) ---
> Retransmitting #5 (no NAT) to 192.168.2.16:5060:
> NOTIFY sip:70...@192.168.2.16:5060;transport=UDP SIP/2.0
> Via: SIP/2.0/UDP 192.168.2.166:5060;branch=z9hG4bK2181f96e;rport
> From: "asterisk" <sip:aste...@192.168.2.166>;tag=as7944bc29
> To: <sip:70...@192.168.2.16:5060;transport=UDP>
> Contact: <sip:aste...@192.168.2.166>
> Call-ID: 5019270247b9b78d...@192.168.2.166
> CSeq: 102 NOTIFY
> User-Agent: Asterisk PBX
> Max-Forwards: 70
> Event: message-summary
> Content-Type: application/simple-message-summary
> Content-Length: 93
>
> Messages-Waiting: no
> Message-Account: sip:aste...@192.168.2.166
> Voice-Message: 0/0 (0/0)
Mas Notify de MWI
> Muchas gracias.
A ver .. este dialogo no tiene nada raro, NADA.
Te ha faltado incluir todo el dialogo de A con Asterisk y viceversa.
En esta prueba que has hecho ...
-¿A escuchó la música?
-¿A dejó de escuchar la música cuando recuperaste la llamada desde B?
Después de recuperar B la llamada:
-¿A escuchaba a B?
-¿B escuchaba a A?
elguillote
Es dificil sacar una conclusion... El protocolo parece estar bien por
lo que decis (mas que nada porque el hold y el reinvite lo hace
asterisk), el rtp manda cuando tiene que mandar. Y este UA anda
siempre bien con Xlite, ya sea cuando el xlite lo deja onHold o cuando
el UA deja onHold al Xlite.
El problema viene del lado del que esta escuchando la musica de espera
para mi. Ya que mientras escucha la musica, esta en el canal sin
problemas, pero en cuanto del otro lado le hacen el reinvite, como que
se desincroniza y no interpreta el audio (hasta que se reacomoda en un
tiempo aleatoreo desde 10 a 60 seg aprox)
Si alguien se le ocurre que es lo que puedo hacer... probar, testear,
muy agradecido.
On 19 jun, 17:24, Raúl Alexis Betancor Santana <r...@dimension-
> El Jueves, 19 de Junio de 2008 20:22, elguillote escribió:
>
>
>
>
>
> > Gracias por tu pronta respuesta.
>
> > El contexto del debug es:
>
> > sip A ip: 192.168.2.67
> > sip B ip: 192.168.2.16
> > Servidor Asterisk ip: 192.168.2.166
>
> > Configuracion de asterisk:
>
> > canreinvite=no (ademas de hacer dial con opcion t y T) , o sea que el
> > audio pasa por asterisk - lo necesito asi -
>
> > Caso de falla:
>
> > SIP A (sua) llama SIP B (sua)
> > SIP B atiende a SIP A
> > --- pongo el sip debug
> > SIP B deja onHold a SIP A
> > --- apago sip debug y lo copio en texto mas abajo
> > --- prendo sip debug
> > SIP B reinvita a SIP A
> > --- apago sip debug y lo copio en texto mas abajo
>
> > SIP debug:
>
> > CUANDO APRIETO ONHOLD
>
> > <--- SIP read from 192.168.2.16:5060 --->
> > 192.168.2.16:5060;rport;branch=z9hG4bKPjd9a53134a3144fb3b4bd1b8b8842a4be
> > Max-Forwards: 70
> > To: "7034|3827" <sip:aster...@192.168.2.166>;tag=as2d7e847b
> > "7034|3827" <sip:aster...@192.168.2.166>;tag=as2d7e847b
> > Call-ID: 54c1a2da11aec810016f33457f620...@192.168.2.166
> > User-Agent: Asterisk PBX
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> > Supported: replaces
> > Content-Length: 289
>
> > v=0
> > o=root 12996 12997 IN IP4 192.168.2.166
> > s=session
> > c=IN IP4 192.168.2.166
> > t=0 0
> > m=audio 13666 RTP/AVP 0 3 8 101
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:3 GSM/8000
> > a=rtpmap:8 PCMA/8000
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-16
> > a=silenceSupp:off - - - -
> > a=ptime:20
> > a=recvonly
>
> Asterisk contestando a B que Ok a su Hold (que en realidad es un re-invite)
>
> > <------------>
> > -- Started music on hold, class 'default', on SIP/7034-08223f18
>
> ^^^^ Se supone que Asterisk a puesto a A a escuchar "el lago de los
> cisnes" ;-)
>
> > localhost*CLI>
> > <--- SIP read from 192.168.2.16:5060 --->
> > 192.168.2.16:5060;rport;branch=z9hG4bKPjb422d58761cf4392a17e92b001c1be84
> > Max-Forwards: 70
> > To: "7034|3827" <sip:aster...@192.168.2.166>;tag=as2d7e847b
> > Call-ID: 54c1a2da11aec810016f33457f620...@192.168.2.166
> > Content-Length: 0
>
> B ACKea el 200 de Asterisk
>
> > <------------->
> > --- (8 headers 0 lines) ---
> > localhost*CLI>
> > <--- SIP read from 192.168.2.16:5060 --->
> > 192.168.2.16:5060;rport;branch=z9hG4bKPj88e371a89f9641cab7b0bee3602ddad8
> > Max-Forwards: 70
> > To: "7034|3827" <sip:aster...@192.168.2.166>;tag=as2d7e847b
> > Call-ID: 54c1a2da11aec810016f33457f620...@192.168.2.166
> > Content-Length: 0
>
> Umm .. retransmisión de un ACK .. buff .. ese UAC no está fino, los ACK no se
> retransmiten, son terminación de dialogo.
>
> > <------------->
> > --- (8 headers 0 lines) ---
> > Really destroying SIP dialog
> Lo que tienes a continuación y que elimino para simplificar es NOTIFY's del
> MWI de Asterisk a A y B
>
>
>
>
>
> > CUANDO APRIETO REINVITE
>
> > Retransmitting #3 (no NAT) to 192.168.2.67:5060:
> > To: <sip:7...@192.168.2.67:5060;transport=UDP>
> > Contact: <sip:aster...@192.168.2.166>
> > Call-ID: 2f184c8b217d8fa75cc2684b2198d...@192.168.2.166
> > User-Agent: Asterisk PBX
> > Max-Forwards: 70
> > Event: message-summary
> > Content-Type: application/simple-message-summary
> > Content-Length: 93
>
> > Messages-Waiting: no
>
> Jejej .. el re-INVITE empieza ahora .. lo de antes era otro notify.
>
>
>
>
>
> > ---
> > localhost*CLI>
> > <--- SIP read from 192.168.2.16:5060 --->
> > 192.168.2.16:5060;rport;branch=z9hG4bKPjead84b01ba2f4d08942520e616859f64
> > Max-Forwards: 70
> > To: "7034|3827" <sip:aster...@192.168.2.166>;tag=as2d7e847b
> > "7034|3827" <sip:aster...@192.168.2.166>;tag=as2d7e847b
> > Call-ID: 54c1a2da11aec810016f33457f620...@192.168.2.166
> > User-Agent: Asterisk PBX
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> > Supported: replaces
> > Content-Length: 289
>
> > v=0
> > o=root 12996 12998 IN IP4 192.168.2.166
> > s=session
> > c=IN IP4 192.168.2.166
> > t=0 0
> > m=audio 13666 RTP/AVP 0 3 8 101
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:3 GSM/8000
> > a=rtpmap:8 PCMA/8000
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-16
> > a=silenceSupp:off - - - -
> > a=ptime:20
> > a=sendrecv
>
> ^^^ Asterisk acepta el re-INVITE de B
>
>
>
> > <------------>
>
> - Mostrar texto de la cita -- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -...
>
> leer más »
elguillote
> En esta prueba que has hecho ...
> -¿A escuchó la música?
> -¿A dejó de escuchar la música cuando recuperaste la llamada desde B?
muy pocos casos como que recupera el sonido pero por un seg o 2 max, y
luego lo pierde... pero SIEMPRE lo vuelve a recuperar pasado un poco
mas de tiempo)
> -¿A escuchaba a B?
Ramses II
final creo que era del teléfono en cuestión...
Saludos,
Ramses
>-----Mensaje original-----
>De: aster...@googlegroups.com
>[mailto:aster...@googlegroups.com] En nombre de elguillote
>Enviado el: viernes, 20 de junio de 2008 1:36
>Para: asterisk-es
>Asunto: [Asterisk-ES] Re: Hold - Reinvite
Iñaki Baz Castillo
> > Xlite:
> > v=0
> > o=- 4 3 IN IP4 192.168.2.16
> > s=CounterPath X-Lite 3.0
> > c=IN IP4 0.0.0.0
> > t=0 0
> > m=audio 5002 RTP/AVP 0 101
> > a=fmtp:101 0-15
> > a=rtpmap:101 telephone-event/8000
> > a=sendonly
> >
> > En este punto, veo que sua mete mas codecs que xlite a mi
> > entender.
>
> En lo de xlite no hay codecs, lo que hay es un telephone-event
Raúl, te equivocas, en ese SDP sí hay un codec (el G711U-ULAW-PCMU). Los
codecs se exponen en orden en la línea "m" con su identificador numérico:
G729 (18)
alaw (8)
ulaw (0)
además de DTMF out-of-band (RFC2833) (101)
En el caso que nos ocupa:
m=audio 5002 RTP/AVP 0 101
Lo que pasa es que muchos teléfonos añaden líneas no imprescindibles para cada
codec:
a=rtpmap:0 PCMU/8000
pero no son necesarias.
Saludos.
Iñaki Baz Castillo
Hola, ¿por qué dices que no es correcto? Está usando la opción "a=sendonly"
definida en el RFC 3264:
5.1 Unicast Streams
If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the "a=sendonly" attribute.
Buena observación, ¿y para qué puñetas reenvía el ACK? ¿espera recibir algo?
Pero si el peer está configurado con NAT sale eso (si no me equivoco).
Sí que es raro sí...
Iñaki Baz Castillo
> Creo recordar que en la lista salio algo similar pero con un terminal, y al
> final creo que era del teléfono en cuestión...
Tiene toda la pinta. Estamos hablando de que el terminal escucha audio unos
segunditos tras el re-INVITE y pierde el audio durante 30-60 segundos y luego
lo vuelve a recuperar. Yo apuesto por el terminal.
Raúl Alexis Betancor Santana
> El Thursday 19 June 2008 20:48:10 Raúl Alexis Betancor Santana escribió:
> > > Xlite:
> > > v=0
> > > o=- 4 3 IN IP4 192.168.2.16
> > > s=CounterPath X-Lite 3.0
> > > c=IN IP4 0.0.0.0
> > > t=0 0
> > > m=audio 5002 RTP/AVP 0 101
> > > a=fmtp:101 0-15
> > > a=rtpmap:101 telephone-event/8000
> > > a=sendonly
> > >
> > > En este punto, veo que sua mete mas codecs que xlite a mi
> > > entender.
> >
> > En lo de xlite no hay codecs, lo que hay es un telephone-event
>
> Raúl, te equivocas, en ese SDP sí hay un codec (el G711U-ULAW-PCMU). Los
> codecs se exponen en orden en la línea "m" con su identificador numérico:
>
> G729 (18)
> alaw (8)
> ulaw (0)
> además de DTMF out-of-band (RFC2833) (101)
>
> En el caso que nos ocupa:
> m=audio 5002 RTP/AVP 0 101
Umm .. pillado .. so me pasa por leer rápido, de todas formas, siendo un
reinvite, más bien habría que interpretarlo como realmente lo hacen los UAC,
que es .. IP = 0.0.0.0 .... no te mando RTP
> Lo que pasa es que muchos teléfonos añaden líneas no imprescindibles para
> cada codec:
> a=rtpmap:0 PCMU/8000
> pero no son necesarias.
Ya, ya ... no es obligatorio exponer el mapping, aunque si recomendable
elguillote
pcs, con distinto hard, sistema operativo (winxp sp2, sp3).
Siguiendo con pruebas, me doy cuenta que el comportamiento es el
siguiente:
Si hay una conversacion establecida entre A y B (ambos SIP sua), sin
importar que la otra parte este onHold, si A presiona Reinvite, B no
escucha el audio de A. Si B presiona reinvite, A no escucha el audio
de B. Siempre por un tiempo hasta que comienza a escucharse.
No se si deberia poder darse el caso, de presionar reinvite sin que
este la otra parte onHold. Pero si esta onHold pasa exactamente lo
mismo.
Evidentemente el problema es el softPhone, y con el reinvite.
Voy a seguir investigando, sigo aceptando sugerencias y ayuda :P
Gracias a todos por sus respuestas.
Raúl Alexis Betancor Santana
> Hola, ¿por qué dices que no es correcto? Está usando la opción "a=sendonly"
> definida en el RFC 3264:
>
> 5.1 Unicast Streams
>
> If the offerer wishes to only send media on a stream to its peer, it
> MUST mark the stream as sendonly with the "a=sendonly" attribute.
Porque me refería a que técnicamente no es un "On-HOLD" es un "No me envíes
mas RTP"
Raúl Alexis Betancor Santana
> El Friday 20 June 2008 12:53:35 Ramses II escribió:
> > Creo recordar que en la lista salio algo similar pero con un terminal, y
> > al final creo que era del teléfono en cuestión...
>
> Tiene toda la pinta. Estamos hablando de que el terminal escucha audio unos
> segunditos tras el re-INVITE y pierde el audio durante 30-60 segundos y
> luego lo vuelve a recuperar. Yo apuesto por el terminal.
La cosa es que no es un terminal, creo que es un UAC que han desarrollado con
pjsip, por lo menos es lo que yo deduzco del useragent
Iñaki Baz Castillo
> El Viernes, 20 de Junio de 2008 12:37, Iñaki Baz Castillo escribió:
> > Hola, ¿por qué dices que no es correcto? Está usando la opción
> > "a=sendonly" definida en el RFC 3264:
> >
> > 5.1 Unicast Streams
> >
> > If the offerer wishes to only send media on a stream to its peer, it
> > MUST mark the stream as sendonly with the "a=sendonly" attribute.
>
> Porque me refería a que técnicamente no es un "On-HOLD" es un "No me envíes
> mas RTP"
Bueno pero eso es precisamente lo coloquialmente conocido como "on-Hold" ¿no?
Ramses II
referimos a terminal telefónico, softphone, cliente PJSUA....
En este caso, como no hay firmware de por medio, ¿podría ser la versión del
PJSUA?
Saludos,
Ramses
>-----Mensaje original-----
>De: aster...@googlegroups.com
>[mailto:aster...@googlegroups.com] En nombre de elguillote
>Enviado el: viernes, 20 de junio de 2008 13:54
>Para: asterisk-es
>Asunto: [Asterisk-ES] Re: Hold - Reinvite
>
>
Iñaki Baz Castillo
> Yo me refiero, y creo que Iñaki también, a que cuando decimos terminal, nos
> referimos a terminal telefónico, softphone, cliente PJSUA....
>
> En este caso, como no hay firmware de por medio, ¿podría ser la versión del
> PJSUA?
No había leído su respuesta, gracias Ramses por el apunte, desde luego que no
me refiero al modelo del Windows XDDD
elguillote
Era el UA. Hubo que sacar unas lineas del cliente para que no se
pierdan los frames, y he posteado la consulta en la lista para saber
los efectos de haber comentado parte del mismo. Tal vez solucione el
problema, pero rompa otra cosa.
Nuevamente gracias!
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-June/003367.html
On 20 jun, 08:55, Raúl Alexis Betancor Santana <r...@dimension-
Ramses II
Saludos,
Ramses
>-----Mensaje original-----
>De: aster...@googlegroups.com
>[mailto:aster...@googlegroups.com] En nombre de elguillote
>Enviado el: miércoles, 25 de junio de 2008 0:14
>Para: asterisk-es
>Asunto: [Asterisk-ES] Re: Hold - Reinvite
>
>