Hi everyone, On the subject of E.164 discussion is there a universal preffix or list of registered preffixes to signify VoIP call. For example, the same E.164 Mobile or PSTN services numbers can be used for dialling Video or Voice Call over IP. Scenario: Alice has her Mobile service number but would like to receive a call instead of Mobile on her PC SIP Soft Client. Are there a preffix XYZ that would indicates to network that this call shall be routed via Gateway to IP Client instead of Mobile ?
Thanks and kind regards / Ellen Robins ViG Technology Manager Services Enablers Wireless Engineering & Operations Telstra Operations Telstra Corporation Limited Ph 03 8627 8981 Mob 0428 309 250 Fax 03 9620 7864 Mail [EMAIL PROTECTED] The information contained in this email message may be confidential. If you are not the intended recipient, any use of, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify me by reply email and then delete the message. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Thursday, 17 April 2008 9:04 AM To: Francois Audet Cc: SIP IETF; Dan WING; Dean Willis Subject: Re: [Sip] E.164 - who owns it replying to myself - another thought: Paul Kyzivat wrote: > > Francois Audet wrote: >> That's kind of what I was also saying. >> >> PS: what's the difference between 2 and 4? > > I think 4 is a typo and was presumably intended to be > > 4) sip:+445588675309:a.com;user=phone > > It is already the case that a.com may treat 3,4 & 5 alike if it wishes. > And b.com may treate 1,2 & 5 alike if it wishes. > > The question is whether a.com may treat 1&2 like 5, or if b.com may > treat 3&4 like 5. > > Apparently some are saying that user=phone is license to ignore the > domain. But that just raises the question of why one would insert a > domain along with a parameter that says to ignore it. Makes no sense to me. This would make *some* sense to me if the semantics were: 1) you MAY route to this domain following 3263 procedures with expectation that it will work. 2) if you are unable to do that (say because you don't have a sip path at all, or don't have a path to the domain in the URI) then you may treat it as a tel URI and route it any way that works for you. But it seems that in many of the use cases that have been presented in this thread it is actually the case that if the recipient routes to the domain in the URI the request *won't* work. That makes absolutely no sense to me. In that case TEL seems clearly the right way. Now Hadriel has made a case that it is the SBC's job to fix this up. So when the URL exits the domain in which it will work, then the SBC should fix it up with the domain it is going into. I guess that could make sense if that SBC was acting as an agent of *both* domains. But typically it is only acting as an agent of one domain. An SBC acting for b.com has no business changing the domain of the URL to a.com, since doing so is (or isn't) a policy of a.com. A way around that is to say that if the URI contains b.com, then an SBC acting for b.com, when it knows it won't honor that, can change it to a TEL URI when it exits the domain. It then may well go through another SBC acting for a.com as it enters the a.com domain. That SBC could change the TEL URI to an a.com URI if that will be handled correctly within the a.com domain. Paul > Paul > >>> -----Original Message----- >>> From: Anders Kristensen [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, April 16, 2008 15:21 >>> To: Dean Willis >>> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); Paul >>> Kyzivat; Dan WING >>> Subject: Re: [Sip] E.164 - who owns it >>> >>> >>> >>> Dean Willis wrote: >>>> What does Bob put into the Contact of a 302 he might send to Alice? >>>> >>>> I've heard several alternatives: >>>> >>>> 1) sip:+445588675309:b.com >>>> >>>> 2) sip:+445588675309:b.com; user=phone >>>> >>>> 3) sip:+445588675309:a.com >>>> >>>> 4) sip:+445588675309:b.com;user=phone >>>> >>>> 5) tel:+445588675309 >>> The presence of user=phone and a valid E.164 number in the user part >>> seems like a pretty strong hint so I wonder if the following might >>> work as a pragmatic, if not exactly elegant, way forward: allow >>> proxies and the UAC to treat cases 2 and 4 as if the URI is >>> equivalent to 5 in the sense that they can do ENUM query on the >>> E.164 number and they can even rewrite the domain part and expect >>> the URI to identify the same entity. >>> >>> This doesn't prevent a.com from recursing when really Alice's UA >>> would have liked to use another provider for gateway services but >>> then neither does using a tel: URI. >>> >>> We'd also want to start pushing support for tel:, of course. >>> >>> Thanks, >>> Anders >>> >>>> So let's step through what these mean and why they each might not >>>> work. Keep in mind also that there's a very real possibility that >>>> Alice might nod NEED a gateway to reach Jenny; it's possible that >>>> Jenny's phone number is already in ENUM and is directly >>> reachable via >>>> SIP. But this only works if Alice knows to look it up that way. >>>> >>>> 1) causes Alice to make a call to a user ID in the domain >>> of b.com. >>>> Assuming that b figures out that this means a telephone >>> destination, >>>> Alice probably doesn't have an account at b.com to use for >>> placing the >>>> call. So unless B provides free SIP-to-PSTN calling, or at least >>>> provides free translation service to ENUM, she's out of luck. >>>> >>>> Of course, maybe a.com knows that when it gets a 302 back with a >>>> contact that looks like it might be a phone number, it >>> should discard >>>> the host part and do phone number routing on the user part. >>> That works >>>> until a.com also has user IDs that look like phone numbers. >>> Of course, >>>> this is a direct violation of RFC 3261, which bans a.com from >>>> retargeting a request with a b.com host part. >>>> >>>> 2) is much the same as 1, except that "user=phone" provides another >>>> hint. B is no more likely to provide gateway services, but at least >>>> least if A is going to do an illegal foreign retargeting, it has a >>>> broader hint that phone number routing instead of user routing is >>>> required. >>>> >>>> 3) instructs alice to make a call in the domain of a.com. >>> That's fine >>>> as long as sip:+445588675309:a.com routes to Jenny. Does >>> it? It might >>>> route to somebody with user ID +445588675309, which is a perfectly >>>> valid user ID. >>>> >>>> It might also be true that Alice doesn't use a.com for her >>> PSTN calls. >>>> Perhaps instead, she uses c.com. So to use c.com services, or do an >>>> enum lookup, she has to do an illegal retargeting. >>>> >>>> 4) is much like 3, with the added hint that a telephone-number >>>> destination is indicated. This might eliminate the >>> accidental calling >>>> of user +445588675309, but it does nothing to resolve the >>> question of >>>> Alice not using a.com services for PSTN gateways. There's >>> also an open >>>> issue as to whether PSTN routing (such as an ENUM lookup) can be >>>> applied, vs requiring the call to traverse a gateway. >>>> >>>> At the very best, a.com (or Alice's UA) knows to discard >>> the host part >>>> and do telephone routing on the user part. If Alice's UA does this, >>>> it's probably a violation of RFC 3261, as the UA itself is not >>>> responsible for the host-part of the contact. A proxy in >>> a.com could >>>> do this translation. But what happens if Alice doesn't use >>> a.com for >>>> routing PSTN calls? For example, I might place SIP calls using >>>> "softarmor.com", but I make my PSTN calls using "sipphone.com", so >>>> a >>>> 302 sent to me for "sip: >>> [EMAIL PROTECTED];user=phone" will >>>> most assuredly fail. Now, if the a.com proxy knew to translate the >>>> call, that would be OK, but depending on the relationship between >>>> Alice and a.com, it might not. >>>> >>>> 5) doesn't work at all, because Alice's phone doesn't >>> understand tel: >>>> URLs, since understanding of such was listed as a MAY in >>> RFC 3261. But >>>> it's the only suggestion from the set that doesn't require >>> violating a >>>> bunch of existing protocol rules. >>>> >>>> >>>> >>>> >>>>> Really, in the long list of interop issues, this one's >>> pretty low on >>>>> the totem pole, imho. People are having trouble getting >>> basic calls >>>>> to work without the aid of a middle-box. That's a bit >>> higher on the >>>>> list to me. :) >>>> This is a very basic interdomain calling scenario. I'm >>> really hoping >>>> we get more and more interdomain calls. >>>> >>>> >>>>>>> Again, don't shoot the messenger: it makes sense to me >>> to use Tel >>>>>>> URI for this. I am just saying it may cause interop >>> problems. Maybe >>>>>>> that's ok, and maybe implementations will start implementing tel >>>>>>> URI. >>>>>> I've no doubt that there will be interop problems. That's what >>>>>> happens when you specify something that has previously been >>>>>> unspecified and left to whim or caprice. >>>>> OK, but failing calls will not give it a high chance of being >>>>> adopted. Maybe we can figure out how to get a sip: uri to work as >>>>> well - there's more than one way to skin a cat, even with a potato >>>>> peeler. ;) >>>> Failing calls that don't work now isn't much of a handicap. >>> Changing >>>> the rules of RFC 3261 to make case 3 or 4 generally valid >>> might also >>>> work. >>>> >>>> Fundamentally, we need a documented solution that works in >>> the general >>>> case and doesn't conflict with MUST level rules of other >>> RFCs we cite, >>>> unless it supercedes those RFCs. >>>> >>>> >>>> -- >>>> 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 >>>> > _______________________________________________ > 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
