Subject: Re: [Sip] OUTBOUND: Direction of keep-alive requests

From: "David Schwartz" <[email-masked]>
Date: Fri, 3 Mar 2006 15:07:41 +0000 GMT

Hi christer

There is no need to define a new session timer mechanism. It would probably be easier to use a "suppression" mechanism similar to REFER implicit subscription suppression by using a header the likes of "Refer-Sub".  So that the UA keeps behavior as is defined curently and each keepalive ping from the server suppresses the ping from the UA. If the binding is lost the UA picks up where it left off.

Cheers

David
-----Original Message-----
From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 3 Mar 2006 15:14:49 
To:"IETF SIP List" <[email-masked]>
Subject: [Sip] OUTBOUND: Direction of keep-alive requests

Hi, 
 
When the different NAT keep-alive mechanisms has been discussed, it seems to be assumed that whatever message is sent, it is originated by the UA (or some other node behind the NAT, on the private side). At some point messages originated from the network has also been mentioned, but then the comment has been that many NATs require the the keep-alive messages to be sent from the UA (or some other node behind the NAT).
 
However, in a requst/response based protocols, there WILL be messages sent also in the UA-to-NAT direction; the response messages. So, while the requests from the network would not keep the NAT binding open, the responses would.
 
Of course, whatever proxy that would send these requests would have some kind of B2BUA behavior, and then we get into religious ground again...
 
The advantage, as I see it, would be that in the easiest form no new functionality would be needed in the SIP UAs. They would reply to SIP requests even if they don't understand them, and the binding would be kept open.
 
The disadvantage, of course, is that the UA would not detect when the NAT binding is gone. 
 
But, if we would define some extension similar to the session-timer, the UA would (assuming it supports the extension) EXPECT these requests. And, if the requests don't come, the UA could e.g. perform a re-registration.
 
This extension could even be combined with some sending of double CRLFs by the UA, so that the keep-alive requests don't have to be sent that often (still often enough, though).
 
This mechanism of course assmes that the responses are sent to the same IP port/address as where requests would be sent, in order to keep the binding open.
 
I am not saying that this solution would be better or worse than anything else, but at least it is the easiest way to force a client to send a message towards the NAT :)
 
Regards, 
 
Christer 
 _______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

Sent wirelessly from my BlackBerry

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Mar 2006 10:24:36 +0200

Hi Juha,

I guess it's up to the operator community to decide whether it needs to be solved. All I am saying is that it is possible, without any new terminal requirements, for the network to initiate messages to be sent from the UA towards the NAT.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Mar 2006 00:19:15 +0200

Hi,

My proposal was that the network would send a SIP request towards the UA, and the response sent back by the UA would act as the "ping".

Regards,

Christer