Hi Jiri, There are two issues here. negotiation of the outbound registration mechanism, and keepalive usage.
OUTBOUND NEGOTIATION - This normative text on this is currently split across each role, so here is a summary: A UAC registers and indicates support for the outbound extension by advertising the outbound option-tag in its Supported header, and it requests an outbound-style registration by including a reg-id and instance-id. The first-hop sees the reg-id and instance-id in a registration request and adds a Path header with a flow token and an 'ob' URI parameter. It might go through other proxies, but we don't care. The registrar (which is a UA) gets the request, checks that there is a reg-id and instance-id in the Contact, an 'ob' parameter in the first Path header field value, and 'outbound' in the Supported header. It uses outbound-style bindings instead of RFC3261-style bindings for this UA instance. It returns a registration response with 'outbound' in its Require header. Any intervening proxies forward the response on its merry way back to the UAC. The first-hop proxy MAY add a Flow-Timer header if, and only if, the response has Require: outbound in it. The UAC receives the successful registration response. It can tell that outbound registration was successful since there is an outbound option-tag in the Require header. <note>No bullets for the fish here, Dean.</note> KEEPALIVE USAGE When using keepalives for outbound, you start sending keepalives after a successful outbound registration. This is safe since the first hop proxy already demonstrated outbound support by inserted on 'ob' parameter, and proxies which do this are required to support both keepalive methods from Section 4.2.1 > If outbound registration succeeded, as indicated by the presence > of the outbound option-tag in the Require header field of a > successful registration response, the UA begins sending keepalives > as described in Section 4.4 (Keep-alives and Detecting Flow Failure). Also, in case you think the text isn't strong enough we have these do no harm admonitions in the standalone STUN keepalive section. from Section 8 > Because sending and receiving binary STUN data on the same ports > used for SIP is a significant and non-backwards compatible change > to RFC 3261, this section requires a number of checks before > sending STUN messages to a SIP node. If a SIP node sends STUN > requests (for example due to incorrect configuration) despite these > warnings, the node could be blacklisted for UDP traffic. > > A SIP node MUST NOT send STUN requests over a flow unless it has an > explicit indication that the target next hop SIP server claims to > support this specification. Note that UACs MUST NOT use an > ambiguous configuration option such as "Work through NATs?" or "Do > Keep alives?" to imply next hop STUN support. > > Typically, a SIP node first sends a SIP request and waits to > receive a 200-class response over a flow to a new target > destination, before sending any STUN messages. When scheduled for > the next NAT refresh, the SIP node sends a STUN request to the target. As for "native-transport" keepalives, this was explanatory text and was cluttering the flow so we trimmed it down, but it is still there: Section 3.5 > UAs are also free to use native transport keep alives, however the > UA application may not be able to set these timers on a per- > connection basis, and the server certainly cannot make any > assumption about what values are used. Use of native transport keep > alives is therefore outside the scope of this document. So, if either the first-hop or the registrar didn't support outbound, the UAC won't send keepalives unless it has some out-of-band configuration that its next hop supports them. Hope this helps. thanks, -rohan On Mar 5, 2008, at 5:00 PM, Francois Audet wrote: > Jiri, > > On p.15 it is explained that the UAC looks at the presence of > the Require: outbound field falue in a response to registration. > > This is to ensure that both the registrar and the edge proxy are > compliant with this spec. The keep-alive would only be sent if > present. > > Please suggest improved wording if you feel it is not clear enough. > > On the TCP keep-alive issue: this has been investigated in previous > versions > of the draft. It was dropped because of the fact that changing the > TCP keep-alive > is often a system-wide setting on most Operating Systems. > > Rohan, we use to have some words about this in the spec, but I > think it's all > gone from this version. Maybe the note should have been left here... > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Jiri Kuthan >> Sent: Monday, March 03, 2008 10:53 >> To: [email protected] >> Subject: [Sip] keep-alive backwards compatibility in >> draft-ietf-sip-outbound-12.txt >> >> I'm just wondering if folks have been worried about the UACs >> that implement the aforementioned I-D and talk to a proxy/UAS >> that doesn't do so? >> >> It appears to me that mandating a reconnect on lacking PONG >> would lead to quite heavy traffic. >> >> (which is why without deeper knowledge of the history of this >> I-D, I would be inclined to rely on TCP's keep-alive, which >> is in there) >> >> -jiri >> >> >> >> -- >> Jiri Kuthan http://iptel.org/~jiri/ >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> [EMAIL PROTECTED] for questions on current sip >> Use [EMAIL PROTECTED] for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
