Jiri, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jiri Kuthan > Sent: 14 November 2008 14:06 > To: Adam Roach > Cc: SIP IETF; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [Sip] draft-kuthan-sip-derive > > Hi Adam, > > thank you very much -- that's been most helpful indeed and I agree > with pretty much all the points. I would highlight the scope and > the actual verification mechanisms. > > I think that the scope, better-than-nothing, which just works with > the same infrastructure, as for INVITE delivery, and makes on > particular trust assumptions, begins to be agreeable. > > I agree too the actual verification mechanism, is difficult to agree > upon. For now,I would resort to listing how such can differ from each > other: > - it it E2E (i.e., without any support in the network) > -- that's obviously the objective > - does it work with existing UA implementations, at least with > some? That's desirable, not sure if really feasible. > - if it leans on some existing SIP extensions, are these specified > in a way that the scenario can unambiguously lean upon? > (unfortunately > not the case with dialog package) > - does it work for requests that don't establish dialogs (preferably > yes) > - can it deal with forking? > > So far I have heard further suggestions for using some combination of > OPTIONS, dialog authorization, or even a new method -- but we haven't > really yet tested those hard. > > Also the applicability is a key aspect -- reverse routability > agreeably being the most important one (apart from latency, security > assumptions such as uncompromised DNS). I think the general > approach is to explain that positive assertions are useful, negative > don't give much, and document examples of when it fails, possibly > accompanied by remedy suggestions: > - unregistered UAC, UAC with call forwarding, anonymous UAC: > don't do it :) > (possibly offer to retry) > - B2BUA: if you break it you fix it [JRE] This is a pointless exercise if it can't be deployed without fixing SIP intermediaries that are out there at present, and many of these are B2BUAs. This is similar reasoning to that which says that it has to work with the majority of UAs out there at present. There has to be a good chance of the mechanism working in the majority of inter-domain situations, and sadly that will nearly always involve B2BUAs of some form, and sadly this means a lot of things in SIP messages get changed. We can't do much about B2BUAs that are deliberately trying to stop things working, but we should at least try to take account of B2BUAs that are going about their legitimate business. Otherwise this will be yet another SIP RFC that never or rarely gets deployed.
John _______________________________________________ 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
