Hi,
I was investigating an issue we had on siptrace with homer: the destination port of all SIP responses to our websocket SIP client was always set to 5060 in the HEP headers of the traced packets sent to Homer, but the websocket client is not actually communicating on port 5060.
When I set the global config option `force_rport=yes`, the trace dst port started to be correct.
Digging further, I found this macro in forward.h:
1 /* use src_ip, port=src_port if rport, via port if via port, 5060 otherwise */ 2 #define update_sock_struct_from_ip( to, msg ) \ 3 init_su((to), &(msg)->rcv.src_ip, \ 4 (((msg)->via1->rport)|| \ 5 (((msg)->msg_flags|global_req_flags)&FL_FORCE_RPORT))? \ 6 (msg)->rcv.src_port: \ 7 ((msg)->via1->port)?(msg)->via1->port: SIP_PORT )
And I suspect that to conform to the description, line 4 should be:
4 (((msg)->rcv.src_port)|| \
instead. This way, I shouldn't need to set `force_rport=yes` to have the tm callbacks containing the correct response dst port.
Any thoughts on this?
Hello,
the specs say that the reply has to be sent to the port in Via header, if rport is not specified (either as rport param in Via or forced by admin in config).
So, at a quick look the macro seems ok from my point of view, it its purpose is to figure out the port where to send the reply.
Cheers, Daniel
On 23/09/15 12:41, Camille Oudot wrote:
Hi,
I was investigating an issue we had on siptrace with homer: the destination port of all SIP responses to our websocket SIP client was always set to 5060 in the HEP headers of the traced packets sent to Homer, but the websocket client is not actually communicating on port 5060.
When I set the global config option `force_rport=yes`, the trace dst port started to be correct.
Digging further, I found this macro in forward.h:
1 /* use src_ip, port=src_port if rport, via port if via port, 5060 otherwise */ 2 #define update_sock_struct_from_ip( to, msg ) \ 3 init_su((to), &(msg)->rcv.src_ip, \ 4 (((msg)->via1->rport)|| \ 5 (((msg)->msg_flags|global_req_flags)&FL_FORCE_RPORT))? \ 6 (msg)->rcv.src_port: \ 7 ((msg)->via1->port)?(msg)->via1->port: SIP_PORT )
And I suspect that to conform to the description, line 4 should be:
4 (((msg)->rcv.src_port)|| \
instead. This way, I shouldn't need to set `force_rport=yes` to have the tm callbacks containing the correct response dst port.
Any thoughts on this?
Le Wed, 23 Sep 2015 12:51:12 +0200, Daniel-Constantin Mierla miconda@gmail.com a écrit :
the specs say that the reply has to be sent to the port in Via header, if rport is not specified (either as rport param in Via or forced by admin in config).
So, at a quick look the macro seems ok from my point of view, it its purpose is to figure out the port where to send the reply.
Ok I see. Then kamailio needs to explicitely add the rport Via parameter for the infos in the tm callback to be correct, even for websocket connections.
Maybe this macro could be updated to handle the websocket-specific case: rport is not mandatory, and the response dst port must be the one set in the msg->rcv structure (no other choice but to reuse the established websocket).
-
Camille Oudot -
Daniel-Constantin Mierla