[reSIProcate] KeepAliveManager usage

Sandro Bordacchini sandro at sis.it
Tue Aug 9 09:34:49 CDT 2005


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)




More information about the resiprocate-devel mailing list