ua sets up tcp connection to sr and registers. expires parameter of
contact header is 3600 and tcp_persistent_flag was set before save() was
called.
after registering, ua sends some other requests and becomes idle 8
second later. 2 minutes 10 seconds after that, wireshark shows that sr
closes the tcp connection.
why is tcp connection closed? it looks like a bug to me, but perhaps i
am missing something?
-- juha
- kamailio core dumps when it can't verify ssl certificate. Propably an error code the module does not parse.
- I can't get the "DN" for a result. All attributes work.
Will dig deeper into this, but if someone has solved these issues or seen them, I would appreciate feedback.
Cheers,
/O
There's been a lot of virtual slander of the work in the IETF on this
list lately...
I keep wondering, why doesn't people like us start working more in the
IETF and change stuff? Are we not patience enough, are we not
brilliant enough?
For myself I can't spend much time on it, since it doesn't generate
any immediate revenue. There's a lot of stuff I could do, but at the
end of the month, I would have no salary that pays for food... It's
quite simple.
Which means that the result in the IETF is far away from reality and
that we reach further separation between IETF SIP and practical
implementations, which is BAD for the overall community.
/O
Hi!
I'm just testing topoh module and it does not protect relayed REGISTER
requests - why?
I found this piece of code which looks guilty:
int th_skip_msg(sip_msg_t *msg)
{
if((get_cseq(msg)->method_id)&(METHOD_REGISTER|METHOD_PUBLISH))
return 1;
return 0;
}
But why? IMO it is a valid use case, e.g. in our office all SIP requests
ae sent via an outbound proxy before entering Internet. This
outboundproxy does topology hiding - but currently not for REGISTER :-(
regards
klaus
As I see in sip-router and in kamailio, the mhomed implementation is very very slow . For each SIP packet a
temporary socket is created, connected to the remote host and than checked to see what interface was selected
to connect the socket(see method get_out_socket() in forward.c)
As test have shown, this implementation, albeit correct from a funtional point of view, it's really too slow
(or too expensive) to be used in medium-large production setups.
I am currently working on a patch that mitigates this problem. The way the patch works is like this:
1. Get the routing table from the kernel via NETLINK sockets(done at start)
2. Construct a link list of routes, each entry for one interface(either real of virtual). The structure will hold
the address of the interface and the destination (as reported by route -n)(this will be a CIDR entry). Also it's
decided if on that interface a default route has been assigned(done at start)
3. get_out_socket() will be changed to loop thru the list described above and decide based on the destination member
of the struct describe above on what interface the packet is to be routed. If no destination is matched than the
default one is selected.(done for each packet)
4.A NETLINK socket will be added to the poll()ing loop so it can monitor the changes in the kernel's routing table
and update the internal structure if necessary.(done at start)(The table is updated only if administration changes the
routing table via route or ip route commands)
I have implemented the first 3 steps and preliminary tests look ok. step for is required only if we want updates on
the routing table in real time.
Limitations:
1. This only works for Linux, AF_INET sockets. AF_INET6 is also supported but i don't know to what extent
2. For BSD, route sockets should replace the NETLINK sockets
What are your suggestion about this? Should this patch (when completely finished) be commited?
Thanks for any suggestions!
Marius.