Hola, veo que las interfaces gui de centralitas VoIP (como las de Asterisk) van bastante a su rolo en temas de estándares SIP. Por ejemplo ya he visto que en alguna si seteas el callerid a mostrar cuando se sale por un proveedor SIP (un OpenSer que luego habla con el gateway) lo que realmente hace es setear el From NAME (From: "NAME" sip:username@domain):
INVITE sip:999999999@dominio SIP/2.0 From: "999000222" sip:usuario_sip@dominio
Eso es una gran guarrada, ¿verdad?
En mi OpenSer permito dos formas de indicar el callerid:
1) Uso de cabecera P-Preferred-Identity (RFC 3325). Si un INVITE lleva esa cabecera el proxy debe colocarla como P-Asserted-Identity cuando reenvíe el INVITE.
RFC 3325 9.2 The P-Preferred-Identity Header The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert.
O sea:
INVITE sip:999999999@dominio SIP/2.0 From: sip:usuario_sip@dominio P-Preferred-Identity: sip:999000222@dominio
2) Permitiendo que el from_username no sea el usuario de autenticación: INVITE sip:999999999@dominio SIP/2.0 From: sip:999000222@dominio Proxy-Authorization: Digest username="usuario_sip"...
Pensé que esta segunda forma es ya lo suficientemente cutre y rancia para que los Asterisk y compañía más preocupados por sus líneas RDSI la usarán, pero veo que van más allá y cambian el callerid NAME en vez del username. Viva lo cerdo.
En fin, por si tal vez soy yo el equivocado, ¿se suele de verdad usar el From NAME para propósitos de setear el número saliente?
Gracias.
El Tuesday 01 April 2008 09:34:02 Iñaki Baz Castillo escribió:
Hola, veo que las interfaces gui de centralitas VoIP (como las de Asterisk) van bastante a su rolo en temas de estándares SIP. Por ejemplo ya he visto que en alguna si seteas el callerid a mostrar cuando se sale por un proveedor SIP (un OpenSer que luego habla con el gateway) lo que realmente hace es setear el From NAME (From: "NAME" sip:username@domain):
INVITE sip:999999999@dominio SIP/2.0 From: "999000222" sip:usuario_sip@dominio
Se me había pasado que dicho gui de Asterisk también setea una cabecera P-Asserted-Id con el callerid que hayas elegido.
Pues lo siento pero NO. La centralita es un CLIENTE del proveedor, y no un nodo trusted (RFC 3325), así que lo máximo que puede hacer es enviar un P-Preferred-Identity **solicitando** al proxy (el cuál NO confía en el CLIENTE) que **por favor** indique el callerid de dicha cabecera P-Preferred-Identity.
¿Es también común la guarrada de enviar PAI en vez de PPI a un proveedor? ¿nadie se lee los RFC's? ¿o es que hacen las cosas a "huevo"?
Dios, qué indignación. Saludos.
Hola Iñaki,
El 01/04/2008, a las 11:45, Iñaki Baz Castillo escribió:
El Tuesday 01 April 2008 09:34:02 Iñaki Baz Castillo escribió:
Hola, veo que las interfaces gui de centralitas VoIP (como las de Asterisk) van bastante a su rolo en temas de estándares SIP. Por ejemplo ya he visto que en alguna si seteas el callerid a mostrar cuando se sale por un proveedor SIP (un OpenSer que luego habla con el gateway) lo que realmente hace es setear el From NAME (From: "NAME" sip:username@domain):
INVITE sip:999999999@dominio SIP/2.0 From: "999000222" sip:usuario_sip@dominio
Se me había pasado que dicho gui de Asterisk también setea una cabecera P-Asserted-Id con el callerid que hayas elegido.
Pues lo siento pero NO. La centralita es un CLIENTE del proveedor, y no un nodo trusted (RFC 3325), así que lo máximo que puede hacer es enviar un P-Preferred-Identity **solicitando** al proxy (el cuál NO confía en el CLIENTE) que **por favor** indique el callerid de dicha cabecera P-Preferred-Identity.
¿Es también común la guarrada de enviar PAI en vez de PPI a un proveedor? ¿nadie se lee los RFC's? ¿o es que hacen las cosas a "huevo"?
Los métodos habituales para mostrar el número llamante es poner el RPID o el PAI... aunque hay por ahí bastantes gateways que no los usan e insisten en mostrar lo que llega en el From, pero por suerte cada vez son menos.
Muchos proveedores piden que el From sea igual al username del digest para asegurar la identidad del llamante y eso complica el uso del From como número A... de ahí que lo mejor sea usar RPID o PAI.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Tuesday 01 April 2008 10:05:10 Jesus Rodriguez escribió:
Los métodos habituales para mostrar el número llamante es poner el RPID o el PAI... aunque hay por ahí bastantes gateways que no los usan e insisten en mostrar lo que llega en el From, pero por suerte cada vez son menos.
Sí, pero sólo un nodo trusted puede enviar un PAI:
RFC 3325: ----------------------------------------------------- 5. Proxy Behavior [...] If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted-Identity header field, if any, as if it had authenticated the user itself. [...] If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field. -----------------------------------------------------
Muchos proveedores piden que el From sea igual al username del digest para asegurar la identidad del llamante y eso complica el uso del From como número A... de ahí que lo mejor sea usar RPID o PAI.
Pero según el RFC se debería usar PPI y no PAI (me refiero cuando el cliente quiere setear el callerid):
----------------------------------------------------- 9.1 The P-Asserted-Identity Header The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication. -----------------------------------------------------
----------------------------------------------------- 9.2 The P-Preferred-Identity Header The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert. -----------------------------------------------------
NOTA: Según el RFC 3324 un proxy puede ser considerado trusted para un cliente pero no la inversa. En el caso que nos ocupa el proxy es trusted para el cliente, pero el cliente no es trusted para el proxy luego estamos en el caso 9.2.
¿Me equivoco? Gracias.
Saludos JesusR.
Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Hola Iñaki,
El 01/04/2008, a las 12:28, Iñaki Baz Castillo escribió:
El Tuesday 01 April 2008 10:05:10 Jesus Rodriguez escribió:
Los métodos habituales para mostrar el número llamante es poner el RPID o el PAI... aunque hay por ahí bastantes gateways que no los usan e insisten en mostrar lo que llega en el From, pero por suerte cada vez son menos.
Sí, pero sólo un nodo trusted puede enviar un PAI:
RFC 3325:
- Proxy Behavior
[...] If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted- Identity header field, if any, as if it had authenticated the user itself. [...] If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field.
¿Consideras a tus usuarios, gateways e interconexiones IP como nodos trusted? :-)
Muchos proveedores piden que el From sea igual al username del digest para asegurar la identidad del llamante y eso complica el uso del From como número A... de ahí que lo mejor sea usar RPID o PAI.
Pero según el RFC se debería usar PPI y no PAI (me refiero cuando el cliente quiere setear el callerid):
9.1 The P-Asserted-Identity Header The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication.
9.2 The P-Preferred-Identity Header The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert.
Cierto, pero eso cuentaselo a los fabricantes que son los que implementan las cabeceras en sus equipos ;)
NOTA: Según el RFC 3324 un proxy puede ser considerado trusted para un cliente pero no la inversa. En el caso que nos ocupa el proxy es trusted para el cliente, pero el cliente no es trusted para el proxy luego estamos en el caso 9.2.
¿Me equivoco? Gracias.
Sí.
Por desgracia, como siempre pasa, los fabricantes implementan lo que les rota y el P-Preferred-Identity todavía no está muy extendido y casi todo el mundo tira de RPID/PAI.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Miércoles, 2 de Abril de 2008, Jesus Rodriguez escribió:
RFC 3325:
- Proxy Behavior
[...] If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted- Identity header field, if any, as if it had authenticated the user itself. [...] If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field.
¿Consideras a tus usuarios, gateways e interconexiones IP como nodos trusted? :-)
Sabías que me lo preguntarías :)
http://tools.ietf.org/html/rfc3324#section-2.3
2.3 Trust Domains
We say that a node, A, in the domain is 'trusted by' a node, B, (or 'B trusts A') if and only if:
1. there is a secure connection between the nodes, AND
2. B has configuration information indicating that A is a member of the Trust Domain.
Note that B may or may not be a member of the Trust Domain. For example, B may be a UA which trusts a given network intermediary, A (e.g., its home proxy).
Pero claro, con lo de "secure connection" pues queda todo muy abierto, ¿qué es una conexión segura? si al menos se MOJARAN en decir "debe ser TLS" o algo por el estilo...
NOTA: Según el RFC 3324 un proxy puede ser considerado trusted para un cliente pero no la inversa. En el caso que nos ocupa el proxy es trusted para el cliente, pero el cliente no es trusted para el proxy luego estamos en el caso 9.2.
¿Me equivoco? Gracias.
Sí.
Por desgracia, como siempre pasa, los fabricantes implementan lo que les rota y el P-Preferred-Identity todavía no está muy extendido y casi todo el mundo tira de RPID/PAI.
Finalmente he bajado la cabeza y mi OpenSer ya permite indicar el callerid que se aplicará en la llamada a PSTN con PPI y PAI. :(
Saludos.
Hola Iñaki,
El 02/04/2008, a las 21:02, Iñaki Baz Castillo escribió:
El Miércoles, 2 de Abril de 2008, Jesus Rodriguez escribió:
RFC 3325:
- Proxy Behavior
[...] If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted- Identity header field, if any, as if it had authenticated the user itself. [...] If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field.
¿Consideras a tus usuarios, gateways e interconexiones IP como nodos trusted? :-)
Sabías que me lo preguntarías :)
http://tools.ietf.org/html/rfc3324#section-2.3
2.3 Trust Domains
We say that a node, A, in the domain is 'trusted by' a node, B, (or 'B trusts A') if and only if:
1. there is a secure connection between the nodes, AND 2. B has configuration information indicating that A is a member of the Trust Domain.Note that B may or may not be a member of the Trust Domain. For example, B may be a UA which trusts a given network intermediary, A (e.g., its home proxy).
Pero claro, con lo de "secure connection" pues queda todo muy abierto, ¿qué es una conexión segura? si al menos se MOJARAN en decir "debe ser TLS" o algo por el estilo...
Ahhhh... por eso lo preguntaba :)
NOTA: Según el RFC 3324 un proxy puede ser considerado trusted para un cliente pero no la inversa. En el caso que nos ocupa el proxy es trusted para el cliente, pero el cliente no es trusted para el proxy luego estamos en el caso 9.2.
¿Me equivoco? Gracias.
Sí.
Por desgracia, como siempre pasa, los fabricantes implementan lo que les rota y el P-Preferred-Identity todavía no está muy extendido y casi todo el mundo tira de RPID/PAI.
Finalmente he bajado la cabeza y mi OpenSer ya permite indicar el callerid que se aplicará en la llamada a PSTN con PPI y PAI. :(
Welcome to the jungle! :-)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
2008/4/2 Iñaki Baz Castillo ibc@aliax.net:
http://tools.ietf.org/html/rfc3324#section-2.3
2.3 Trust Domains
We say that a node, A, in the domain is 'trusted by' a node, B, (or 'B trusts A') if and only if:
1. there is a secure connection between the nodes, AND 2. B has configuration information indicating that A is a member of the Trust Domain.Note that B may or may not be a member of the Trust Domain. For example, B may be a UA which trusts a given network intermediary, A (e.g., its home proxy).
Pero claro, con lo de "secure connection" pues queda todo muy abierto, ¿qué es una conexión segura? si al menos se MOJARAN en decir "debe ser TLS" o algo por el estilo...
A 'secure connection' in this context means that messages cannot be read by third parties, cannot be modified by third parties without detection and that B can be sure that the message really did come from A.
Fíjate que solo especifica requirements y NO se restringe al uso de un proto en concreto :-)
Saludos,
El Thursday 03 April 2008 08:03:37 Victor Pascual Ávila escribió:
A 'secure connection' in this context means that messages cannot be read by third parties, cannot be modified by third parties without detection and that B can be sure that the message really did come from A.
O sea, no vale interné XD
Fíjate que solo especifica requirements y NO se restringe al uso de un proto en concreto :-)
¡Cómo no! ¡¡¡cómo va el IETF a restringir/especificar algo en concreto!!! ¡para qué decir las cosas claramente pudiendo hablar en abstracto y que cada implementador interprete lo que le salga de los catapli***!
Ah claro claro, entiendo... no se mojan en decir "debe ser TLS o IPSEC" no sea que se dejen en el tintero algún protocolo capa 3 completamente deprecated tipo IPX. Dios mío ¡¡¡compatibilidad hacia atrás!!! ¿Para qué hacer la gramática ABNF de SIP sencilla y fácil de parsear si podemos basarla en gramáticas de hace 20 años como el HTTP y SMTP con todos sus fallos de diseño y eficiencia por ser megapermisivos sin corregir NI UNO SOLO!!
PD: ¿A que se nota que estoy haciendo un parser SIP y estoy to' quemao? XDDD
PPD: Gramática RFC3261 de la cabecera "Via" [1] convertida a RegExp: [1] http://www.tech-invite.com/Ti-sip-abnf-hf.html#Via
HDR_VIA = %r{(?:via|v)[\t\x20]*:(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:sip|[!%'\x2a\x2b\x2d\x2e0-9_-z~]+) (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?/ (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?[!%'\x2a\x2b\x2d\x2e0-9_-z~]+ (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?/ (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:udp|tcp|tls|sctp|[!%'\x2a\x2b\x2d\x2e0-9_-z~]+) (?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+ (?:(?:(?:[0-9a-z]|[0-9a-z][\x2d0-9a-z]*[0-9a-z])\x2e)* (?:[a-z]|[a-z][\x2d0-9a-z]*[0-9a-z])\x2e?| \d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3}| \x5b (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*| [0-9a-f]{1,4}(?::[0-9a-f]{1,4})*:: (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?| ::(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?) (?::\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3})?\x5d) (?:(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?: (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?\d+)? (?:(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?; (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:ttl(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?\d{1,3}| maddr(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:(?:(?:[0-9a-z]|[0-9a-z][\x2d0-9a-z]*[0-9a-z])\x2e)* (?:[a-z]|[a-z][\x2d0-9a-z]*[0-9a-z])\x2e?| \d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3}| \x5b (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*| [0-9a-f]{1,4}(?::[0-9a-f]{1,4})*:: (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?| ::(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?) (?::\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3})?\x5d)| received(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3}| (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*| [0-9a-f]{1,4}(?::[0-9a-f]{1,4})*:: (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?| ::(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?) (?::\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3})?)| branch(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? [!%'\x2a\x2b\x2d\x2e0-9_-z~]+| [!%'\x2a\x2b\x2d\x2e0-9_-z~]+ (?:(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:[!%'\x2a\x2b\x2d\x2e0-9_-z~]+| (?:(?:[0-9a-z]|[0-9a-z][\x2d0-9a-z]*[0-9a-z])\x2e)* (?:[a-z]|[a-z][\x2d0-9a-z]*[0-9a-z])\x2e?| \d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3}| \x5b (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*| [0-9a-f]{1,4}(?::[0-9a-f]{1,4})*:: (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?| ::(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?) (?::\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3})?\x5d| (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?" (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+| [!\x23-@\x5b\x5d-~]| [\xc0-\xdf][\x80-\xbf]| [\xe0-\xef][\x80-\xbf]{2}| [\xf0-\xf7][\x80-\xbf]{3}| [\xf8-\xfb][\x80-\xbf]{4}| [\xfc\xfd][\x80-\xbf]{5}| [\x00-\t\v\f\x0e-@\x5b-\x7f])*"))?))* (?:(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?, (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:sip|[!%'\x2a\x2b\x2d\x2e0-9_-z~]+) (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?/ (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?[!%'\x2a\x2b\x2d\x2e0-9_-z~]+ (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?/ (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:udp|tcp|tls|sctp|[!%'\x2a\x2b\x2d\x2e0-9_-z~]+) (?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+ (?:(?:(?:[0-9a-z]|[0-9a-z][\x2d0-9a-z]*[0-9a-z])\x2e)* (?:[a-z]|[a-z][\x2d0-9a-z]*[0-9a-z])\x2e?| \d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3}| \x5b (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*| [0-9a-f]{1,4}(?::[0-9a-f]{1,4})*:: (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?| ::(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?) (?::\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3})?\x5d) (?:(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?: (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?\d+)? (?:(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?; (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:ttl(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?\d{1,3}| maddr(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:(?:(?:[0-9a-z]|[0-9a-z][\x2d0-9a-z]*[0-9a-z])\x2e)* (?:[a-z]|[a-z][\x2d0-9a-z]*[0-9a-z])\x2e?| \d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3}| \x5b (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*| [0-9a-f]{1,4}(?::[0-9a-f]{1,4})*:: (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?| ::(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?) (?::\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3})?\x5d)| received(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3}| (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*| [0-9a-f]{1,4}(?::[0-9a-f]{1,4})*:: (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?| ::(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?) (?::\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3})?)| branch(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? [!%'\x2a\x2b\x2d\x2e0-9_-z~]+| [!%'\x2a\x2b\x2d\x2e0-9_-z~]+ (?:(?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?= (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)? (?:[!%'\x2a\x2b\x2d\x2e0-9_-z~]+| (?:(?:[0-9a-z]|[0-9a-z][\x2d0-9a-z]*[0-9a-z])\x2e)* (?:[a-z]|[a-z][\x2d0-9a-z]*[0-9a-z])\x2e?| \d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3}| \x5b (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*| [0-9a-f]{1,4}(?::[0-9a-f]{1,4})*:: (?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?| ::(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)?) (?::\d{1,3}\x2e\d{1,3}\x2e\d{1,3}\x2e\d{1,3})?\x5d| (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+)?" (?:(?:[\t\x20]*(?:\r\n|\r\n))?[\t\x20]+| [!\x23-@\x5b\x5d-~]| [\xc0-\xdf][\x80-\xbf]| [\xe0-\xef][\x80-\xbf]{2}| [\xf0-\xf7][\x80-\xbf]{3}| [\xf8-\xfb][\x80-\xbf]{4}| [\xfc\xfd][\x80-\xbf]{5}| [\x00-\t\v\f\x0e-@\x5b-\x7f])*"))?))*)*}xi
Ala, senillita, eficiente y ligera. XDDD
Saludos.
2008/4/3, Iñaki Baz Castillo ibc@in.ilimit.es:
El Thursday 03 April 2008 08:03:37 Victor Pascual Ávila escribió:
A 'secure connection' in this context means that messages cannot be read by third parties, cannot be modified by third parties without detection and that B can be sure that the message really did come from A.
O sea, no vale interné XD
Fíjate que solo especifica requirements y NO se restringe al uso de un proto en concreto :-)
¡Cómo no! ¡¡¡cómo va el IETF a restringir/especificar algo en concreto!!! ¡para qué decir las cosas claramente pudiendo hablar en abstracto y que cada implementador interprete lo que le salga de los catapli***!
es parte de los problemas de hacer cosas que funcionen "en general" sin casos particulares.
Ah claro claro, entiendo... no se mojan en decir "debe ser TLS o IPSEC" no
sea que se dejen en el tintero algún protocolo capa 3 completamente deprecated tipo IPX. Dios mío ¡¡¡compatibilidad hacia atrás!!!
o hacía delante.....que es uno de los puntos fuertes de SIP, la extensibilidad cara al futuro. Pasa lo mismo con la especificación del transporte utilizado.
¿Para qué hacer la gramática ABNF de SIP sencilla y fácil de parsear si
podemos basarla en gramáticas de hace 20 años como el HTTP y SMTP con todos sus fallos de diseño y eficiencia por ser megapermisivos sin corregir NI UNO SOLO!!
PD: ¿A que se nota que estoy haciendo un parser SIP y estoy to' quemao? XDDD
ánimus que así se aprende ;)
PPD: Gramática RFC3261 de la cabecera "Via" [1] convertida a RegExp:
[1] http://www.tech-invite.com/Ti-sip-abnf-hf.html#Via
Ala, senillita, eficiente y ligera. XDDD
la quito de la respuesta no sea que me bloquee el gestor de la lista el correo por demasiado grande ;)
Saludos.
Vaya bien! Samuel.
--
Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
El Viernes, 4 de Abril de 2008, samuel escribió:
¡Cómo no! ¡¡¡cómo va el IETF a restringir/especificar algo en concreto!!! ¡para qué decir las cosas claramente pudiendo hablar en abstracto y que cada implementador interprete lo que le salga de los catapli***!
es parte de los problemas de hacer cosas que funcionen "en general" sin casos particulares.
Seguro que sí, pero a estas alturas yo todavía no conozco, por ejemplo, dos implementaciones SIP que interoperen correctamente en presencia SIMPLE con más de los estados básicos "online/offline". Todos los estados "secundarios" (busy, away...) sólo funcionan con clientes iguales.
Es curioso, los RFC están ahí, por ejemplo el RFC4480 (RPID: Rich Presence Extensions to the Presence Information Data Format), pero claro, ¿quién demonios se va a molestar en implementar estados tan absurdos como?:
------------------------------------------------------- 3.2. Activities Element
breakfast: The person is eating the first meal of the day, usually eaten in the morning.
dinner: The person is having his or her main meal of the day, eaten in the evening or at midday.
holiday: This is a scheduled national or local holiday.
in-transit: The person is riding in a vehicle, such as a car, but not steering. The <place-type> element provides more specific information about the type of conveyance the person is using.
looking-for-work: The presentity is looking for (paid) work.
lunch... meal...
playing: The person is occupying himself or herself in amusement, sport, or other recreation.
presentation: The person is giving a presentation, lecture, or participating in a formal round-table discussion.
shopping: The person is visiting stores in search of goods or services.
sleeping: This activity category can often be generated automatically from a calendar, local time information, or biometric data.
spectator: The person is observing an event, such as a sports event.
tv: The person is watching television.
worship: The presentity is participating in religious rites.
etc etc... -------------------------------------------------------
Personalmente flipo con los estados "rezando, jugando, viendo la TV, buscando trabajo...", ¡¡¡flipo mucho!!!
Y esto por no hablar de los "moods" (estado de ánimo):
o afraid o amazed o angry o annoyed o anxious o ashamed o bored o brave ... ... o nervous o neutral o offended o other o playful o proud o relieved o remorseful
Es alucinante, ¿quién ha aprobado este enjendro?
Ah claro claro, entiendo... no se mojan en decir "debe ser TLS o IPSEC" no sea que se dejen en el tintero algún protocolo capa 3 completamente deprecated tipo IPX. Dios mío ¡¡¡compatibilidad hacia atrás!!!
o hacía delante.....que es uno de los puntos fuertes de SIP, la extensibilidad cara al futuro. Pasa lo mismo con la especificación del transporte utilizado.
Estoy de acuerdo, pero no creo que esté de más mojarse un poco y al menos mencionar los casos que YA existen. O sea, si dices que "tal sólo es una red segura" al menos dígnate a decir:
"Una red segura puede ser una VPN privada, una conexión con IPSEC, uso de SIP TLS... y además se contemplan nuevas tecnologías de red futuras que se denominen seguras".
Al menos la gente que vive **ahora** sabría cuándo una red es segura o no en el escenario actual.
¿Para qué hacer la gramática ABNF de SIP sencilla y fácil de parsear si podemos basarla en gramáticas de hace 20 años como el HTTP y SMTP con todos sus fallos de diseño y eficiencia por ser megapermisivos sin corregir NI UNO SOLO!!
PD: ¿A que se nota que estoy haciendo un parser SIP y estoy to' quemao? XDDD
ánimus que así se aprende ;)
Eso sí, se aprende a todo: - A programar. - A parsear. - A leer. - A despotricar XDDD
PPD: Gramática RFC3261 de la cabecera "Via" [1] convertida a RegExp: [1] http://www.tech-invite.com/Ti-sip-abnf-hf.html#Via
Ala, sencillita, eficiente y ligera. XDDD
la quito de la respuesta no sea que me bloquee el gestor de la lista el correo por demasiado grande ;)
Pues no te pongo entonces el RequestURI XDDDD
Saludos ;)
Retomando el thread,
¿Cómo puede un UA verificar que el From del Invite que recibe es realmente de quien dice ser?
2008/4/2 Jesus Rodriguez jesusr@voztele.com:
Por desgracia, como siempre pasa, los fabricantes implementan lo que les rota y el P-Preferred-Identity todavía no está muy extendido y casi todo el mundo tira de RPID/PAI.
¿Qué diferencias hay entre el PPI y el RPID/PAI?
Saludos,
Victor Pascual Ávila wrote:
Retomando el thread,
¿Cómo puede un UA verificar que el From del Invite que recibe es realmente de quien dice ser?
Yo creo que la cosa está chunga, como en el email. - Teoricamente si dispones de una infraestructura PKI podrías utilizar métodos para firmar las cabeceras (incluido el from) [RFC3893][RFC447] - En la práctica, si el mensaje es de un usuario de tu mismo dominio y pasa por el servidor de tu dominio, el servidor debería asegurarse que el From es quien dice ser. Si el mensaje es de un usuario de otro dominio no hay nada que hacer, salvo establecer relaciones de confianza entre dominios y cosas similares.
2008/4/2 Jesus Rodriguez jesusr@voztele.com:
Por desgracia, como siempre pasa, los fabricantes implementan lo que les rota y el P-Preferred-Identity todavía no está muy extendido y casi todo el mundo tira de RPID/PAI.
¿Qué diferencias hay entre el PPI y el RPID/PAI?
The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert. [RFC3325]
Saludos,
Victor Pascual Ávila
Un saludo, G.
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
2008/5/5 Gustavo ggb@tid.es:
Victor Pascual Ávila wrote:
¿Cómo puede un UA verificar que el From del Invite que recibe es realmente de quien dice ser?
Yo creo que la cosa está chunga, como en el email.
- Teoricamente si dispones de una infraestructura PKI podrías utilizar
métodos para firmar las cabeceras (incluido el from) [RFC3893][RFC447]
- En la práctica, si el mensaje es de un usuario de tu mismo dominio y
pasa por el servidor de tu dominio, el servidor debería asegurarse que el From es quien dice ser. Si el mensaje es de un usuario de otro dominio no hay nada que hacer, salvo establecer relaciones de confianza entre dominios y cosas similares.
¿Tendría sentido hacer lo siguiente?
0) Suponemos que todos los UA (callerB i calleeA) se registran contra su proxy 1) CalleeA recibe un INVITE con el From de CallerB 2) CalleeA genera un re-INVITE contra el From de CallerB (en este caso, contra su proxy) 3) El proxy, mediante el location service, hace un re-targeting contra el CallerB
De este modo, si un attacker genera una llamada hacia CalleeA suplantando el From de CallerB, CalleeA le preguntará a CallerB si realmente es él quien le llama...
Puede sonar algo perverso, pero en un entorno no-trusted... ¿hay otro modo de hacerlo?
Saludos,
El Lunes, 5 de Mayo de 2008, Victor Pascual Ávila escribió:
2008/5/5 Gustavo ggb@tid.es:
Victor Pascual Ávila wrote:
¿Cómo puede un UA verificar que el From del Invite que recibe es realmente de quien dice ser?
Yo creo que la cosa está chunga, como en el email.
- Teoricamente si dispones de una infraestructura PKI podrías utilizar
métodos para firmar las cabeceras (incluido el from) [RFC3893][RFC447]
- En la práctica, si el mensaje es de un usuario de tu mismo dominio y
pasa por el servidor de tu dominio, el servidor debería asegurarse que el From es quien dice ser. Si el mensaje es de un usuario de otro dominio no hay nada que hacer, salvo establecer relaciones de confianza entre dominios y cosas similares.
¿Tendría sentido hacer lo siguiente?
- Suponemos que todos los UA (callerB i calleeA) se registran contra su
proxy 1) CalleeA recibe un INVITE con el From de CallerB 2) CalleeA genera un re-INVITE contra el From de CallerB (en este caso, contra su proxy) 3) El proxy, mediante el location service, hace un re-targeting contra el CallerB
De este modo, si un attacker genera una llamada hacia CalleeA suplantando el From de CallerB, CalleeA le preguntará a CallerB si realmente es él quien le llama...
Pero no va a funcionar ya que al ser un re-INVITE el proxy no va a a hacer un "location". Es decir, el INVITE de callerB a callerA era:
INVITE sip:callerA From: sip:callerB;tag=1x1x1x1x1 To: sip:callerA Contact: sip:caller_a@80.80.80.88:5070
Pero una vez aceptada la llamada, si callerA envía un re-INVITE será:
INVITE sip:caller_a@80.80.80.88:5070 From: sip:callerA;tag=2x2x2x2x2 To: sip:callerB;tag=1x1x1x1x1
Como es in-dialog (To tag) el proxy no hará un location. Además, el location se hace del RURI y en un mensaje in-dialog el RURI no indica un AoR sino la ubicación real de un usuario.
Puede sonar algo perverso, pero en un entorno no-trusted... ¿hay otro modo de hacerlo?
Si no me equivoco, hay un RFC para eso:
RFC 4916 - Connected Identity in the Session Initiation Protocol (SIP): http://tools.ietf.org/html/rfc4916
Viene un ejemplo aquí:
http://tools.ietf.org/html/rfc4916#section-5.1
Saludos.
El Martes, 6 de Mayo de 2008, Iñaki Baz Castillo escribió:
Es decir, el INVITE de callerB a callerA era:
INVITE sip:callerA From: sip:callerB;tag=1x1x1x1x1 To: sip:callerA Contact: sip:caller_a@80.80.80.88:5070
Pero una vez aceptada la llamada, si callerA envía un re-INVITE será:
INVITE sip:caller_a@80.80.80.88:5070 From: sip:callerA;tag=2x2x2x2x2 To: sip:callerB;tag=1x1x1x1x1
Perdón, me corrijo:
El INVITE de callerB a callerA era:
INVITE sip:callerA From: sip:callerB;tag=1x1x1x1x1 To: sip:callerA Contact: sip:caller_b@80.80.80.88:5070
Pero una vez aceptada la llamada, si callerA envía un re-INVITE será:
INVITE sip:caller_b@80.80.80.88:5070 From: sip:callerA;tag=2x2x2x2x2 To: sip:callerB;tag=1x1x1x1x1
Victor Pascual Ávila wrote:
2008/5/5 Gustavo ggb@tid.es:
Victor Pascual Ávila wrote:
¿Cómo puede un UA verificar que el From del Invite que recibe es realmente de quien dice ser?
Yo creo que la cosa está chunga, como en el email.
- Teoricamente si dispones de una infraestructura PKI podrías utilizar
métodos para firmar las cabeceras (incluido el from) [RFC3893][RFC447]
- En la práctica, si el mensaje es de un usuario de tu mismo dominio y
pasa por el servidor de tu dominio, el servidor debería asegurarse que el From es quien dice ser. Si el mensaje es de un usuario de otro dominio no hay nada que hacer, salvo establecer relaciones de confianza entre dominios y cosas similares.
¿Tendría sentido hacer lo siguiente?
- Suponemos que todos los UA (callerB i calleeA) se registran contra su proxy
- CalleeA recibe un INVITE con el From de CallerB
- CalleeA genera un re-INVITE contra el From de CallerB (en este
caso, contra su proxy) 3) El proxy, mediante el location service, hace un re-targeting contra el CallerB
Yo creo que no puedes enviar un re-INVITE antes de aceptar la llamada y tampoco puedes mandar un reINVITE al From (debería ir al Contact).
Tal vez pudieras hacerlo enviando otro tipo de mensaje al From de forma no estandard, pero ¿que pasa si el origen de la llamada tiene un desvío incondicional a otro destino? Nunca le llegaría ese mensaje.
De este modo, si un attacker genera una llamada hacia CalleeA suplantando el From de CallerB, CalleeA le preguntará a CallerB si realmente es él quien le llama...
Puede sonar algo perverso, pero en un entorno no-trusted... ¿hay otro modo de hacerlo?
Podrías comprobar en tu proxy cuando te llega un mensaje de una IP, que esa IP corresponde al dominio del From (haciendo una resolución inversa en el DNS). Así al menos ya sabes que el dominio del From es correcto, y dejas la comprobación de la parte de usuario del From a su dominio. Yo creo que hotmail hace algo así para el email. No estoy convencido, pero igual es una opción.
BR, G:
Saludos,
Victor Pascual Ávila _______________________________________________ Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Hola,
Victor Pascual Ávila wrote:
2008/5/5 Gustavo ggb@tid.es:
Victor Pascual Ávila wrote:
¿Cómo puede un UA verificar que el From del Invite que recibe es realmente de quien dice ser?
Yo creo que la cosa está chunga, como en el email.
- Teoricamente si dispones de una infraestructura PKI podrías
utilizar métodos para firmar las cabeceras (incluido el from) [RFC3893] [RFC447]
- En la práctica, si el mensaje es de un usuario de tu mismo
dominio y pasa por el servidor de tu dominio, el servidor debería asegurarse que el From es quien dice ser. Si el mensaje es de un usuario de otro dominio no hay nada que hacer, salvo establecer relaciones de confianza entre dominios y cosas similares.
¿Tendría sentido hacer lo siguiente?
- Suponemos que todos los UA (callerB i calleeA) se registran
contra su proxy
- CalleeA recibe un INVITE con el From de CallerB
- CalleeA genera un re-INVITE contra el From de CallerB (en este
caso, contra su proxy) 3) El proxy, mediante el location service, hace un re-targeting contra el CallerB
Yo creo que no puedes enviar un re-INVITE antes de aceptar la llamada y tampoco puedes mandar un reINVITE al From (debería ir al Contact).
Exacto...
Tal vez pudieras hacerlo enviando otro tipo de mensaje al From de forma no estandard, pero ¿que pasa si el origen de la llamada tiene un desvío incondicional a otro destino? Nunca le llegaría ese mensaje.
Cierto... y meterse en cosas no estándar al final es llamar a los problemas :-/
De este modo, si un attacker genera una llamada hacia CalleeA suplantando el From de CallerB, CalleeA le preguntará a CallerB si realmente es él quien le llama...
Puede sonar algo perverso, pero en un entorno no-trusted... ¿hay otro modo de hacerlo?
Podrías comprobar en tu proxy cuando te llega un mensaje de una IP, que esa IP corresponde al dominio del From (haciendo una resolución inversa en el DNS). Así al menos ya sabes que el dominio del From es correcto, y dejas la comprobación de la parte de usuario del From a su dominio. Yo creo que hotmail hace algo así para el email. No estoy convencido, pero igual es una opción.
Un problema con esto es si tienes un proxy multidominio... sólo puedes tener una resolución inversa sobre una ip por lo que si tu dominio no pertenece al dominio de la inversa, la comprobación fallará.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
Hola,
Victor Pascual Ávila wrote:
Retomando el thread,
¿Cómo puede un UA verificar que el From del Invite que recibe es realmente de quien dice ser?
Yo creo que la cosa está chunga, como en el email.
- Teoricamente si dispones de una infraestructura PKI podrías utilizar
métodos para firmar las cabeceras (incluido el from) [RFC3893][RFC447]
- En la práctica, si el mensaje es de un usuario de tu mismo dominio y
pasa por el servidor de tu dominio, el servidor debería asegurarse que el From es quien dice ser. Si el mensaje es de un usuario de otro dominio no hay nada que hacer, salvo establecer relaciones de confianza entre dominios y cosas similares.
Estoy de acuerdo con Gustavo... si los dos UA están en el mismo dominio, es el gestor del dominio el que debe asegurar la integridad y no cursar señalización en la que el From no sea de quien dice ser.
2008/4/2 Jesus Rodriguez jesusr@voztele.com:
Por desgracia, como siempre pasa, los fabricantes implementan lo que les rota y el P-Preferred-Identity todavía no está muy extendido y casi todo el mundo tira de RPID/PAI.
¿Qué diferencias hay entre el PPI y el RPID/PAI?
The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert. [RFC3325]
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Lunes, 5 de Mayo de 2008, Victor Pascual Ávila escribió:
Retomando el thread,
¿Cómo puede un UA verificar que el From del Invite que recibe es realmente de quien dice ser?
En teoría el UA (UAS destino) debe "fiarse" de su proxy del cuál recibe ese INVITE. Y se supone que el proxy se ha encargado de autenticar al usuario, o tal vez el INVITE venga a su vez de otro proxy que tiene relación de confianza con nuestro proxy, etc etc...
2008/4/2 Jesus Rodriguez jesusr@voztele.com:
Por desgracia, como siempre pasa, los fabricantes implementan lo que les rota y el P-Preferred-Identity todavía no está muy extendido y casi todo el mundo tira de RPID/PAI.
¿Qué diferencias hay entre el PPI y el RPID/PAI?
El PPI lo pone un UAC solicitando a su proxy qué PAI poner. O sea, en teoría un UAC no puede enviar un PAI a su proxy puesto que, en teoría, un proxy nunca ve a un UAC como "trusted" (pero sí al contrario). De hecho si un proxy recibe un PAI de un elemento no considerado como "trusted" debe ignorarlo (y eliminarlo) o rechazar el mensaje directamente.
También creo recordar de cuando me leí el RFC sobre PAI/PPI, que un UAC puede poner un PPI para indicar al proxy quién es (y cómo autenticarse) a la vez que solicita a su proxy que el INVITE salga como "anónimo". Por ejemplo Twinkle implementa este comportamiento si marcas la casilla "Llamada anónima" y genera un INVITE así:
--------- INVITE sip:pepe@dominio.com SIP/2.0 Max-Forwards: 70 To: sip:pepe@dominio.com From: "Anonymous" sip:anonymous@anonymous.invalid;tag=fqtlx Contact: sip:192.168.0.129;transport=udp Privacy: id P-Preferred-Identity: "IBC" sip:ibc@aliax.net ----------
Fíjate que el From no indica un URI sobre el que el proxy podría exigir autenticación, pero para evitar sea rechazado se supone que el proxy debería mirar el PPI y exigir autenticación para ese PPI (ibc@aliax.net).
Además, como valor añadido, Twinkle "esconde" el username en el "Contact" y añade el "Privacy: id".
Así pues, el proxy debería exigir autenticación para el usuario ibc@aliax.net. Tras recibirla, y suponiendo que el proxy envía el INVITE a otro nodo trusted de su red (por ejemplo un gateway o lo que sea), el proxy generaría un INVITE así:
--------- INVITE sip:pepe@dominio.com SIP/2.0 Max-Forwards: 70 To: sip:pepe@dominio.com From: "Anonymous" sip:anonymous@anonymous.invalid;tag=fqtlx Contact: sip:192.168.0.129;transport=udp Privacy: id P-Asserted-Identity: "IBC" sip:ibc@aliax.net ----------
Ya no hay PPI sino PAI, que es lo que tiene sentido entre nodos trusted. Y se mantiene el "Privacy: id".
El siguiente proxy/gateway/cosa_sip envía finalmente el INVITE a un elemento no trusted (un UAS registrado en él por ejemplo) que tendría esta pinta:
--------- INVITE sip:pepe@dominio.com SIP/2.0 Max-Forwards: 70 To: sip:pepe@dominio.com From: "Anonymous" sip:anonymous@anonymous.invalid;tag=fqtlx Contact: sip:192.168.0.129;transport=udp ----------
Es decir, el destino finalmente no se entera de quién llama.
PD: No sé para qué me esfuerzo en entender esto si luego no lo usa ni cristo XDDD
sr-users-es@lists.kamailio.org
-
Gustavo -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
samuel -
Victor Pascual Ávila