< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] KeepAliveManager usage


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)