On Mar 6, 2008, at 9:46 AM, Christer Holmberg wrote: > Hi Rohan, > >>>> I have big issues with the keep-alive change in the -12 version. >>>> >>>> Because, now the STUN keep-alives usage can't be applied between >>>> the >>>> UA and outbound proxy, unless the registrar supports outbound. >> >> What gave you that impression Christer? By my read that is >> still allowed if the UA has explicit configuration that its >> next-hop support keepalives: > > Of course, but previously we had a mechanism for the outbound proxy to > actually indicate support. > > Also, chapter 8 of the draft does say: > > "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."
That text has been there for ages. That is not new. >>> 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. >> >> >>>> I strongly think it should be possible to use STUN keep-alives for >>>> "pure" signalling NAT traversal, even if the "rest" of outbound is >>>> not used. >>>> >>>> So, while I DO agree with the Vancouver(?) decission to not include >>>> any "URI" keep parameter in the R-URI of the register request, I >>>> think we shall we keep the URI "keep" parameter definition, and >>>> e.g. I'm pretty sure we had rough consensus to remove the parameter completely. I'll go dig up my notes and the minutes. Maybe Francois can jump in here. thanks, -rohan >>>> allow it to be inserted into the Path header (I don't remember any >>>> discussions regarding removing that possibility) by the outbound >>>> proxy, in order to inform the UA that the outbound proxy supports >>>> STUN keep-alive. >>>> >>>> (OR, there should be another mechanism for the outbound proxy to >>>> inform the UA it supports STUN keep-alive) >> >> Currently, that other mechanism is out-of-band configuration. >> We could also add another way to indicate this in the >> future, but for know the WG seems happy with what we have. > > I don't understand "add in future". We already had a mechanism. > > This is what you, me and Cullen were discussing a long time ago, > and we > all agreed to :) > > One thing we in Vancouver DID agree to was that a mechanism to also > indicate the keep-alive refresh timer value WOULD be a future > extension. > > > Regards, > > Christer > > > > >>>> That would allow people to start using outbound for NAT >> traversal, >>>> even if the registrars haven't yet been updated to >> support outbound >>>> etc. >>>> >>>> At one point we decided that we will keep the STUN >> keep-alive usage >>>> and outbound in the same spec, but that we will describe the STUN >>>> keep-alive usage as a "stand alone" function (chapter 8 of the >>>> draft). But, now you have more or less "merged" the STUN >> keep-alive >>>> usage with the outbound function, and that is bad. >>>> >>>> Also, this change is not mentioned in the >>>> changes-since-the-previous-version part (if it is mentioned, I >>>> appologize for having missed it) >>>> >>>> Regards, >>>> >>>> Christer >>>> _______________________________________________ >>>> 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
