Problema con la detección del caller-ID en las llamadas entrantes en un SANGOMA VEGA 50 2BRI
2,284 views
Skip to first unread message
Miguel Alberto Sanz Pardo
Oct 8, 2014, 10:01:10 AM10/8/14
to aster...@googlegroups.com
Hola buenas tardes,
Hace unos días obtuve un gateway Sangoma Vega 50 2BRI y después de varios intentos conseguí configurarlo de manera que tanto las llamadas entrantes
como las salientes fueran de miedo.
El único problema que sigo sin resolver es que cuando aguien realiza una llamada entrante no me muestra su callerid como debería.
En mi extensions.conf tengo algo de esta manera: ;Llamadas entrantes(Troncal Digital 976680000) exten => 976680000,1,NoOp(Llamada entrante de ${CALLERID(num)} a traves del TRONCAL DIGITAL 976680000) same => n,Goto(from-pstn,main_menu_IP,1) Si realizo una llamada aparece algo del estilo: -- Executing [976682118@from-pstn:1] NoOp("SIP/vegaRDSI0301-0000594a", "Llamada entrante de vegaRDSI0301 a traves del TRONCAL DIGITAL 976682118") in new stack Aparece el CALLER ID del propio gateway en vez del número de tele´fono que está realizando la llamada entrante. En el SIP.conf tengo algo de este estilo: [vegaRDSI0301] callerid="Troncal 976682118-01" username=vegaRDSI0301 type=friend host=dynamic language = es qualify = yes disallow=all allow=alaw allow=g729 context=from-pstn canreinvite=no nat=no secret=
Por más que he investigado por el foro y por google no he encontrado nada que me haya servido para poder solucionar dicho problema.
En la pestaña DIALPLAN del gateway tengo algo del estilo que muestro en el archivo adjunto. ¿Se os ocurre por qué puede estar pasando esto? No sé si tendrá que ver con la configuración de Asterisk o con la configuración del propio gateway
(Dialplan --> Incoming). un saludo y gracias de nuevo por vuestra atención Miguel Sanz
Raúl Alexis Betancor Santana
Oct 8, 2014, 11:28:10 AM10/8/14
to aster...@googlegroups.com
On Wed, Oct 08, 2014 at 07:01:10AM -0700, Miguel Alberto Sanz Pardo wrote:
>
> [vegaRDSI0301]
> callerid="Troncal 976682118-01"
> username=vegaRDSI0301
> type=friend
> host=dynamic
> language = es
> qualify = yes
> disallow=all
> allow=alaw
> allow=g729
> context=from-pstn
> canreinvite=no
> nat=no
> secret=
Los gateways no se suelen configurar con autenticación, y suelen ser
>
> [vegaRDSI0301]
> callerid="Troncal 976682118-01"
> username=vegaRDSI0301
> type=friend
> host=dynamic
> language = es
> qualify = yes
> disallow=all
> allow=alaw
> allow=g729
> context=from-pstn
> canreinvite=no
> nat=no
> secret=
tipo peer, no friend
> Por más que he investigado por el foro y por google no he encontrado nada que me haya servido para poder solucionar dicho problema.
propable que el número llamante te venga en alguno de los otros
campos.
Lo mejor que puedes hacer antes de volverte loco, es capturar el
tráfico sip, con sngrep o ngrip-sip ... y ver si el INVITE lleva el
CLI del llamante en alguna cabecera ... sino te llega, tendrás que
revisar la configuración del gateway con respecto a eso.
Los Vega no los conozco ... pero en los Epigy, que te permiten hacer
el pino puente con las orejas ... puedes modificar prácticamente todos
los parámetros de las llamadas y el dialplan del propio gateway.
Saludos
Miguel Alberto Sanz Pardo
Oct 14, 2014, 8:17:09 AM10/14/14
to aster...@googlegroups.com
Hola de nuevo Raúl,
Te cuento, por una parte telefónica nos había desactivado el servicio identificador de llamadas. No obstante una vez activado he podido observar que las llamadas a veces entran y a veces no.
En caso de entrar aparece un mensaje de este tipo por el CLI de Asterisk:
[2014-10-14 13:20:14] WARNING[32294][C-00000f89]: chan_sip.c:16405 check_auth: username mismatch, have <vegaRDSI0301>, digest has <vegaRDSI0302>
[2014-10-14 13:20:14] NOTICE[32294][C-00000f89]: chan_sip.c:25351 handle_request_invite: Failed to authenticate device <sip:9766...@192.168.7.229>;tag=007E-0054-2EA46268
[2014-10-14 13:20:26] WARNING[32294][C-00000f8a]: chan_sip.c:16405 check_auth: username mismatch, have <vegaRDSI0301>, digest has <vegaRDSI0303>
[2014-10-14 13:20:26] NOTICE[32294][C-00000f8a]: chan_sip.c:25351 handle_request_invite: Failed to authenticate device
He capturado dos debug desde el propio interfaz del gateway, y por lo que he podido ver:
- Cuando la llamada entra estos son los mensajes SIP que van del llamante al llamado:
INIVTE , 401, ACK, INVITE, 100 Triying, 200 OK, ACK, BYE, 200 OK
- Cuando la llamada no entra estos son los mensajes SIP que van del llamante al llamado:
INIVTE , 401, ACK, INVITE, 403 forbidden , ACK
Adjunto un par de .txt con los debug a ver si me puedes echar una mano (probado tanto usando como type: peer o friend)
Me huele que es algo de la autentificación lo que le está molestando a ver si se la quito pero de manera que a la vez se pueda registrar sin problemas.
Hay una pestaña del interfaz web del gateway que dice algo del estilo:
SIP Profile 1 Configuration 1 ---> From Header 'userinfo' y puedes elegir entre "Calling party" y "Authentication Username"
Si está puesto en Authentication Username todas las llamadas entran pero no puedo ver el CallerID de los usuarios llamantes, sino que veo el de mi propio gateway.
Si está puesto en Calling party las llamadas entran a veces pero si entran puedo ver el caller id.
un saludo
Miguel Sanz
Te cuento, por una parte telefónica nos había desactivado el servicio identificador de llamadas. No obstante una vez activado he podido observar que las llamadas a veces entran y a veces no.
En caso de entrar aparece un mensaje de este tipo por el CLI de Asterisk:
[2014-10-14 13:20:14] WARNING[32294][C-00000f89]: chan_sip.c:16405 check_auth: username mismatch, have <vegaRDSI0301>, digest has <vegaRDSI0302>
[2014-10-14 13:20:14] NOTICE[32294][C-00000f89]: chan_sip.c:25351 handle_request_invite: Failed to authenticate device <sip:9766...@192.168.7.229>;tag=007E-0054-2EA46268
[2014-10-14 13:20:26] WARNING[32294][C-00000f8a]: chan_sip.c:16405 check_auth: username mismatch, have <vegaRDSI0301>, digest has <vegaRDSI0303>
[2014-10-14 13:20:26] NOTICE[32294][C-00000f8a]: chan_sip.c:25351 handle_request_invite: Failed to authenticate device
He capturado dos debug desde el propio interfaz del gateway, y por lo que he podido ver:
- Cuando la llamada entra estos son los mensajes SIP que van del llamante al llamado:
INIVTE , 401, ACK, INVITE, 100 Triying, 200 OK, ACK, BYE, 200 OK
- Cuando la llamada no entra estos son los mensajes SIP que van del llamante al llamado:
INIVTE , 401, ACK, INVITE, 403 forbidden , ACK
Adjunto un par de .txt con los debug a ver si me puedes echar una mano (probado tanto usando como type: peer o friend)
Me huele que es algo de la autentificación lo que le está molestando a ver si se la quito pero de manera que a la vez se pueda registrar sin problemas.
Hay una pestaña del interfaz web del gateway que dice algo del estilo:
SIP Profile 1 Configuration 1 ---> From Header 'userinfo' y puedes elegir entre "Calling party" y "Authentication Username"
Si está puesto en Authentication Username todas las llamadas entran pero no puedo ver el CallerID de los usuarios llamantes, sino que veo el de mi propio gateway.
Si está puesto en Calling party las llamadas entran a veces pero si entran puedo ver el caller id.
un saludo
Miguel Sanz
Miguel Alberto Sanz Pardo
Oct 14, 2014, 9:28:19 AM10/14/14
to aster...@googlegroups.com
Me acaba de venir a la cabeza un aspecto que el soporte del vega50 me comentó hace unos días, me dijeron que no debería tener más de un peer registrado para mi gateway (usando la misma IP).¿Te suena que esto pase en general con todos los gateways? O al menos con los epigy, que son los que más has tocado.
En mi SIP.conf tengo un perfil para cada uno de los 4 canales del RDSI de 2 BRI
[vegaRDSI0301]
callerid="Troncal 976682118-01"
username=vegaRDSI0301
; type=friend
type=peer
host=dynamic
language = es
qualify = yes
disallow=all
allow=alaw
allow=g729
context=from-pstn
canreinvite=no
nat=no
secret=
[vegaRDSI0302]
callerid="Troncal 976682118-02"
username=vegaRDSI0302
; type=friend
type=peer
callerid="Troncal 976682118-02"
username=vegaRDSI0302
; type=friend
type=peer
host=dynamic
language = es
qualify = yes
disallow=all
allow=alaw
allow=g729
context=from-pstn
canreinvite=no
nat=no
secret=
[vegaRDSI0303]
callerid="Troncal 976682118-03"
username=vegaRDSI0303
; type=friend
type=peer
callerid="Troncal 976682118-03"
username=vegaRDSI0303
; type=friend
type=peer
host=dynamic
language = es
qualify = yes
disallow=all
allow=alaw
allow=g729
context=from-pstn
canreinvite=no
nat=no
secret=
[vegaRDSI0304]
callerid="Troncal 976682118-04"
username=vegaRDSI0304
; type=friend
type=peer
callerid="Troncal 976682118-04"
username=vegaRDSI0304
; type=friend
type=peer
host=dynamic
language = es
qualify = yes
disallow=all
allow=alaw
allow=g729
context=from-pstn
canreinvite=no
nat=no
secret=
De la misma manera en el interfaz web tengo algo de este estilo:
Quizás ese mensaje que da como de que se confunde entre que quiere entrar por un canal pero entra por otro(si es que refiere a eso, que tampoco lo tengo tan claro) tenga que ver con todo esto.
| SIP Registration Users | ||||||||
|---|---|---|---|---|---|---|---|---|
| Del? | User | Enable | Sip Profile | Dn | Username | Authentication User Index | Chg? | |
| 1 | 1 | 1 - profile1 | vegaRDSI0301 | vegaRDSI0301 | 1 - vegaRDSI0301 | Modify | ||
| 2 | 1 | 1 - profile1 | vegaRDSI0302 | vegaRDSI0302 | 2 - vegaRDSI0302 | Modify | ||
| 3 | 1 | 1 - profile1 | vegaRDSI0303 | vegaRDSI0303 | 3 - vegaRDSI0303 | Modify | ||
| 4 | 1 | 1 - profile1 | vegaRDSI0304 | vegaRDSI0304 | 4 - vegaRDSI0304 |
Modify | ||
| SIP Authentication Users | ||||||||
|---|---|---|---|---|---|---|---|---|
| Del? | User | Enable | SIP Profile | Username | Password | Subscriber | Resource Priority (no namespace selected) | Chg? |
| 1 | 1 | 1 | vegaRDSI0301 | **** | IF:0301 | N/A | Modify | |
| 2 | 1 | 1 | vegaRDSI0302 | **** | IF:0302 | N/A | Modify | |
| 3 | 1 | 1 | vegaRDSI0303 | **** | IF:0303 | N/A | Modify | |
| 4 | 1 | 1 | vegaRDSI0304 | **** | IF:0304 | N/A | Modify | |
Quizás ese mensaje que da como de que se confunde entre que quiere entrar por un canal pero entra por otro(si es que refiere a eso, que tampoco lo tengo tan claro) tenga que ver con todo esto.
Raúl Alexis Betancor Santana
Oct 14, 2014, 12:38:07 PM10/14/14
to aster...@googlegroups.com
On Tue, Oct 14, 2014 at 05:17:09AM -0700, Miguel Alberto Sanz Pardo wrote:
> Hola de nuevo Raúl,
>
>
> Te cuento, por una parte telefónica nos había desactivado el servicio
> identificador de llamadas. No obstante una vez activado he podido observar
> que las llamadas a veces entran y a veces no.
>
> En caso de entrar aparece un mensaje de este tipo por el CLI de Asterisk:
>
> [2014-10-14 13:20:14] WARNING[32294][C-00000f89]: chan_sip.c:16405
> check_auth: username mismatch, have <vegaRDSI0301>, digest has
> <vegaRDSI0302>
> [2014-10-14 13:20:14] NOTICE[32294][C-00000f89]: chan_sip.c:25351
> handle_request_invite: Failed to authenticate device
> <sip:9766...@192.168.7.229>;tag=007E-0054-2EA46268
> [2014-10-14 13:20:26] WARNING[32294][C-00000f8a]: chan_sip.c:16405
> check_auth: username mismatch, have <vegaRDSI0301>, digest has
> <vegaRDSI0303>
> [2014-10-14 13:20:26] NOTICE[32294][C-00000f8a]: chan_sip.c:25351
> handle_request_invite: Failed to authenticate device
Error de autenticación del gateway ... como te comenté el otro día ...
> Hola de nuevo Raúl,
>
>
> Te cuento, por una parte telefónica nos había desactivado el servicio
> identificador de llamadas. No obstante una vez activado he podido observar
> que las llamadas a veces entran y a veces no.
>
> En caso de entrar aparece un mensaje de este tipo por el CLI de Asterisk:
>
> [2014-10-14 13:20:14] WARNING[32294][C-00000f89]: chan_sip.c:16405
> check_auth: username mismatch, have <vegaRDSI0301>, digest has
> <vegaRDSI0302>
> [2014-10-14 13:20:14] NOTICE[32294][C-00000f89]: chan_sip.c:25351
> handle_request_invite: Failed to authenticate device
> <sip:9766...@192.168.7.229>;tag=007E-0054-2EA46268
> [2014-10-14 13:20:26] WARNING[32294][C-00000f8a]: chan_sip.c:16405
> check_auth: username mismatch, have <vegaRDSI0301>, digest has
> <vegaRDSI0303>
> [2014-10-14 13:20:26] NOTICE[32294][C-00000f8a]: chan_sip.c:25351
> handle_request_invite: Failed to authenticate device
lo normal no es autenticar las llamadas entrantes desde un gateway.
Cambia la configuración del Asterisk, para que el gateway lo
identifiques por IP y punto, y desactiva en el propio gateway para que
no envíe autenticación.
Saludos
Raúl Alexis Betancor Santana
Oct 14, 2014, 12:39:56 PM10/14/14
to aster...@googlegroups.com
On Tue, Oct 14, 2014 at 06:28:19AM -0700, Miguel Alberto Sanz Pardo wrote:
>
> Me acaba de venir a la cabeza un aspecto que el soporte del vega50 me
> comentó hace unos días, me dijeron que no debería tener más de un peer
> registrado para mi gateway (usando la misma IP).¿Te suena que esto pase en
> general con todos los gateways? O al menos con los epigy, que son los que
> más has tocado.
>
Error ... error ... error ... Asterisk es altamente famoso porque es
>
> Me acaba de venir a la cabeza un aspecto que el soporte del vega50 me
> comentó hace unos días, me dijeron que no debería tener más de un peer
> registrado para mi gateway (usando la misma IP).¿Te suena que esto pase en
> general con todos los gateways? O al menos con los epigy, que son los que
> más has tocado.
>
una mierda tamaño catedral para lo que se conoce como 'peer matching'.
Define el gateway una sola vez, no una por cada interfaz RDSI.
Si quieres diferenciar porque puerto sale la llamada, cuando la
mandes desde el Asterisk al GW para que salga por la RDSI ... hazlo
con el dialplan interno del gateway.
Saludos
Elio Rojano
Oct 15, 2014, 4:46:18 AM10/15/14
to aster...@googlegroups.com
Hay que cambiar de mentalidad.
Un peer es más que suficiente para hacer/recibir todas las llamadas simultaneas que quieras, desde los números y hacia los números que quieras. No necesitas N peers con el mismo operador uno por cada línea...
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es.
Para obtener más opciones, visita https://groups.google.com/d/optout.
Página web: http://www.sinologic.net/
Twitter: http://twitter.com/hellc2
LinkedIn: http://es.linkedin.com/in/rojano
Miguel Alberto Sanz Pardo
Oct 15, 2014, 6:08:22 AM10/15/14
to aster...@googlegroups.com
Muchas gracias por tu ayuda Raúl,
Ya tengo por fin configurado el gateway de manera que parece funcionar de forma correcta. Lo único que desde el gateway hay que asociar al perfil de registro de usuario un perfil de autentificación de usuario; o al menos es lo que creo entender.
Desde el sip.conf ya le he puesto el campo host=192.168.7.235(su IP) en vez de dynamic.
Dejo una captura de pantalla de las diferentes pestañas del interfaz web del gateway por si a alguien le pasa alguna vez lo que a mí y le puede valer.
También dejo una captura de la definición del gateway en el SIP.conf y del diaplan asociado al extensions.conf
un saludo y gracias de nuevo
Miguel Sanz
Miguel Alberto Sanz Pardo
Oct 16, 2014, 11:14:39 AM10/16/14
to aster...@googlegroups.com
Me está surgiendo un problema con un SPA3000 parecido al que me surgía
con el Sangoma Vega50 al principio. Cuando alguien llama al troncal que
está conectado al puerto FXO del ATA (es un troncal analógico de
telefónica el cuál está asociado a una línea con ADSL) no aparece el
callerid correspondiente en el CLI de Asterisk, sino que aparece el
propio callerid del SPA3000 que tengo como "USER ID" en la pestaña "PSTN
Line".
Se pueden realizar llamadas entrantes/salientes sin problemas pero no aparece el caller id en las llamadas entrantes.
Ya busqué hace tiempo y he vuelto a buscar hoy información acerca de qué parámetros podían estar haciendo que no me apareciera el callerid en las llamadas entrantes a través de un SPA3000, ya fueran relacionados con CID, timers, etc pero por más que he modificado parámetros no he conseguido poder ver el caller id desde el CLI de Asterisk.
En el sip.conf tengo algo de este estilo:
[SPA3000-pstn]
callerid="Troncal SPA3000"
username=SPA3000-pstn
type=peer
host=192.168.7.212
Se pueden realizar llamadas entrantes/salientes sin problemas pero no aparece el caller id en las llamadas entrantes.
Ya busqué hace tiempo y he vuelto a buscar hoy información acerca de qué parámetros podían estar haciendo que no me apareciera el callerid en las llamadas entrantes a través de un SPA3000, ya fueran relacionados con CID, timers, etc pero por más que he modificado parámetros no he conseguido poder ver el caller id desde el CLI de Asterisk.
En el sip.conf tengo algo de este estilo:
[SPA3000-pstn]
callerid="Troncal SPA3000"
username=SPA3000-pstn
type=peer
host=192.168.7.212
language = es
qualify = yes
disallow=all
allow=alaw
allow=g729
context=from_pstn_SPA3000
canreinvite=no
nat=no
Y en el interfaz web ya he configurado la pestaña PSTN LINE para que no se registre y autentifique
¿Alguien sabe qué puedo estar haciendo mal?
Adjunto un par de capturas de llamadas entrantes hacia el ATA a ver si sois capaces de ver algo más que yo:
- Una captura está hecha con el ngrep respecto a la IP 192.168.7.212(el ATA)
ngrep -d any udp and port 5060 and host 192.168.7.212 -O /tmp/captura.txt
- La otra captura está hecha con el tcpdump respecto al tráfico capturado entre Asterisk(192.168.7.229) y el ATA(192.168.7.212)
tcpdump -pi eth0 -s0 –w /tmp/sip.cap \(dst 192.168.7.212 or 192.168.7.1\) and \(src 192.168.7.212 or 204.16.7.1\) -vvv
un saludo
Miguel Sanz
canreinvite=no
nat=no
Y en el interfaz web ya he configurado la pestaña PSTN LINE para que no se registre y autentifique
¿Alguien sabe qué puedo estar haciendo mal?
Adjunto un par de capturas de llamadas entrantes hacia el ATA a ver si sois capaces de ver algo más que yo:
- Una captura está hecha con el ngrep respecto a la IP 192.168.7.212(el ATA)
ngrep -d any udp and port 5060 and host 192.168.7.212 -O /tmp/captura.txt
- La otra captura está hecha con el tcpdump respecto al tráfico capturado entre Asterisk(192.168.7.229) y el ATA(192.168.7.212)
tcpdump -pi eth0 -s0 –w /tmp/sip.cap \(dst 192.168.7.212 or 192.168.7.1\) and \(src 192.168.7.212 or 204.16.7.1\) -vvv
un saludo
Miguel Sanz
Elio Rojano
Oct 16, 2014, 11:20:26 AM10/16/14
to aster...@googlegroups.com
insecure=invite,port
y quítale el callerid=... ¿para qué le pones el callerid si lo que quieres es que aparezca el original?
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Miguel Alberto Sanz Pardo
Oct 17, 2014, 5:31:33 AM10/17/14
to aster...@googlegroups.com
Hola Elio ¿Qué tal?
Ya probé a poner como insecure las diferentes combinaciones posibles pero no he conseguido que aparezca el caller id del ususario llamante.
Por cierto el parámetro callerid que se le puede asignar a cada par ¿no es para que nuestro destinatario vea un "Identificador" de llamada determinado cuando le llamemos? Quiero decir, que ese callerid asociado al SPA3000 no debería de influenciar para la captura del callerid del usuario que llama, ¿no?. Si me confundo ya me dirás.
un saludo
Miguel Sanz
Ya probé a poner como insecure las diferentes combinaciones posibles pero no he conseguido que aparezca el caller id del ususario llamante.
Por cierto el parámetro callerid que se le puede asignar a cada par ¿no es para que nuestro destinatario vea un "Identificador" de llamada determinado cuando le llamemos? Quiero decir, que ese callerid asociado al SPA3000 no debería de influenciar para la captura del callerid del usuario que llama, ¿no?. Si me confundo ya me dirás.
un saludo
Miguel Sanz
Raúl Alexis Betancor Santana
Oct 17, 2014, 5:42:33 AM10/17/14
to aster...@googlegroups.com
Insecure=invite,port lo que hace es que el asterisk no le pida autenticación al gw para los invite entrantes.
El parámetro callerid es para que Asterisk 'asuma' un callerid en caso de que el gw no lo envíe.
En las trazas que mandaste ayer, se podía ver como el gw enviaba mal el callerid, de hecho no lo enviaba.
Revisa la configuración del gw, como ya te comente el otro día ... En la captura del invite que va del gw al asterisk has de ver el callerid ... Sino lo ves ... Es que el gw esta mal configurado.
Saludos
Miguel Alberto Sanz Pardo
Oct 20, 2014, 4:08:22 AM10/20/14
to aster...@googlegroups.com
Buenos días Raul,
En las trazas que envié jueves 16 ¿no aparece como callerid SPA3000?
En el primer INVITE en el campo From aparece el callerid del propio SPA(SPA3000-pstn), no del usuario que llama. Al igual que había en el Vega50 supongo que en el SPA 3000 habrá algún parámetro del estilo "From Header 'userinfo'" donde puedas elegir "calling party" o "authentication username".
Otra cosa que veo es que en el campo Call-ID en vez de aparecer el número de teléfono aparece algo del estilo "8d19dd4e-1b8575d".
INVITE sip:192.168.7.229 SIP/2.0
Via: SIP/2.0/UDP 192.168.7.212:5060;branch=z9hG4bK-3c5d82a9
From: SPA3000 <sip:SPA300...@192.168.7.229>;tag=632a0c9a3abf1081o1
To: <sip:192.168.7.229>
Remote-Party-ID: SPA3000 <sip:SPA300...@192.168.7.229>;screen=yes;party=calling
Call-ID: 8d19dd4e...@192.168.7.212
CSeq: 101 INVITE
Max-Forwards: 70
Contact: SPA3000 <sip:SPA300...@192.168.7.212:5060>
Expires: 240
User-Agent: Linksys/SPA3000-3.1.20(GW)
Content-Length: 444
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura, replaces
Content-Type: application/sdp
Seguiré revisando la configuración del SPA a ver si consigo dar con el parámetro adecuado.
un saludo y gracias
Miguel Sanz
Reply all
Reply to author
Forward
0 new messages