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
