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." >>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. >>>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
