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
