According to this article I mentioned in the beginning:
http://nil.uniza.sk/sip/kamailio/configuring-kamailio-4x-websocket
In http:request they do straight away the set_reply_close();
I don't know exactly if this kamailio.cfg implementation may be useful for working with WSS:
event_route[xhttp:request] { set_reply_close(); set_reply_no_connect();
if ($Rp != MY_WS_PORT #!ifdef WITH_TLS && $Rp != MY_WSS_PORT #!endif ) { xlog("L_WARN", "HTTP request received on $Rp\n"); xhttp_reply("403", "Forbidden", "", ""); exit; }
xlog("L_DBG", "HTTP Request Received\n");
if ($hdr(Upgrade)=~"websocket" && $hdr(Connection)=~"Upgrade" && $rm=~"GET") {
# Validate Host - make sure the client is using the correct # alias for WebSockets if ($hdr(Host) == $null || !is_myself("sip:" + $hdr(Host))) { xlog("L_WARN", "Bad host $hdr(Host)\n"); xhttp_reply("403", "Forbidden", "", ""); exit; }
# Optional... validate Origin - make sure the client is from an # authorised website. For example, # # if ($hdr(Origin) != "http://communicator.MY_DOMAIN" # && $hdr(Origin) != "https://communicator.MY_DOMAIN") { # xlog("L_WARN", "Unauthorised client $hdr(Origin)\n"); # xhttp_reply("403", "Forbidden", "", ""); # exit; # }
# Optional... perform HTTP authentication
# ws_handle_handshake() exits (no further configuration file # processing of the request) when complete. if (ws_handle_handshake()) { # Optional... cache some information about the # successful connection exit; } }
HTTP authentication is not being properly set up. Any indications on how to perform this sucessfully?
Kind regards
Manuel
Hello,
from the logs you sent now, it appears that you have set_reply_close() in config, therefore the connection is closed after sending the reply.
Cheers, Daniel
The set_reply_close() should be removed from there.
For digest authentication, simply use the same functions as for sip (e.g., from auth/auth_db modules).
Cheers, Daniel
On 09/09/14 16:49, Manuel Camarg wrote:
According to this article I mentioned in the beginning:
http://nil.uniza.sk/sip/kamailio/configuring-kamailio-4x-websocket
In http:request they do straight away the set_reply_close();
I don't know exactly if this kamailio.cfg implementation may be useful for working with WSS:
event_route[xhttp:request] { set_reply_close(); set_reply_no_connect();
if ($Rp != MY_WS_PORT #!ifdef WITH_TLS && $Rp != MY_WSS_PORT #!endif ) { xlog("L_WARN", "HTTP request received on $Rp\n"); xhttp_reply("403", "Forbidden", "", ""); exit; }
xlog("L_DBG", "HTTP Request Received\n");
if ($hdr(Upgrade)=~"websocket" && $hdr(Connection)=~"Upgrade" && $rm=~"GET") {
# Validate Host - make sure the client is using the correct # alias for WebSockets if ($hdr(Host) == $null || !is_myself("sip:" + $hdr(Host))) { xlog("L_WARN", "Bad host $hdr(Host)\n"); xhttp_reply("403", "Forbidden", "", ""); exit; }
# Optional... validate Origin - make sure the client is from an # authorised website. For example, # # if ($hdr(Origin) != "http://communicator.MY_DOMAIN" # && $hdr(Origin) != "https://communicator.MY_DOMAIN") { # xlog("L_WARN", "Unauthorised client $hdr(Origin)\n"); # xhttp_reply("403", "Forbidden", "", ""); # exit; # }
# Optional... perform HTTP authentication
# ws_handle_handshake() exits (no further configuration file # processing of the request) when complete. if (ws_handle_handshake()) { # Optional... cache some information about the # successful connection exit; } }
HTTP authentication is not being properly set up. Any indications on how to perform this sucessfully?
Kind regards
Manuel
Hello,
from the logs you sent now, it appears that you have set_reply_close() in config, therefore the connection is closed after sending the reply.
Cheers, Daniel
Daniel-Constantin Mierla writes:
The set_reply_close() should be removed from there.
why is that? my wss clients work fine even when i have:
event_route[xhttp:request] { # Handle HTTP requests
set_reply_close(); set_reply_no_connect();
this was included in the original instructions when wss transport was introduced to kamailio.
-- juha
On 10/09/14 18:43, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The set_reply_close() should be removed from there.
why is that? my wss clients
are they ws (over tcp) or wss (over tls)?
work fine even when i have:
event_route[xhttp:request] { # Handle HTTP requests
set_reply_close(); set_reply_no_connect();
this was included in the original instructions when wss transport was introduced to kamailio.
I guess the example was built on top of the one for xhttp module which closes the connection after sending the http reply.
On the other hand, I remember that I tested with default example some time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using?
Cheers, Daniel
Daniel-Constantin Mierla writes:
On the other hand, I remember that I tested with default example some time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using?
i have used jsip based web client both with firefox and chrome browsers. i just tested yesterday with latest stable versions of both browsers and didn't have any problems.
-- juha
Hello Juha
They why you think i'm encountering this issue based on the beginning of this topic? http://lists.sip-router.org/pipermail/sr-users/2014-September/084699.html
Daniel:
However, more recent versions of browsers don't work with that anymore
Do you have an example of some functional wss system? (xhttp request route)
Regards
*Manuel Camargo* Teléfono: 638000836 eMail: sir.louen@gmail.com https://twitter.com/SirLouen [image: Ver el perfil de Manuel Camargo Lominchar en LinkedIn] http://es.linkedin.com/in/louen
2014-09-10 19:05 GMT+02:00 Juha Heinanen jh@tutpro.com:
Daniel-Constantin Mierla writes:
On the other hand, I remember that I tested with default example some time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using?
i have used jsip based web client both with firefox and chrome browsers. i just tested yesterday with latest stable versions of both browsers and didn't have any problems.
-- juha
Manuel Camarg writes:
They why you think i'm encountering this issue based on the beginning of this topic? http://lists.sip-router.org/pipermail/sr-users/2014-September/084699.html
perhaps it has something to do with sipml5. i'm using jssip based ws client. try with the jssip demo client to see if there is any difference.
-- juha
Hello,
On 10/09/14 23:15, Manuel Camarg wrote:
Hello Juha
They why you think i'm encountering this issue based on the beginning of this topic? http://lists.sip-router.org/pipermail/sr-users/2014-September/084699.html
Daniel:
However, more recent versions of browsers don't work with that anymore
Do you have an example of some functional wss system? (xhttp request route)
next is a piece of config that I used recently and worked.
Cheers, Daniel
event_route[xhttp:request] {
set_reply_no_connect();
if ($Rp != 8080 # MY_WS_PORT && $Rp != 8082 # MY_WSS_PORT
) { xlog("L_WARN", "HTTP request received on $Rp\n"); xhttp_reply("403", "Forbidden", "", ""); exit; }
xlog("L_DBG", "HTTP Request Received\n");
if ($hdr(Upgrade)=~"websocket" && $hdr(Connection)=~"Upgrade" && $rm=~"GET") {
# Validate Host - make sure the client is using the correct # alias for WebSockets if ($hdr(Host) == $null || !is_myself("sip:" + $hdr(Host))) { xlog("L_WARN", "Bad host $hdr(Host)\n"); xhttp_reply("403", "Forbidden", "", ""); exit; }
# ws_handle_handshake() exits (no further configuration file # processing of the request) when complete. if (ws_handle_handshake()) { # Optional... cache some information about the # successful connection exit; } }
xhttp_reply("404", "Not Found", "", ""); }
On 10/09/14 19:05, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
On the other hand, I remember that I tested with default example some time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using?
i have used jsip based web client both with firefox and chrome browsers. i just tested yesterday with latest stable versions of both browsers and didn't have any problems.
I am using beta version for firefox and chrome, aslo with jssip (might not be the latest version, though).
Cheers, Daniel
I used jssip during testing. It doesn't differ much from sipml5 from regular operations, but it does not work with wss (at least with my current config, the mentioned before)
Are you sure you are using WSS with that config or just WS? The problem is I cant debug since I have no errors in regular log :( just seems a handshake issue
*Manuel Camargo* Teléfono: 638000836 eMail: sir.louen@gmail.com https://twitter.com/SirLouen [image: Ver el perfil de Manuel Camargo Lominchar en LinkedIn] http://es.linkedin.com/in/louen
2014-09-11 12:40 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 10/09/14 19:05, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
On the other hand, I remember that I tested with default example some
time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using?
i have used jsip based web client both with firefox and chrome browsers. i just tested yesterday with latest stable versions of both browsers and didn't have any problems.
I am using beta version for firefox and chrome, aslo with jssip (might not be the latest version, though).
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany
On 11/09/14 16:30, Manuel Camarg wrote:
I used jssip during testing. It doesn't differ much from sipml5 from regular operations, but it does not work with wss (at least with my current config, the mentioned before)
Are you sure you are using WSS with that config or just WS? The problem is I cant debug since I have no errors in regular log :( just seems a handshake issue
One thing I also noticed lately, if I am on https page and try to make a ws (tcp) connection, the browser doesn't allow it.
What do you get in browser console?
Cheers, Daniel
*Manuel Camargo* Teléfono: 638000836 eMail: sir.louen@gmail.com mailto:sir.louen@gmail.com https://twitter.com/SirLouen Ver el perfil de Manuel Camargo Lominchar en LinkedIn http://es.linkedin.com/in/louen
2014-09-11 12:40 GMT+02:00 Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>:
On 10/09/14 19:05, Juha Heinanen wrote: Daniel-Constantin Mierla writes: On the other hand, I remember that I tested with default example some time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using? i have used jsip based web client both with firefox and chrome browsers. i just tested yesterday with latest stable versions of both browsers and didn't have any problems. I am using beta version for firefox and chrome, aslo with jssip (might not be the latest version, though). Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany
Daniel, websocket is not "downgradeable" under https, that's why I'm trying to make this work
As I said in the first message here is the error log in the browser:
In the Chrome console:
*__tsip_transport_ws_onerror * *__tsip_transport_ws_onclose *
Regards, Manuel
*Manuel Camargo* Teléfono: 638000836 eMail: sir.louen@gmail.com https://twitter.com/SirLouen [image: Ver el perfil de Manuel Camargo Lominchar en LinkedIn] http://es.linkedin.com/in/louen
2014-09-11 16:50 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 11/09/14 16:30, Manuel Camarg wrote:
I used jssip during testing. It doesn't differ much from sipml5 from regular operations, but it does not work with wss (at least with my current config, the mentioned before)
Are you sure you are using WSS with that config or just WS? The problem is I cant debug since I have no errors in regular log :( just seems a handshake issue
One thing I also noticed lately, if I am on https page and try to make a ws (tcp) connection, the browser doesn't allow it.
What do you get in browser console?
Cheers, Daniel
*Manuel Camargo* Teléfono: 638000836 eMail: sir.louen@gmail.com https://twitter.com/SirLouen [image: Ver el perfil de Manuel Camargo Lominchar en LinkedIn] http://es.linkedin.com/in/louen
2014-09-11 12:40 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
On 10/09/14 19:05, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
On the other hand, I remember that I tested with default example some
time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using?
i have used jsip based web client both with firefox and chrome browsers. i just tested yesterday with latest stable versions of both browsers and didn't have any problems.
I am using beta version for firefox and chrome, aslo with jssip (might not be the latest version, though).
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany
On 11/09/14 16:53, Manuel Camarg wrote:
Daniel, websocket is not "downgradeable" under https, that's why I'm trying to make this work
As I said in the first message here is the error log in the browser:
In the Chrome console:
/*__tsip_transport_ws_onerror */ /*__tsip_transport_ws_onclose */
Are these the only messages printed? In the javascript console of Chrome?
Daniel
/* */ Regards,/* */ Manuel
*Manuel Camargo* Teléfono: 638000836 eMail: sir.louen@gmail.com mailto:sir.louen@gmail.com https://twitter.com/SirLouen Ver el perfil de Manuel Camargo Lominchar en LinkedIn http://es.linkedin.com/in/louen
2014-09-11 16:50 GMT+02:00 Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>:
On 11/09/14 16:30, Manuel Camarg wrote:I used jssip during testing. It doesn't differ much from sipml5 from regular operations, but it does not work with wss (at least with my current config, the mentioned before) Are you sure you are using WSS with that config or just WS? The problem is I cant debug since I have no errors in regular log :( just seems a handshake issueOne thing I also noticed lately, if I am on https page and try to make a ws (tcp) connection, the browser doesn't allow it. What do you get in browser console? Cheers, Daniel*Manuel Camargo* Teléfono: 638000836 <tel:638000836> eMail: sir.louen@gmail.com <mailto:sir.louen@gmail.com> <https://twitter.com/SirLouen> Ver el perfil de Manuel Camargo Lominchar en LinkedIn <http://es.linkedin.com/in/louen> 2014-09-11 12:40 GMT+02:00 Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>>: On 10/09/14 19:05, Juha Heinanen wrote: Daniel-Constantin Mierla writes: On the other hand, I remember that I tested with default example some time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using? i have used jsip based web client both with firefox and chrome browsers. i just tested yesterday with latest stable versions of both browsers and didn't have any problems. I am using beta version for firefox and chrome, aslo with jssip (might not be the latest version, though). Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany-- Daniel-Constantin Mierla http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 -http://www.asipto.com Sep 22-25, Berlin, Germany
Daniel-Constantin Mierla writes:
Are you sure you are using WSS with that config or just WS? The problem is I cant debug since I have no errors in regular log :( just seems a handshake issue
One thing I also noticed lately, if I am on https page and try to make a ws (tcp) connection, the browser doesn't allow it.
i'm using only wss, i.e., my proxy is listening only on tls websocket port.
below is what i get to browser js console when connection is set up and my web client sends register request. i don't know how to get kamailio tls log at debug level.
-- juha
"Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | configuration parameters after validation:" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · via_host: "c090j2d3iko1.invalid"" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · password: NOT SHOWN" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · register_expires: 600" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · register: true" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · registrar_server: sip:test.tutpro.com" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · ws_server_max_reconnection: 3" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · ws_server_reconnection_timeout: 4" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · connection_recovery_min_interval: 2" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · connection_recovery_max_interval: 30" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · use_preloaded_route: false" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · no_answer_timeout: 60000" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · stun_servers: ["stun:stun.l.google.com:19302"]" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · turn_servers: []" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · trace_sip: true" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · hack_via_tcp: false" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · hack_ip_in_contact: false" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · uri: sip:jh@test.tutpro.com" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · ws_servers: [{"ws_uri":"wss://test.tutpro.com:8001","sip_uri":"sip:test.tutpro.com:8001;transport=ws;lr","weight":0,"status":0,"scheme":"WSS"}]" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · authorization_user: "jh"" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · display_name: "Juha Heinanen"" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · instance_id: "d9d16181-c87c-4e41-b4ce-f56280fbc135"" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · jssip_id: "lb46m"" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | · hostport_params: "test.tutpro.com"" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | user requested startup..." jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.transport | connecting to WebSocket wss://test.tutpro.com:8001" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:33 GMT+0300 (EEST) | jssip.ua | emitting event connecting" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:34 GMT+0300 (EEST) | jssip.transport | WebSocket wss://test.tutpro.com:8001 connected" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:34 GMT+0300 (EEST) | jssip.ua | connection state set to 0" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:34 GMT+0300 (EEST) | jssip.ua | emitting event newTransaction" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:34 GMT+0300 (EEST) | jssip.transaction.nict | emitting event stateChanged" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:34 GMT+0300 (EEST) | jssip.transport | sending WebSocket message:
REGISTER sip:test.tutpro.com SIP/2.0 Via: SIP/2.0/WSS c090j2d3iko1.invalid;branch=z9hG4bK3979772 Max-Forwards: 69 To: sip:jh@test.tutpro.com From: "Juha Heinanen" sip:jh@test.tutpro.com;tag=00a6ilq626 Call-ID: g9rm7pkhb0mijn9emmep8r CSeq: 81 REGISTER Contact: sip:ddr8h1o0@c090j2d3iko1.invalid;transport=ws;+sip.ice;reg-id=1;+sip.instance="urn:uuid:d9d16181-c87c-4e41-b4ce-f56280fbc135";expires=600 Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE Supported: path,gruu,outbound User-Agent: JsSIP 0.4.0-devel Content-Length: 0
" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:34 GMT+0300 (EEST) | jssip.ua | emitting event connected" jssip-devel.min.js:9 "Thu Sep 11 2014 17:54:34 GMT+0300 (EEST) | jssip.transport | received WebSocket text message:
SIP/2.0 401 Unauthorized ...
Hi Manuel,
If there is a websocket handshake error / incorrect port etc, then you will send an HTTP error and close the connection (otherwise non-websocket connections could use up resources).
If the handshake is successful, then the connection is upgraded and no HTTP final response is ever sent, hence the connection is not closed. Our implementation is working fine with this line in there.
The log excerpt you gave on Monday shows two connections. The second was for a normal browser GET, not a websocket, so it finds the end-of-header marker instead of the Upgrade header and closes the connection.
The first connection doesn't look like it even gets as far as the event route before it is disconnected. I suspect a TLS handshake failure.
Can you look at a network trace of the connection? Wireshark will show if there is a certificate failure and which side sent it.
Regards,
Hugh
-----Original Message----- From: sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Daniel-Constantin Mierla Sent: 10 September 2014 18:00 To: Juha Heinanen; Kamailio (SER) - Users Mailing List Cc: Manuel Camarg Subject: Re: [SR-Users] TLS Handshake failing with WSS
On 10/09/14 18:43, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The set_reply_close() should be removed from there.
why is that? my wss clients
are they ws (over tcp) or wss (over tls)?
work fine even when i have:
event_route[xhttp:request] { # Handle HTTP requests
set_reply_close();
set_reply_no_connect();
this was included in the original instructions when wss transport was
introduced to kamailio.
I guess the example was built on top of the one for xhttp module which closes the connection after sending the http reply.
On the other hand, I remember that I tested with default example some time ago and worked. However, more recent versions of browsers don't work with that anymore. What browser (or wss client) are you using?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
________________________________ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
-
Daniel-Constantin Mierla -
Juha Heinanen -
Manuel Camarg -
Waite, Hugh