On Apr 16, 2008, at 5:24 PM, Francois Audet wrote: > That's kind of what I was also saying. > > PS: what's the difference between 2 and 4? >
the difference is a typo on my part. Should be: 1) sip:[EMAIL PROTECTED] 2) sip:[EMAIL PROTECTED]; user=phone 3) sip:[EMAIL PROTECTED] 4) sip:[EMAIL PROTECTED];user=phone 5) tel:+445588675309 so the difference between 2 and 4 is the domain part of the Contact: header field's URI value in the 302. First case is that the constructed URI is in the terminating domain, which works only if the terminating domain is willing to provide PSTN service to Alice. This is just a business case problem -- which, IMHO, makes it intractable in some cases. Sure, most of the cases we see today have Alice and Bob in the same domain, so it works fine intradomain. Second case is that the constructed URI is in the originating domain, which works only if a) it guesses the URI construction correctly, and b) Alice has access to the PSTN through that domain. Both A and B can be mediated by Alice or the a.com proxy "understanding" what this sort of response means and then figuring it how to transform the URI to something they can route. If Alice doesn't use a.com for PSTN service and the a.com proxy recurses, it is certain to fail -- but that's between Alice and a.com. One might make the argument that a UA or recursing proxy should "know" that if it sees a 302 Contact URI with a domain part equal to that of the sender's and a "user=phone" modifier, that a redirection to PSTN has been requested. 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. -- Dean, who cannot type. _______________________________________________ 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
