Hola Iñaki, El 01/04/2008, a las 11:45, Iñaki Baz Castillo 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. 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(a)voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------

Hola Iñaki, El 01/04/2008, a las 12:28, Iñaki Baz Castillo escribió: ¿Consideras a tus usuarios, gateways e interconexiones IP como nodos trusted? :-) Cierto, pero eso cuentaselo a los fabricantes que son los que implementan las cabeceras en sus equipos ;) 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(a)voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------

Hola Iñaki, El 02/04/2008, a las 21:02, Iñaki Baz Castillo escribió: Ahhhh... por eso lo preguntaba :) Welcome to the jungle! :-) Saludos JesusR. ------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr(a)voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------

El Thursday 03 April 2008 08:03:37 Victor Pascual Ávila escribió: O sea, no vale interné XD ¡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. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

El Viernes, 4 de Abril de 2008, samuel escribió: 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? 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. Eso sí, se aprende a todo: - A programar. - A parsear. - A leer. - A despotricar XDDD Pues no te pongo entonces el RequestURI XDDDD Saludos ;) -- Iñaki Baz Castillo

Victor Pascual Ávila wrote: 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. 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] Un saludo, G.

El Lunes, 5 de Mayo de 2008, Victor Pascual Ávila escribió: 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. 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. -- Iñaki Baz Castillo

Victor Pascual Ávila wrote: 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. 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:

Hola, 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. Saludos JesusR. ------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr(a)voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------