I think Hadriel is right. As much as I agree that from a technical perspective, having 302s not recursed on by proxies is better, I can't see this generally becoming the norm in this SIP universe. It's too late for that.
Maybe in SIP Four Dot Oh. > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: Friday, April 18, 2008 07:32 > To: Dean Willis; Anders Kristensen > Cc: Audet, Francois (SC100:3055); SIP IETF; Paul Kyzivat; Dan WING > Subject: RE: [Sip] E.164 - who owns it > > > > -----Original Message----- > > From: Dean Willis [mailto:[EMAIL PROTECTED] > > > > 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. > > I think that's a great utopian view, but in the real world > that would be impractical. A great many SIP UA's are > ultimately just TDM gateways, providing POTS-type interfaces > into the home, or PBX phone lines into the office, etc. > Afaik there is no way for them to indicate this redirection > to the human, or have a way to be told yes/no by the human. > Some people handle this type of thing with an app-server > b2bua where it plays out a message and takes in DTMF to make > the decision, but I think that's uncommon. > > I think/hope in the common case, if a call goes from one > provider to another, the second provider will not recurse it > outside of its domain and will pass it back upstream to the > calling provider to decide. I think that because often the > billing model between them seems to dictate that. I have no > doubt some cases will occur to validate your concern, but I > think market forces will "correct" them naturally over time. > Providers have plenty of natural motivation not to piss off > their customers and regulators. > > -hadriel > _______________________________________________ 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
