All this argument seems to be predicated on an assumption for a charging model that is not defined anywhere by IETF. Many models exist for charging in diversion, and calling customer pays all is only one of them.
302s recursed by intermediate proxies may be perfectly reasonably in certain charging environments. I would further add that in the UK at least, there is a some assumption that the customer knows what he is going to pay at the time he "dials" the number (within fairly wide bounds). That means that if the network equipment (rather than the user's equipment) sends the request off into 0900 land without further input from the user or his equipment, then that customer will have a fairly good case for complaint and refund. This somewhat forces the network operator to make sure that any such cost implications of diversion are reasonable. Regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: Friday, April 18, 2008 7:46 PM > To: Paul Kyzivat > Cc: SIP IETF; Francois Audet; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > > 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 > _______________________________________________ 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
