We voted on the "issue". This is a done deal.
> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 06, 2008 23:47 > To: Audet, Francois (SC100:3055); Rohan Mahy > Cc: Xavier Marjou; [email protected]; Cullen Jennings > 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
