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
On 08/10/14 07:53, Gonzalo Gasca wrote:
Hi Daniel,
Just a quick update, I rem
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 r
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
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.
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 r
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/W
