Hi Christer, 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.
thanks, -rohan 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
