Dwight, Timothy M (Tim) wrote: > 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?
IMO if I give you sip:[EMAIL PROTECTED], with or without user=phone, then a call back to that URI MUST be via sip, and the 3263 rules say that it MUST be routed to domain sp.com before making any decision about how to reach something associated with the user part. If I give you tel:+4085551212, then you have total freedom regarding what protocol to use to reach me, and the path taken. You may just use an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip service, or whatever. >> 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 was thinking of a device that keeps a log of *incoming* calls, so the From-URI would be appropriate. > 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. If you are originating a call from a dial string, not a URI, then I guess you can formulate the R-URI any way you want. But if the calling party is supplying a URI (e.g. one it has saved from a prior received call) then it should be used as-is. If you want some server on the originating end to do something for the outbound call, then you should put a Route header in the request identifying the server. As a practical matter, suppose you receive a call from sip:[EMAIL PROTECTED] If you want to return that call, you have little choice but to use that as the R-URI. You can't very well send it to sip:[EMAIL PROTECTED] and expect the right thing to happen. So, if you received a call from sip:[EMAIL PROTECTED];user=phone, then IMO the caller had an expectation that callbacks would be delivered there, not to sip:[EMAIL PROTECTED] But in fact that is exactly what a lot of systems are doing. >> 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". I think as a community we are far from agreeing on what "best practices" are. Hopefully it will eventually be sorted out. But it seems that there is a fair chance that we will never all agree on what best practices are in this regard, and will continue to be partitioned into a bunch of warring feudal communities, with tax collectors on every road. >> 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 > _______________________________________________ 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
