Re: [reSIProcate] KeepAliveManager usage
- From: Sandro Bordacchini <sandro@xxxxxx>
- Date: Tue, 09 Aug 2005 16:34:49 +0200
Scott Godin wrote:
To enable keep alive messages you only need to call:
auto_prt<KeepAliveManager> keepAlive(new KeepAliveManager);
dum->setKeepAliveManager(keepAlive);
and
dum->getMasterProfile()->setKeepAliveTime(30); // 30 seconds
There is no notification to the application if sending the keep alive
results in a TCP disconnection or a failed UDP send - although the next
SIP message sent, will likely cause a 4xx response to be returned from
the stack (if the connection is still lost).
Scott
Hi Scott.
I've tried to do that but i see only small UDP packets going from my
application to outbound proxy sip (so not reaching the other UA) and no
response to that UDP packets (afaik this is normal because UDP packets
are not ACK-ed). Maybe this type of keepalive works only with TCP
connection and without a outbound proxy (i'm not interested to check the
proxy but only the other user...)?
On resiprocate log i see (10.0.6.171 is my application, 10.0.6.114 is my
proxy):
....
INFO | 20050809-154719.383 | sandro | MyAppl | RESIP:DUM | 6972 |
1099754416 | DialogUsageManager.cxx:840 | Got: [ V4 10.0.6.114:5060 UDP
received on: Transport: [ V4 10.0.6.171:5062 UDP connectionId=0 ] on
10.0.6.171 connectionId=0 ]
INFO | 20050809-154719.383 | sandro | MyAppl | RESIP:DUM | 6972 |
1099754416 | DialogUsageManager.cxx:965 | Keep Alive Message
DEBUG | 20050809-154719.384 | sandro | MyAppl | RESIP:TRANSACTION | 6972
| 1099754416 | TimerQueue.cxx:105 | Adding application timer: [ V4
10.0.6.114:5060 UDP received on: Transport: [ V4 10.0.6.171:5062 UDP
connectionId=0 ] on 10.0.6.171 connectionId=0 ]
INFO | 20050809-154719.384 | sandro | MyAppl | RESIP:DUM | 6972 |
1099754416 | KeepAliveManager.cxx:61 | Refreshing keep alive of 30
seconds for: [ V4 10.0.6.114:5060 UDP received on: Transport: [ V4
10.0.6.171:5062 UDP connectionId=0 ] on 10.0.6.171 connectionId=0 ]
INFO | 20050809-154719.445 | sandro | MyAppl | RESIP:TRANSACTION | 6972
| 1099754416 | TransactionState.cxx:93 | Sending keep alive to: [ V4
10.0.6.114:5060 UDP received on: Transport: [ V4 10.0.6.171:5062 UDP
connectionId=0 ] on 10.0.6.171 connectionId=0 ]
DEBUG | 20050809-154719.445 | sandro | MyAppl | RESIP:TRANSPORT | 6972 |
1099754416 | TransportSelector.cxx:479 | Looked up source for
destination: [ V4 10.0.6.114:5060 UDP received on: Transport: [ V4
10.0.6.171:5062 UDP connectionId=0 ] on 10.0.6.171 connectionId=0 ] -> [
V4 10.0.6.171:0 UDP received on: Transport: [ V4 10.0.6.171:5062 UDP
connectionId=0 ] on 10.0.6.171 connectionId=0 ] sent-by= sent-port=0
DEBUG | 20050809-154719.445 | sandro | MyAppl | RESIP:TRANSPORT | 6972 |
1099754416 | TransportSelector.cxx:619 | Transmitting to [ V4
10.0.6.114:5060 UDP received on: Transport: [ V4 10.0.6.171:5062 UDP
connectionId=0 ] on 10.0.6.171 connectionId=0 ] via [ V4 10.0.6.171:0
UDP received on: Transport: [ V4 10.0.6.171:5062 UDP connectionId=0 ] on
10.0.6.171 connectionId=0 ]
...
Of course, if I disconnect physically my peer nothing happens, because
my application "pings" the proxy and not the peer.
I suppose that a (peer's) keepalive had to be done with a SIP request,
so it can be delivered to the right "host".
Do you think that periodic transmission of OPTIONS requests is a
suitable way to implement a keepalive?
From rfc3261:
The target of the OPTIONS request is identified by the Request-URI,
which could identify another UA or a SIP server. If the OPTIONS is
addressed to a proxy server, the Request-URI is set without a user
part, similar to the way a Request-URI is set for a REGISTER request.
[...]
As is the case for general UA behavior, the transaction layer can
return a timeout error if the OPTIONS yields no response. This may
indicate that the target is unreachable and hence unavailable.
Thanks a lot for your help.
Best regards,
--
Ing. Sandro Bordacchini
SIS s.r.l.
Via Cottolengo, 21
56100 Pisa (Italy)