[SR-Users] Kamailio -topoh- and Via headers

Discussion:

Gonzalo Gasca

2014-10-06 00:39:25 UTC

I'm using Kamailio as SIP Registrar using Websockets.
My topology looks like this:

Sip client (sipml5) ---> wss ---> Nginx ---> ws ---> Kamailio 4.1.5

When I look into my SipMl5 application in the Register Message 200 OK
from Kamailio I see the Nginx private IP address 172.31.22.2

Via: SIP/2.0/WSS
df7jal23ls0d.invalid;rport=37111;received=172.31.22.2;branch=z9hG4bKtv75otkzmPVsdNWevweLt4TN9JnLnQ0p

How can I remove private IP Address in Via header to achieve topology hiding?
Oct 6 00:34:21 ip-172-31-27-85 /usr/sbin/kamailio[8941]: DEBUG:
registrar [reply.c:374]: build_contact(): created Contact HF: Contact:
<sips:gogasca-QsEt/***@public.gmane.org;rtcweb-breaker=no;transport=wss>;expires=200#015#012
Oct 6 00:34:21 ip-172-31-27-85 /usr/sbin/kamailio[8941]: DEBUG: sl
[sl.c:288]: send_reply(): reply in stateless mode (sl)
Oct 6 00:34:21 ip-172-31-27-85 /usr/sbin/kamailio[8941]: DEBUG:
<core> [msg_translator.c:204]: check_via_address():
check_via_address(172.31.22.2, df7jal23ls0d.invalid, 0)
O

Version: kamailio 4.1.5 (x86_64/linux)

# ------ topoh --------

modparam("topoh", "mask_key", "opencall")
modparam("topoh", "mask_ip", "<Public IP Address of Kamailio>")
modparam("topoh", "vparam_prefix", "llamato")
modparam("topoh", "mask_callid", 1)
modparam("topoh", "sanity_checks", 1)

Daniel-Constantin Mierla

2014-10-06 08:06:18 UTC

Permalink

Hello,

received is added because the client requests that via rport parameter
or because of using rport. If the processed request is REGISTER, you can
try removing rport/received parameters from Via, then do
msg_apply_changes().

However, without rport enforcement, the response might not be routed
back, because SIP says to send it back to the address in Via, which is
invalid in websocket case.

Maybe you can rewrite headers in nginx or use kamailio as a proxy/load
balancer instead of nginx and then you have plenty of options to play
with sip headers.

Cheers,
Daniel

Post by Gonzalo Gasca
I'm using Kamailio as SIP Registrar using Websockets.
Sip client (sipml5) ---> wss ---> Nginx ---> ws ---> Kamailio 4.1.5
When I look into my SipMl5 application in the Register Message 200 OK
from Kamailio I see the Nginx private IP address 172.31.22.2
Via: SIP/2.0/WSS
df7jal23ls0d.invalid;rport=37111;received=172.31.22.2;branch=z9hG4bKtv75otkzmPVsdNWevweLt4TN9JnLnQ0p
How can I remove private IP Address in Via header to achieve topology hiding?
Oct 6 00:34:21 ip-172-31-27-85 /usr/sbin/kamailio[8941]: DEBUG: sl
[sl.c:288]: send_reply(): reply in stateless mode (sl)
check_via_address(172.31.22.2, df7jal23ls0d.invalid, 0)
O
Version: kamailio 4.1.5 (x86_64/linux)
# ------ topoh --------
modparam("topoh", "mask_key", "opencall")
modparam("topoh", "mask_ip", "<Public IP Address of Kamailio>")
modparam("topoh", "vparam_prefix", "llamato")
modparam("topoh", "mask_callid", 1)
modparam("topoh", "sanity_checks", 1)
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Gonzalo Gasca

2014-10-07 04:19:49 UTC

Permalink

Daniel,
I will re-write it in Kamailio, seems to be that during initial WS
negotiation (HTTP Connection Upgrade), Kamailio is already including
the Via header:

Via: SIP/2.0/TCP 172.31.22.2:37137\r\n

Which as you said is perfectly fine, Im just trying to hide my info.

Thanks
-Gonzalo

No. Time Source Destination
Protocol Length Info
13 21:00:41.016 172.31.22.2 172.31.27.85 HTTP
814 GET / HTTP/1.1

Frame 13: 814 bytes on wire (6512 bits), 814 bytes captured (6512 bits)
Ethernet II, Src: 06:17:4e:87:69:98 (06:17:4e:87:69:98), Dst:
06:79:4f:ef:e3:d6 (06:79:4f:ef:e3:d6)
Internet Protocol Version 4, Src: 172.31.22.2 (172.31.22.2), Dst:
172.31.27.85 (172.31.27.85)
Transmission Control Protocol, Src Port: 37137 (37137), Dst Port:
na-localise (5062), Seq: 1, Ack: 1, Len: 748
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Host: ramenlabs.io:5062\r\n
Upgrade: websocket\r\n
Connection: Upgrade\r\n
Pragma: no-cache\r\n
Cache-Control: no-cache\r\n
Origin: https://www.ramenlabs.io\r\n
Sec-WebSocket-Version: 13\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2180.0
Safari/537.36\r\n
Accept-Encoding: gzip, deflate, sdch\r\n
Accept-Language: en-US,en;q=0.8\r\n
Cookie: __utmt=1;
__utma=257296520.931028039.1410155955.1412651114.1412653901.42;
__utmb=257296520.1.10.1412653901; __utmc=257296520;
__utmz=257296520.1410155955.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)\r\n
Sec-WebSocket-Key: QR+qynpQ7+7psMScB/WkQQ==\r\n
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits\r\n
Sec-WebSocket-Protocol: sip\r\n
\r\n
[Full request URI: http://ramenlabs.io:5062/]

No. Time Source Destination
Protocol Length Info
15 21:00:41.017 172.31.27.85 172.31.22.2 HTTP
314 HTTP/1.1 101 Switching Protocols

Frame 15: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits)
Ethernet II, Src: 06:79:4f:ef:e3:d6 (06:79:4f:ef:e3:d6), Dst:
06:17:4e:87:69:98 (06:17:4e:87:69:98)
Internet Protocol Version 4, Src: 172.31.27.85 (172.31.27.85), Dst:
172.31.22.2 (172.31.22.2)
Transmission Control Protocol, Src Port: na-localise (5062), Dst Port:
37137 (37137), Seq: 1, Ack: 749, Len: 248
Hypertext Transfer Protocol
HTTP/1.1 101 Switching Protocols\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 101 Switching Protocols\r\n]
[Message: HTTP/1.1 101 Switching Protocols\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 101
Response Phrase: Switching Protocols
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Sec-WebSocket-Protocol: sip\r\n
Upgrade: websocket\r\n
Connection: upgrade\r\n
Sec-WebSocket-Accept: rb6Ng4aiTHNyZatk74btU9vZNPk=\r\n
Server: Llamato SipRegistrar(1.0)\r\n
Content-Length: 0\r\n
\r\n

On Mon, Oct 6, 2014 at 1:06 AM, Daniel-Constantin Mierla

Post by Daniel-Constantin Mierla
Hello,
received is added because the client requests that via rport parameter or
because of using rport. If the processed request is REGISTER, you can try
removing rport/received parameters from Via, then do msg_apply_changes().
However, without rport enforcement, the response might not be routed back,
because SIP says to send it back to the address in Via, which is invalid in
websocket case.
Maybe you can rewrite headers in nginx or use kamailio as a proxy/load
balancer instead of nginx and then you have plenty of options to play with
sip headers.
Cheers,
Daniel
I'm using Kamailio as SIP Registrar using Websockets.
Sip client (sipml5) ---> wss ---> Nginx ---> ws ---> Kamailio 4.1.5
When I look into my SipMl5 application in the Register Message 200 OK
from Kamailio I see the Nginx private IP address 172.31.22.2
Via: SIP/2.0/WSS
df7jal23ls0d.invalid;rport=37111;received=172.31.22.2;branch=z9hG4bKtv75otkzmPVsdNWevweLt4TN9JnLnQ0p
How can I remove private IP Address in Via header to achieve topology
hiding?
Oct 6 00:34:21 ip-172-31-27-85 /usr/sbin/kamailio[8941]: DEBUG: sl
[sl.c:288]: send_reply(): reply in stateless mode (sl)
check_via_address(172.31.22.2, df7jal23ls0d.invalid, 0)
O
Version: kamailio 4.1.5 (x86_64/linux)
# ------ topoh --------
modparam("topoh", "mask_key", "opencall")
modparam("topoh", "mask_ip", "<Public IP Address of Kamailio>")
modparam("topoh", "vparam_prefix", "llamato")
modparam("topoh", "mask_callid", 1)
modparam("topoh", "sanity_checks", 1)
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Daniel-Constantin Mierla

2014-10-07 07:01:55 UTC

Permalink

Do you refer to the http response only? Or to SIP as well?

Daniel

Post by Gonzalo Gasca
Daniel,
I will re-write it in Kamailio, seems to be that during initial WS
negotiation (HTTP Connection Upgrade), Kamailio is already including
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Which as you said is perfectly fine, Im just trying to hide my info.
Thanks
-Gonzalo
No. Time Source Destination
Protocol Length Info
13 21:00:41.016 172.31.22.2 172.31.27.85 HTTP
814 GET / HTTP/1.1
Frame 13: 814 bytes on wire (6512 bits), 814 bytes captured (6512 bits)
06:79:4f:ef:e3:d6 (06:79:4f:ef:e3:d6)
172.31.27.85 (172.31.27.85)
na-localise (5062), Seq: 1, Ack: 1, Len: 748
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Host: ramenlabs.io:5062\r\n
Upgrade: websocket\r\n
Connection: Upgrade\r\n
Pragma: no-cache\r\n
Cache-Control: no-cache\r\n
Origin: https://www.ramenlabs.io\r\n
Sec-WebSocket-Version: 13\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2180.0
Safari/537.36\r\n
Accept-Encoding: gzip, deflate, sdch\r\n
Accept-Language: en-US,en;q=0.8\r\n
Cookie: __utmt=1;
__utma=257296520.931028039.1410155955.1412651114.1412653901.42;
__utmb=257296520.1.10.1412653901; __utmc=257296520;
__utmz=257296520.1410155955.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)\r\n
Sec-WebSocket-Key: QR+qynpQ7+7psMScB/WkQQ==\r\n
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits\r\n
Sec-WebSocket-Protocol: sip\r\n
\r\n
[Full request URI: http://ramenlabs.io:5062/]
No. Time Source Destination
Protocol Length Info
15 21:00:41.017 172.31.27.85 172.31.22.2 HTTP
314 HTTP/1.1 101 Switching Protocols
Frame 15: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits)
06:17:4e:87:69:98 (06:17:4e:87:69:98)
172.31.22.2 (172.31.22.2)
37137 (37137), Seq: 1, Ack: 749, Len: 248
Hypertext Transfer Protocol
HTTP/1.1 101 Switching Protocols\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 101 Switching Protocols\r\n]
[Message: HTTP/1.1 101 Switching Protocols\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 101
Response Phrase: Switching Protocols
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Sec-WebSocket-Protocol: sip\r\n
Upgrade: websocket\r\n
Connection: upgrade\r\n
Sec-WebSocket-Accept: rb6Ng4aiTHNyZatk74btU9vZNPk=\r\n
Server: Llamato SipRegistrar(1.0)\r\n
Content-Length: 0\r\n
\r\n
On Mon, Oct 6, 2014 at 1:06 AM, Daniel-Constantin Mierla

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Gonzalo Gasca

2014-10-07 08:57:03 UTC

Permalink

Hi Daniel,

I see the "Via" header in both initial Websocket upgrade response
(101) and in SIP 200 OK from Kamailio when Sipml5 client is
registering.

At SIP level including rport in initial REGISTER message from client
and getting a "received" field from Kamailio makes sense and I will
use your recommended solution.

When I look at this Section:
https://tools.ietf.org/html/rfc7118#section-5.3

I have WSS at client level hence I expect users not to see WS messages
including the "received" field but...
I'm wondering if in the case of WS(Not secure), Kamailio replying to
the 101 WS using Via header may reveal inside information and if it is
possible to change this?

Protocols\r\n]
[Message: HTTP/1.1 101 Switching Protocols\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 101
Response Phrase: Switching Protocols
--> Via: SIP/2.0/TCP 172.31.22.2:37137\r\n

Thanks Daniel

-Gonzalo

On Tue, Oct 7, 2014 at 12:01 AM, Daniel-Constantin Mierla

Post by Daniel-Constantin Mierla
Do you refer to the http response only? Or to SIP as well?
Daniel

Post by Gonzalo Gasca
Daniel,
I will re-write it in Kamailio, seems to be that during initial WS
negotiation (HTTP Connection Upgrade), Kamailio is already including
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Which as you said is perfectly fine, Im just trying to hide my info.
Thanks
-Gonzalo
No. Time Source Destination
Protocol Length Info
13 21:00:41.016 172.31.22.2 172.31.27.85 HTTP
814 GET / HTTP/1.1
Frame 13: 814 bytes on wire (6512 bits), 814 bytes captured (6512 bits)
06:79:4f:ef:e3:d6 (06:79:4f:ef:e3:d6)
172.31.27.85 (172.31.27.85)
na-localise (5062), Seq: 1, Ack: 1, Len: 748
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Host: ramenlabs.io:5062\r\n
Upgrade: websocket\r\n
Connection: Upgrade\r\n
Pragma: no-cache\r\n
Cache-Control: no-cache\r\n
Origin: https://www.ramenlabs.io\r\n
Sec-WebSocket-Version: 13\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2180.0
Safari/537.36\r\n
Accept-Encoding: gzip, deflate, sdch\r\n
Accept-Language: en-US,en;q=0.8\r\n
Cookie: __utmt=1;
__utma=257296520.931028039.1410155955.1412651114.1412653901.42;
__utmb=257296520.1.10.1412653901; __utmc=257296520;
__utmz=257296520.1410155955.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)\r\n
Sec-WebSocket-Key: QR+qynpQ7+7psMScB/WkQQ==\r\n
Sec-WebSocket-Extensions: permessage-deflate;
client_max_window_bits\r\n
Sec-WebSocket-Protocol: sip\r\n
\r\n
[Full request URI: http://ramenlabs.io:5062/]
No. Time Source Destination
Protocol Length Info
15 21:00:41.017 172.31.27.85 172.31.22.2 HTTP
314 HTTP/1.1 101 Switching Protocols
Frame 15: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits)
06:17:4e:87:69:98 (06:17:4e:87:69:98)
172.31.22.2 (172.31.22.2)
37137 (37137), Seq: 1, Ack: 749, Len: 248
Hypertext Transfer Protocol
HTTP/1.1 101 Switching Protocols\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 101 Switching
Protocols\r\n]
[Message: HTTP/1.1 101 Switching Protocols\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 101
Response Phrase: Switching Protocols
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Sec-WebSocket-Protocol: sip\r\n
Upgrade: websocket\r\n
Connection: upgrade\r\n
Sec-WebSocket-Accept: rb6Ng4aiTHNyZatk74btU9vZNPk=\r\n
Server: Llamato SipRegistrar(1.0)\r\n
Content-Length: 0\r\n
\r\n
On Mon, Oct 6, 2014 at 1:06 AM, Daniel-Constantin Mierla

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Gonzalo Gasca

2014-10-08 05:53:15 UTC

Permalink

Hi Daniel,

Just a quick update, I remove the rport from sipML5 request and I
still see Kamailio adding the "received=<Proxy IP Address>" field into
Via at SIP level.
I found textops module to remove this parameter is this a good idea?

On the other side, Via header at WS level is inserted, not sure if
this is expected for Websockets.

Thanks so much Daniel

-Gonzalo

Post by Gonzalo Gasca
Hi Daniel,
I see the "Via" header in both initial Websocket upgrade response
(101) and in SIP 200 OK from Kamailio when Sipml5 client is
registering.
At SIP level including rport in initial REGISTER message from client
and getting a "received" field from Kamailio makes sense and I will
use your recommended solution.
https://tools.ietf.org/html/rfc7118#section-5.3
I have WSS at client level hence I expect users not to see WS messages
including the "received" field but...
I'm wondering if in the case of WS(Not secure), Kamailio replying to
the 101 WS using Via header may reveal inside information and if it is
possible to change this?
Protocols\r\n]
[Message: HTTP/1.1 101 Switching Protocols\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 101
Response Phrase: Switching Protocols
--> Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Thanks Daniel
-Gonzalo
On Tue, Oct 7, 2014 at 12:01 AM, Daniel-Constantin Mierla

Post by Daniel-Constantin Mierla
Do you refer to the http response only? Or to SIP as well?
Daniel

Post by Gonzalo Gasca
Daniel,
I will re-write it in Kamailio, seems to be that during initial WS
negotiation (HTTP Connection Upgrade), Kamailio is already including
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Which as you said is perfectly fine, Im just trying to hide my info.
Thanks
-Gonzalo
No. Time Source Destination
Protocol Length Info
13 21:00:41.016 172.31.22.2 172.31.27.85 HTTP
814 GET / HTTP/1.1
Frame 13: 814 bytes on wire (6512 bits), 814 bytes captured (6512 bits)
06:79:4f:ef:e3:d6 (06:79:4f:ef:e3:d6)
172.31.27.85 (172.31.27.85)
na-localise (5062), Seq: 1, Ack: 1, Len: 748
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Host: ramenlabs.io:5062\r\n
Upgrade: websocket\r\n
Connection: Upgrade\r\n
Pragma: no-cache\r\n
Cache-Control: no-cache\r\n
Origin: https://www.ramenlabs.io\r\n
Sec-WebSocket-Version: 13\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2180.0
Safari/537.36\r\n
Accept-Encoding: gzip, deflate, sdch\r\n
Accept-Language: en-US,en;q=0.8\r\n
Cookie: __utmt=1;
__utma=257296520.931028039.1410155955.1412651114.1412653901.42;
__utmb=257296520.1.10.1412653901; __utmc=257296520;
__utmz=257296520.1410155955.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)\r\n
Sec-WebSocket-Key: QR+qynpQ7+7psMScB/WkQQ==\r\n
Sec-WebSocket-Extensions: permessage-deflate;
client_max_window_bits\r\n
Sec-WebSocket-Protocol: sip\r\n
\r\n
[Full request URI: http://ramenlabs.io:5062/]
No. Time Source Destination
Protocol Length Info
15 21:00:41.017 172.31.27.85 172.31.22.2 HTTP
314 HTTP/1.1 101 Switching Protocols
Frame 15: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits)
06:17:4e:87:69:98 (06:17:4e:87:69:98)
172.31.22.2 (172.31.22.2)
37137 (37137), Seq: 1, Ack: 749, Len: 248
Hypertext Transfer Protocol
HTTP/1.1 101 Switching Protocols\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 101 Switching Protocols\r\n]
[Message: HTTP/1.1 101 Switching Protocols\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 101
Response Phrase: Switching Protocols
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Sec-WebSocket-Protocol: sip\r\n
Upgrade: websocket\r\n
Connection: upgrade\r\n
Sec-WebSocket-Accept: rb6Ng4aiTHNyZatk74btU9vZNPk=\r\n
Server: Llamato SipRegistrar(1.0)\r\n
Content-Length: 0\r\n
\r\n
On Mon, Oct 6, 2014 at 1:06 AM, Daniel-Constantin Mierla

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Daniel-Constantin Mierla

2014-10-08 11:29:00 UTC

Permalink

Hello,

the received is added because the ip/address in via is not the same as
source address. It is a section in an rfc about that.

If textops can help with that, then it should be ok if you do it.

Cheers,
Daniel

Post by Gonzalo Gasca
Hi Daniel,
Just a quick update, I remove the rport from sipML5 request and I
still see Kamailio adding the "received=<Proxy IP Address>" field into
Via at SIP level.
I found textops module to remove this parameter is this a good idea?
On the other side, Via header at WS level is inserted, not sure if
this is expected for Websockets.
Thanks so much Daniel
-Gonzalo

Post by Daniel-Constantin Mierla
Do you refer to the http response only? Or to SIP as well?
Daniel

Post by Gonzalo Gasca
Daniel,
I will re-write it in Kamailio, seems to be that during initial WS
negotiation (HTTP Connection Upgrade), Kamailio is already including
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Which as you said is perfectly fine, Im just trying to hide my info.
Thanks
-Gonzalo
No. Time Source Destination
Protocol Length Info
13 21:00:41.016 172.31.22.2 172.31.27.85 HTTP
814 GET / HTTP/1.1
Frame 13: 814 bytes on wire (6512 bits), 814 bytes captured (6512 bits)
06:79:4f:ef:e3:d6 (06:79:4f:ef:e3:d6)
172.31.27.85 (172.31.27.85)
na-localise (5062), Seq: 1, Ack: 1, Len: 748
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Host: ramenlabs.io:5062\r\n
Upgrade: websocket\r\n
Connection: Upgrade\r\n
Pragma: no-cache\r\n
Cache-Control: no-cache\r\n
Origin: https://www.ramenlabs.io\r\n
Sec-WebSocket-Version: 13\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2180.0
Safari/537.36\r\n
Accept-Encoding: gzip, deflate, sdch\r\n
Accept-Language: en-US,en;q=0.8\r\n
Cookie: __utmt=1;
__utma=257296520.931028039.1410155955.1412651114.1412653901.42;
__utmb=257296520.1.10.1412653901; __utmc=257296520;
__utmz=257296520.1410155955.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)\r\n
Sec-WebSocket-Key: QR+qynpQ7+7psMScB/WkQQ==\r\n
Sec-WebSocket-Extensions: permessage-deflate;
client_max_window_bits\r\n
Sec-WebSocket-Protocol: sip\r\n
\r\n
[Full request URI: http://ramenlabs.io:5062/]
No. Time Source Destination
Protocol Length Info
15 21:00:41.017 172.31.27.85 172.31.22.2 HTTP
314 HTTP/1.1 101 Switching Protocols
Frame 15: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits)
06:17:4e:87:69:98 (06:17:4e:87:69:98)
172.31.22.2 (172.31.22.2)
37137 (37137), Seq: 1, Ack: 749, Len: 248
Hypertext Transfer Protocol
HTTP/1.1 101 Switching Protocols\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 101 Switching Protocols\r\n]
[Message: HTTP/1.1 101 Switching Protocols\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 101
Response Phrase: Switching Protocols
Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
Sec-WebSocket-Protocol: sip\r\n
Upgrade: websocket\r\n
Connection: upgrade\r\n
Sec-WebSocket-Accept: rb6Ng4aiTHNyZatk74btU9vZNPk=\r\n
Server: Llamato SipRegistrar(1.0)\r\n
Content-Length: 0\r\n
\r\n
On Mon, Oct 6, 2014 at 1:06 AM, Daniel-Constantin Mierla

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda