On Apr 18, 2008, at 7:00 AM, Paul Kyzivat wrote: > > > Dean Willis wrote: > >> Proxies that recurse on 302 responses should be taken out and >> burned anyhow. It's just a tragically stupid thing to do in most >> cases. In the scenarios we're talking about, which probably >> involve a transition from a "no charge" IP call to a potentially >> very expensive (like, up to $25 a minute for some premium >> services) PSTN call, the user REALLY needs to be able to make a >> decision. > > This doesn't bother me. If this happens I'm just going to refuse to > pay the bill, with the argument that "I never called that number". > So this is a feature.
I look forward to seeing that argument played on Judge Judy's daytime TV show. > > IMO if a proxy was already forking, or prepared to fork, then > recursing on 3xx is not making things any worse. That depends on who it was forking to. If the forks are "retargeting", then recursing on a 302 is only marginally worse. If however the forks are "rerouting", than recursing on a 302 raises all sorts of unanticipated respondent problems that not recursing would have avoided. > > Also, you are assuming that the recursion is happening in the > calling domain. It may well be happening in the called domain, which > may want to hide the 3xx response from the calling domain. That's fair. >> So the limitation you've noted doesn't bother me at all. > > Why should we need Supported:tel before tel can be used? Its already > supposed to be supported. > Ok, spec dude: Can you show me a citation that says tel: MUST be supported by a SIP UA? Even a SHOULD? -- Dean _______________________________________________ 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
