Paul, I don't understand a couple of your points below. Can you elaborate?
tim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Kyzivat > Sent: Thursday, April 10, 2008 12:14 PM > To: Francois Audet > Cc: [email protected]; Dan Wing > Subject: Re: [Sip] E.164 - who owns it > > Francois, > > I agree with your point entirely. > > BUT, even if I choose to advertise a sip URI (with user=phone), some of > the UASs I call may well display only the numeric portion as the > callerid. Those people in turn may then attempt to call me back using a > TEL URI, and as a result, may end up going over the PSTN, even if > originating from a sip device. (I don't know how often a PSTN > path will be chosen even if a sip path was possible, but probably more > often than we would wish.) Are you saying that use of tel:+4085551212 as opposed to sip:+4085551212;user=phone makes it more likely that the call will be routed the PSTN? If so, why would that be? > If the devices are half way smart, even if they only show the number > they will keep the entire URI in their call log, so that if I attempt a > callback via the call log it will use the whole URI. But I expect some > devices will be dumber than that. When you say "use the whole URI" do you mean in the R-URI? I'm not sure this would be desirable behavior. If the host part of the R-URI does not identify a domain for which the network serving the calling party is authoritative, then as I understand it the network serving the calling party should simply proxy the INVITE per 3263. But then how does the network serving the calling party provide originating services to its subscriber? As a practical matter I'll note that in some networks with which I am familiar, the value to be used in the host part of the R-URI is dictated by the network. > I don't know that we can do anything about it, except perhaps publish > some best practices drafts. But I expect it may be a problem > for a long > time. A "best practice" promoting the behavior described above, seems problematic. Maybe if there are networks somehow fundamentally unlike that described above (e.g., where there is no concept of originating services), it could be scoped to be applicable to them? I suppose this is a general problem with best practices - few are universally "best". > > Paul > > Francois Audet wrote: > > I'm still not sure I get it. > > > > If I present a Tel URI, and somebody uses it to reach me, > and it just happens > > that we are both using SIP as our default "Telephony" > client, then sure, you > > absolutely will be able to do whatever you want (IM, HD, etc.). > > > > The point is that if you choose to advertise a Tel URI > INSTEAD of a SIP URI, don't be > > surprised if you have people reaching you with PSTN-capabilies only. > > > > Conversely, if you choose to advertize a SIP URI ONLY, then > you may be missing out > > entirely on people calling from PSTN. > > > > - At least, that's the theory... > > > >> -----Original Message----- > >> From: Dan Wing [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, April 09, 2008 21:20 > >> To: Audet, Francois (SC100:3055) > >> Cc: [email protected]; 'Paul Kyzivat'; 'Juha Heinanen' > >> Subject: RE: [Sip] E.164 - who owns it > >> > >> > >> > >>> -----Original Message----- > >>> From: Francois Audet [mailto:[EMAIL PROTECTED] > >>> Sent: Wednesday, April 09, 2008 8:04 PM > >>> To: Dan Wing > >>> Cc: [email protected]; Paul Kyzivat; Juha Heinanen > >>> Subject: RE: [Sip] E.164 - who owns it > >>> > >>> Well, you can still do video over PSTN with H.320. I still > >> view this > >>> as "telephony". > >> Sorry -- please pick something you cannot do over the PSTN. > >> Instant Messaging, presence, high-quality video (HDTV), whatever. > >> > >>> Not sure I understand the question. > >> Let me reword my previous email into a question: > >> > >> If you have a non-SIP telephony application that trunks > >> towards the PSTN, and it is configured to process tel URIs, > >> and it is asked to initiate a call that exceeds the > >> capabilities of the PSTN (instant messaging, presence, > >> HDTV-quality video, whatever you prefer) -- would it route > >> the call towards a "SIP trunk" in order to gain the ability > >> to set up that call, abort the call, or just ignore it all > >> and trunk towards the PSTN? > >> > >> An additional question (statement, actually) is: We can't > >> influence how that non-SIP telephony application provides for > >> its own identity and authentication of tel URIs. > >> > >> (This is getting me to lean more towards my email-identity > >> straw-man. With it, we can step out of this festering, > >> smelly pile of trying to get E.164 working well with SIP and > >> move to email-style SIP URIs. The IETF is capable of > >> building an end-to-end identity/authentication solution > >> around email-style SIP URIs; we have one (RFC4474) that works > >> if we prohibit SBCs and B2BUAs from modifying SDP). > >> > >> -d > >> > >> > > _______________________________________________ > > 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 > _______________________________________________ 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
