Re: [reSIProcate] KeepAliveManager usage
For this to work correctly over both UDP and TCP the user agent needs
to send STUN messages as keep-alives. This requires the edge proxy to
demultiplex the STUN requests and provide a STUN response back.
The point of the keepalive is to keep the pinhole open through the NAT device.
Jason
On 8/9/05, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
> 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)
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>