RE: [reSIProcate] KeepAliveManager usage
Keepalives are meant to be used to let proxies and firewalls know that a
connection is still active - so it will not timeout the connection as
inactive in periods when no SIP messaging is sent. It is not meant as a
mechanism to provide lost connection/session detection. For this reason
- a proxy will not normally pass CR/LF packets on to the destination.
You might be interested in looking at Session Timers (which are also
implemented in DUM). RFC 4028.
To enable session timers you must do the following:
dum->getMasterProfile()->addSupportedOptionTag(Token(Symbols::Timer));
dum->getMasterProfile()->setDefaultSessionTime(180); // 3 minutes
dum->getMasterProfile()->setDefaultSessionTimerMode(Profile::PreferUACRe
freshes);
Also - Check out comments in Profile.hxx.
Scott
-----Original Message-----
From: Sandro Bordacchini [mailto:sandro@xxxxxx]
Sent: Tuesday, August 09, 2005 10:35 AM
To: Scott Godin
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: 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)