Hi Rohan, >The edge proxy is only supposed to add the ob parameter to >the Path if the edge proxy included a flow token in the path >URI. This should only happen when the UA included a reg-id >and instance-id parameter in its Contact header.
Correct. But, the point is that the UA would then still be "allowed" to use STUN keep-alive between itself and the outbound proxy, even if the registrar doesn't support outbound. Regards, Christer > On Mar 7, 2008, at 12:52 AM, Christer Holmberg wrote: > > 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
