Hello,
if i use append_branch together to divert a call after events like 408 the Dialog modoule seems suddenly to have problems to find the call even in matching mode 2
Dec 8 12:14:12 uplink01 /usr/sbin/kamailio[29001]: DBG:dialog:run_dlg_callbacks: dialog=0xb57d1e38, type=256
Dec 8 12:14:12 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:internal_get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:12 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:internal_get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:12 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:12 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:dlg_onroute: Callid '034b1e34e1000012cb59@csgmc1' not found
Dec 8 12:14:14 uplink01 /usr/sbin/kamailio[29001]: DBG:dialog:run_dlg_callbacks: dialog=0xb57d1e38, type=256
Dec 8 12:14:14 uplink01 /usr/sbin/kamailio[29001]: DBG:sst:sst_dialog_response_fwded_CB: Dialog seen REPLY 200 OK
Dec 8 12:14:14 uplink01 /usr/sbin/kamailio[29001]: DBG:sst:sst_dialog_response_fwded_CB: appending the Session-Expires: header to the 2XX reply. UAC will deal with it.
Dec 8 12:14:14 uplink01 /usr/sbin/kamailio[29001]: DBG:dialog:run_dlg_callbacks: dialog=0xb57d1e38, type=256
Dec 8 12:14:14 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:internal_get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:14 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:internal_get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:14 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:14 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:dlg_onroute: Callid '034b1e34e1000012cb59@csgmc1' not found
Dec 8 12:14:15 uplink01 /usr/sbin/kamailio[29004]: DBG:dialog:next_state_dlg: unref dlg 0xb57d1e38 with 1 -> 2
Dec 8 12:14:15 uplink01 /usr/sbin/kamailio[29004]: DBG:dialog:next_state_dlg: dialog 0xb57d1e38 changed from state 3 to state 3, due event 1
Dec 8 12:14:19 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:internal_get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:19 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:internal_get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:19 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:get_dlg: no dialog callid='034b1e34e1000012cb59@csgmc1' found
Dec 8 12:14:19 uplink01 /usr/sbin/kamailio[29000]: DBG:dialog:dlg_onroute: Callid '034b1e34e1000012cb59@csgmc1' not found
Dec 8 12:15:11 uplink01 /usr/sbin/kamailio[29011]: DBG:dialog:internal_mi_print_dlgs: printing 4096 dialogs
uplink01:~# kamctl fifo dlg_list
dialog:: hash=2425:542696298
state:: 3
timestart:: 1260270850
timeout:: 43270
callid:: 034b1e34e1000012cb59@csgmc1
from_uri:: sip:Anonymous@dus.net
from_tag:: 7b94728b
caller_contact:: sip:sipd@62.134.16.100:5060;transport=udp
caller_cseq:: 42
caller_route_set:: <sip:83.125.8.88;lr=on;ftag=7b94728b;did=979.5474de15;vsf=AAAAAHFcXV9BXV9GQHJUNUUcQFRHNC4xNi4xMDA->,<sip:62.134.16.104;lr=on>
caller_bind_addr:: udp:94.228.106.69:5060
to_uri:: sip:da9040322210302510@62.134.16.104
to_tag:: as1441dd9c
callee_contact:: sip:01728595562@83.125.8.82
callee_cseq:: 42
callee_route_set::
callee_bind_addr:: udp:94.228.106.69:5060
any idea what could cause this?
Freundliche Grüße
Mike van Stijn
Schoenland Online GmbH
Technology Operations
Professional System Engineer
Tel. 0221 / 8455-1866
Fax 0221 / 8455-2428
mike.vanstijn(a)schoenland.net
www.schoenland.net
Think before you print.
Gesetzliche Pflichtangaben:
Schoenland Online GmbH, Sitz der Gesellschaft ist Köln, Amtsgericht Köln HRB 59449, WEEE-Reg.-Nr.: DE57403598; Geschäftsführer: Daniel Schoenland, Henning Keil; Zuständige Aufsichtsbehörde: Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen Tulpenfeld 4, 53113 Bonn
Wie Sie wissen, können über das Internet versandte E-Mails leicht unter fremden Namen erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um Verständnis dafür, dass wir zu Ihrem und unserem Schutz die rechtliche Verbindlichkeit der vorstehenden Erklärungen und Äußerungen ausschließen, soweit wir mit Ihnen keine anders lautenden Vereinbarungen getroffen haben. Die für die Schoenland Online GmbH geltenden Regelungen über die Verbindlichkeit von Willenserklärungen bleiben unberührt.
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.