[SR-Users] Kamailio -topoh- and Via headers
Gonzalo Gasca
gascagonzalo at gmail.com
Wed Oct 8 07:53:15 CEST 2014
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
On Tue, Oct 7, 2014 at 1:57 AM, Gonzalo Gasca <gascagonzalo at gmail.com> wrote:
> 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
> <miconda at gmail.com> wrote:
>> Do you refer to the http response only? Or to SIP as well?
>>
>> Daniel
>>
>>
>> On 07/10/14 06:19, Gonzalo Gasca wrote:
>>>
>>> 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
>>> <miconda at gmail.com> wrote:
>>>>
>>>> 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
>>>>
>>>>
>>>> On 06/10/14 02:39, Gonzalo Gasca wrote:
>>>>
>>>> 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?
>>>>
>>>> From Kamailio logs:
>>>>
>>>> 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 at df7jal23ls0d.invalid;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)
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> 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
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>
>> --
>> Daniel-Constantin Mierla
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kamailio.log.zip
Type: application/zip
Size: 25101 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141007/55a2e05b/attachment.zip>
More information about the sr-users
mailing list