On Apr 17, 2008, at 7:27 PM, Anders Kristensen wrote: > > > Dean Willis wrote: >> It;s been proposed that we use #5: if tel: is known to be >> supported, and #4 if it isn't. That's actually quite doable by >> adding a SIP extension tag for "tel" to the Supported field of the >> request. >> How about: A node generating a redirect-to-PSTN in the caller's >> domain MUST use a tel: URI if the request contains a "tel" option >> tag, and SHOULD use a "[EMAIL PROTECTED];user=phone" construction >> if the request does not contain such a tag. > > Proxies can't muck with Supported headers so I'm not sure how this > helps if it's a proxy in the caller's domain (as opposed to the UAC > itself) that understands and acts on tel: URIs.
So assume the UAC does not support "tel" and the UAS's domain is not going to pay to send the call to the PSTN -- the redirecting node ends up doing what it would do now, which is assume that tel isn't supported, and make its best SIP guess at a SIP rewrite in the UAC's domain. 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. So the limitation you've noted doesn't bother me at all. -- 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
