23 Sep
2015
23 Sep
'15
1:41 p.m.
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?
--
Camille
23 Sep
23 Sep
1:51 p.m.
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?
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat
2:13 p.m.
Le Wed, 23 Sep 2015 12:51:12 +0200,
Daniel-Constantin Mierla <miconda(a)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
3352
days inactive
3352
days old
2 comments
2 participants
participants (2)
-
Camille Oudot -
Daniel-Constantin Mierla