Hi,
I have an IMS core deployed using kamailio 5.0.2. Calls from clients are reaching the core pcscf from a freeswitch (with address A.A.A.A) + a kamailio acting as proxy (with address B.B.B.B), so the INVITE request looks like this:
INVITE sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0 Record-Route: sip:A.A.A.A;lr Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0 Via: SIP/2.0/UDP B.B.B.B:5080;received=B.B.B.B;rport=5080;branch=z9hG4bKHpB704ZaXSKtm Max-Forwards: 65 From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S To: sip:1111111111@mnc001.mcc001.3gppnetwork.org Call-ID: 77d249c0-487c-1236-1997-00163edbaa97 CSeq: 115249948 INVITE Contact: sip:mod_sofia@B.B.B.B:5080 User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20170927T175834Z~38f568d343~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 224 P-Charge-Info: sip:222222222@mobile.tuenti.int;npi=ISDN;noa=4 X-FS-Support: update_display,send_info Remote-Party-ID: "222222222" sip:222222222@B.B.B.B;party=calling;screen=yes;privacy=off
If the client cancels the request, the CANCEL request that gets to the core pcscf looks like this:
CANCEL sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0 Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0 Max-Forwards: 65 From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S To: sip:1111111111@mnc001.mcc001.3gppnetwork.org Call-ID: 77d249c0-487c-1236-1997-00163edbaa97 CSeq: 115249948 CANCEL Content-Length: 0 Reason: Q.850;cause=16;text="Normal Call Clearing"
The processing of the CANCEL at the pcscf is eventually reaching the t_check_trans() function, but the logs return “no CANCEL matching found!” and thus the processing ends. I have followed the code up to the via_matching function in the t_lookup.c file of the tm module source and added some logs. The via matching is failing at the port comparison (the port stored for the INVITE is “5060”, the port stored for the CANCEL is “0”. The flow works ok with a different client (connected directly to the core) which includes the port in the Via headers. ¿Can this be a bug in kamailio or am I doing something wrong?. AFAIK The RFC 3261 does not mandate to include the ports in the sent-by element of the Via header
Thanks!
Carlos
________________________________
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Hi,
it's kind of funny: I quit at Telefonica six years ago, to do Open-Source IMS based on Kamailio... ;-) Good to see, that Telefonica is checking out open-source. :-)
This SHOULD not be an issue, as the port SHOULD default to 5060 if not present. I can check the sources in the next couple of days.
Thanks, Carsten
2017-11-22 12:57 GMT+01:00 CARLOS GARCIA MORCHON carlos.garciamorchon@telefonica.com:
Hi,
I have an IMS core deployed using kamailio 5.0.2. Calls from clients are reaching the core pcscf from a freeswitch (with address A.A.A.A) + a kamailio acting as proxy (with address B.B.B.B), so the INVITE request looks like this:
INVITE sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0
Record-Route: sip:A.A.A.A;lr
Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0
Via: SIP/2.0/UDP B.B.B.B:5080;received=B.B.B.B;rport=5080;branch=z9hG4bKHpB704ZaXSKtm
Max-Forwards: 65
From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S
To: sip:1111111111@mnc001.mcc001.3gppnetwork.org
Call-ID: 77d249c0-487c-1236-1997-00163edbaa97
CSeq: 115249948 INVITE
Contact: sip:mod_sofia@B.B.B.B:5080
User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20170927T175834Z~38f568d343~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 224
P-Charge-Info: sip:222222222@mobile.tuenti.int;npi=ISDN;noa=4
X-FS-Support: update_display,send_info
Remote-Party-ID: "222222222" sip:222222222@B.B.B.B;party=calling;screen=yes;privacy=off
If the client cancels the request, the CANCEL request that gets to the core pcscf looks like this:
CANCEL sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0
Max-Forwards: 65
From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S
To: sip:1111111111@mnc001.mcc001.3gppnetwork.org
Call-ID: 77d249c0-487c-1236-1997-00163edbaa97
CSeq: 115249948 CANCEL
Content-Length: 0
Reason: Q.850;cause=16;text="Normal Call Clearing"
The processing of the CANCEL at the pcscf is eventually reaching the t_check_trans() function, but the logs return “no CANCEL matching found!” and thus the processing ends. I have followed the code up to the via_matching function in the t_lookup.c file of the tm module source and added some logs. The via matching is failing at the port comparison (the port stored for the INVITE is “5060”, the port stored for the CANCEL is “0”.
The flow works ok with a different client (connected directly to the core) which includes the port in the Via headers.
¿Can this be a bug in kamailio or am I doing something wrong?. AFAIK The RFC 3261 does not mandate to include the ports in the sent-by element of the Via header
Thanks!
Carlos
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
can you test with the master branch or backport the patch from the commit:
- https://github.com/kamailio/kamailio/commit/5fabdea4d86c527a2e38caaae7a54884...
If all goes fine, then I can backport to 5.x.x branches.
Cheers, Daniel
On 22.11.17 12:57, CARLOS GARCIA MORCHON wrote:
Hi,
I have an IMS core deployed using kamailio 5.0.2. Calls from clients are reaching the core pcscf from a freeswitch (with address A.A.A.A) + a kamailio acting as proxy (with address B.B.B.B), so the INVITE request looks like this:
INVITE sip:1111111111@mnc001.mcc001.3gppnetwork.org sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0
Record-Route: sip:A.A.A.A;lr
Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0
Via: SIP/2.0/UDP B.B.B.B:5080;received=B.B.B.B;rport=5080;branch=z9hG4bKHpB704ZaXSKtm
Max-Forwards: 65
From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S
To: sip:1111111111@mnc001.mcc001.3gppnetwork.org
Call-ID: 77d249c0-487c-1236-1997-00163edbaa97
CSeq: 115249948 INVITE
Contact: sip:mod_sofia@B.B.B.B:5080
User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20170927T175834Z~38f568d343~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 224
P-Charge-Info: sip:222222222@mobile.tuenti.int;npi=ISDN;noa=4
X-FS-Support: update_display,send_info
Remote-Party-ID: "222222222" sip:222222222@B.B.B.B;party=calling;screen=yes;privacy=off
If the client cancels the request, the CANCEL request that gets to the core pcscf looks like this:
CANCEL sip:1111111111@mnc001.mcc001.3gppnetwork.org sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0
Max-Forwards: 65
From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S
To: sip:1111111111@mnc001.mcc001.3gppnetwork.org
Call-ID: 77d249c0-487c-1236-1997-00163edbaa97
CSeq: 115249948 CANCEL
Content-Length: 0
Reason: Q.850;cause=16;text="Normal Call Clearing"
The processing of the CANCEL at the pcscf is eventually reaching the t_check_trans() function, but the logs return “no CANCEL matching found!” and thus the processing ends. I have followed the code up to the via_matching function in the t_lookup.c file of the tm module source and added some logs. The via matching is failing at the port comparison (the port stored for the INVITE is “5060”, the port stored for the CANCEL is “0”.
The flow works ok with a different client (connected directly to the core) which includes the port in the Via headers.
¿Can this be a bug in kamailio or am I doing something wrong?. AFAIK The RFC 3261 does not mandate to include the ports in the sent-by element of the Via header
Thanks!
Carlos
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
can you try adding also the patch from commit:
- https://github.com/kamailio/kamailio/commit/4bd1d70c2804ee2a1d29bd911275aa24...
Cheers, Daniel
On 23.11.17 10:09, Daniel-Constantin Mierla wrote:
Hello,
can you test with the master branch or backport the patch from the commit:
- https://github.com/kamailio/kamailio/commit/5fabdea4d86c527a2e38caaae7a54884...
If all goes fine, then I can backport to 5.x.x branches.
Cheers, Daniel
On 22.11.17 12:57, CARLOS GARCIA MORCHON wrote:
Hi,
I have an IMS core deployed using kamailio 5.0.2. Calls from clients are reaching the core pcscf from a freeswitch (with address A.A.A.A)
- a kamailio acting as proxy (with address B.B.B.B), so the INVITE
request looks like this:
INVITE sip:1111111111@mnc001.mcc001.3gppnetwork.org sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0
Record-Route: sip:A.A.A.A;lr
Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0
Via: SIP/2.0/UDP B.B.B.B:5080;received=B.B.B.B;rport=5080;branch=z9hG4bKHpB704ZaXSKtm
Max-Forwards: 65
From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S
To: sip:1111111111@mnc001.mcc001.3gppnetwork.org
Call-ID: 77d249c0-487c-1236-1997-00163edbaa97
CSeq: 115249948 INVITE
Contact: sip:mod_sofia@B.B.B.B:5080
User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20170927T175834Z~38f568d343~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 224
P-Charge-Info: sip:222222222@mobile.tuenti.int;npi=ISDN;noa=4
X-FS-Support: update_display,send_info
Remote-Party-ID: "222222222" sip:222222222@B.B.B.B;party=calling;screen=yes;privacy=off
If the client cancels the request, the CANCEL request that gets to the core pcscf looks like this:
CANCEL sip:1111111111@mnc001.mcc001.3gppnetwork.org sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0
Max-Forwards: 65
From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S
To: sip:1111111111@mnc001.mcc001.3gppnetwork.org
Call-ID: 77d249c0-487c-1236-1997-00163edbaa97
CSeq: 115249948 CANCEL
Content-Length: 0
Reason: Q.850;cause=16;text="Normal Call Clearing"
The processing of the CANCEL at the pcscf is eventually reaching the t_check_trans() function, but the logs return “no CANCEL matching found!” and thus the processing ends. I have followed the code up to the via_matching function in the t_lookup.c file of the tm module source and added some logs. The via matching is failing at the port comparison (the port stored for the INVITE is “5060”, the port stored for the CANCEL is “0”.
The flow works ok with a different client (connected directly to the core) which includes the port in the Via headers.
¿Can this be a bug in kamailio or am I doing something wrong?. AFAIK The RFC 3261 does not mandate to include the ports in the sent-by element of the Via header
Thanks!
Carlos
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
Hi Daniel,
With the second patch my scenarios work ok (udp, 5060, with and without port field in the Via header)
De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviado el: jueves, 23 de noviembre de 2017 11:56 Para: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; CARLOS GARCIA MORCHON carlos.garciamorchon@telefonica.com Asunto: Re: [SR-Users] RV: CANCEL not being matched by tm module when via address does not have port included
Hello,
can you try adding also the patch from commit:
- https://github.com/kamailio/kamailio/commit/4bd1d70c2804ee2a1d29bd911275aa24... Cheers, Daniel On 23.11.17 10:09, Daniel-Constantin Mierla wrote:
Hello,
can you test with the master branch or backport the patch from the commit:
- https://github.com/kamailio/kamailio/commit/5fabdea4d86c527a2e38caaae7a54884...
If all goes fine, then I can backport to 5.x.x branches.
Cheers, Daniel
On 22.11.17 12:57, CARLOS GARCIA MORCHON wrote: Hi,
I have an IMS core deployed using kamailio 5.0.2. Calls from clients are reaching the core pcscf from a freeswitch (with address A.A.A.A) + a kamailio acting as proxy (with address B.B.B.B), so the INVITE request looks like this:
INVITE sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0 Record-Route: sip:A.A.A.A;lr Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0 Via: SIP/2.0/UDP B.B.B.B:5080;received=B.B.B.B;rport=5080;branch=z9hG4bKHpB704ZaXSKtm Max-Forwards: 65 From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S To: sip:1111111111@mnc001.mcc001.3gppnetwork.org Call-ID: 77d249c0-487c-1236-1997-00163edbaa97 CSeq: 115249948 INVITE Contact: sip:mod_sofia@B.B.B.B:5080 User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20170927T175834Z~38f568d343~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 224 P-Charge-Info: sip:222222222@mobile.tuenti.int;npi=ISDN;noa=4 X-FS-Support: update_display,send_info Remote-Party-ID: "222222222" sip:222222222@B.B.B.B;party=calling;screen=yes;privacy=off
If the client cancels the request, the CANCEL request that gets to the core pcscf looks like this:
CANCEL sip:1111111111@mnc001.mcc001.3gppnetwork.org SIP/2.0 Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0 Max-Forwards: 65 From: "222222222" sip:222222222@B.B.B.B;tag=eytD49ymQr71S To: sip:1111111111@mnc001.mcc001.3gppnetwork.org Call-ID: 77d249c0-487c-1236-1997-00163edbaa97 CSeq: 115249948 CANCEL Content-Length: 0 Reason: Q.850;cause=16;text="Normal Call Clearing"
The processing of the CANCEL at the pcscf is eventually reaching the t_check_trans() function, but the logs return “no CANCEL matching found!” and thus the processing ends. I have followed the code up to the via_matching function in the t_lookup.c file of the tm module source and added some logs. The via matching is failing at the port comparison (the port stored for the INVITE is “5060”, the port stored for the CANCEL is “0”. The flow works ok with a different client (connected directly to the core) which includes the port in the Via headers. ¿Can this be a bug in kamailio or am I doing something wrong?. AFAIK The RFC 3261 does not mandate to include the ports in the sent-by element of the Via header
Thanks!
Carlos
________________________________
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.comhttp://www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.comhttp://www.kamailioworld.com
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.comhttp://www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.comhttp://www.kamailioworld.com
________________________________
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
-
CARLOS GARCIA MORCHON -
Carsten Bock -
Daniel-Constantin Mierla