Hi, An alternative solution, based on "ob", and which does not require "keep", would be to add something like the following:
"When the UA receives a 200 OK response to a REGISTER message, it can deduce that outbound keepalives and flows can be used if there either is an "outbound" options-tag in a Supported or Requires header, or in lack of this, if the URI in the path header contains the "ob" URI parameter." Now, if there is no Supported/Require with "outbound" the UA knows that the registrar does not support outbound, but since the Path header contains "ob" the UA knows that the outbound proxy supports it, and that it supports keep-alives. This would of course require an outbuond proxy who only wants to do keep-alive to implement "full" outbound, but it would at least be possible to use keep-alives between the UA and the outbound proxy even if the registrar does not support outbound. Does that sound feasible? Regards, Christer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Christer Holmberg > Sent: 7. maaliskuuta 2008 9:47 > To: Francois Audet; Rohan Mahy > Cc: [email protected]; Cullen Jennings; Xavier Marjou > Subject: Re: [Sip] Outbound-12: STUN keep-alives without outbound > > > Francois, > > I am not following you... > > Why do we then need the "ob" parameter? Why should the > outbound proxy "on the wire" be able to say "I want to do outbound"? > > Why not simply use configuration? > > And, the parameter would NOT say "I want to do outbound, but > just the keep-alive". It would say "I want to do keep-alive", > which we along time ago agreed is a stand-alone function, and > not part of outbound itself. I don't remember any change of > that decission. > > Also, I don't agree this is a "corner case". STUN keep-alive > is pretty much the only signalling keep-alive mechanism we > have specified for SIP, and there are people who want to use > it for that. > > Regards, > > Christer > > > > -----Original Message----- > > From: Francois Audet [mailto:[EMAIL PROTECTED] > > Sent: 7. maaliskuuta 2008 0:45 > > To: Christer Holmberg; Rohan Mahy > > Cc: Xavier Marjou; [email protected]; Cullen Jennings > > Subject: RE: [Sip] Outbound-12: STUN keep-alives without outbound > > > > Yes, we had agreed to remove keep altogether. > > > > Using parameters for the job of something that logically belongs to > > configuration is futile and harmful as it would result in > > infinite-length URIs or other field. > > > > I can also garantee that everybody that presents a concept will > > somehow believe that this particular concept is worthy of being a > > parameter while the other guy's concept is inferior and doesn't > > warrant it. > > > > I think the point of the text was that it shouldn't be an AMBIGUOUS > > parameter, but instead a EXPLICIT parameter. > > > > So, this paragraph is completely accurate: > > 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. > > > > But it would be clearer if we added the following sentence > at the end: > > Rather than an ambiguous configuration option, it MUST > be an explicit > > configuration such as "Server supports RFC XXX CRLF > keep-alives? > > without RFC XXX registration procedures?". > > > > I really do believe that a parameter "on the wire" for such > a corner > > case (i.e., "I want to do outbound, but just the > > keep-alive") is absolutely not warranted. > > > > > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, March 06, 2008 10:38 > > > To: Rohan Mahy > > > Cc: Xavier Marjou; Audet, Francois (SC100:3055); [email protected]; > > > Cullen Jennings > > > Subject: RE: [Sip] Outbound-12: STUN keep-alives without outbound > > > > > > > > > Hi, > > > > > > >>>>>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. > > > > > > Exactly - so therfor I don't think the explicit configuration you > > > propose is appropriate :) > > > > > > >>>>>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. > > > > > > Maybe the problem is that we only discussed the usage of the > > > parameter in the R-URI, and when we agreed not to use it there we > > > forgot that it could actually be used in the Path header. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> 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 > _______________________________________________ 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
