> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Hannes Tschofenig > >> > > [JRE] Well, what about enterprise via service provider to enterprise? As > > an enterprise provider, I would like to be able to use SIP identity, but > > a precondition is that it gets through that intermediate service > > provider(s). > > > Why would like to pick a service provider in the first place?
Want the top 10 reasons? (in no particular order) 1) Because most of their calls still go to/from the PSTN. 2) Because most of their calls are still addressed to/from using E.164 - they have no idea it's going to end up at another SIP-enabled Enterprise. 3) Because voice means business/money for many Enterprises - if it doesn't work they want someone to go fix it, someone to yell at, someone to monitor it, etc. 4) Because the target destination Enterprise may not allow incoming calls from anyone but *their* SP. 5) Because their SP has defined qos guarantees for VoIP traffic, if it's SIP-routed through them. (in some ways one could argue SIP has accomplished what RSVP was meant to do but did not) 6) Because SIP has significant interop issues, and the Enterprise knows their stuff works with the SP. 7) Because the IT guys can justify it more easily to execs, and won't get fired if the SP screws up. (if there even *is* an IT dept.) 8) Because email has NOT been a shining example for how VoIP could work. 9) Because they have constrained-resource WAN links and want to use low-bandwidth codecs over that, but want to let the SP transcode it to whatever will work with the far end. 10) Because if it ain't broke, they don't want to fix it. (ie, if it works it works) > Why are > they deploying B2BUAs? Who, the SP or the Enterprise? The answer is usually "control" ultimately, in some form or other. > If you really want todo that then pick one that does not damage your > security. You are the customer and you decide. Damage your security how, and according to who's definition of security? You think end-end is somehow inherently secure. But neither end trusts the other. They trust the middles (specifically their respective next-middles) more than the other ends. That's the rub. > If you want to pick such as service provider then why does the chain of > trust not work for you? Hopefully you trust the provider you have chosen. I trust my provider, but not their peers as much, and less their peers' peers. If I am using myprovider.com and I get a call from them saying it's from [EMAIL PROTECTED] I would be confident that's true. I have much less confidence when I get a call from my provider saying the caller is [EMAIL PROTECTED] But this topic isn't really about me or us anyway, imho. Most SP customers blindly trust their SP's, imo - IETF'ers are an exception not the rule. It's about an SP wanting to live-up to the trust its customers put in it. They'd like to know that when they get calls from one of their peer SPs, they can trust calls that didn't originate at that peer. They essentially had that in the PSTN, because they could ferret out trouble-makers over time, there's a forced hierarchy of providers, and the cost of calls and linking into SS7 self-limited many issues. Whether that holds true for SIP remains to be seen. I'd like to be ready before we find otherwise. > .... just trying to figure out what the typical deployment cases are and > why we don't see any of this in XMPP. If people only used SIP for free IM, with email-type [EMAIL PROTECTED] FQDN URIs only, and had one dominant vendor implementation, I bet the deployment landscape would be quite similar to XMPP. It's not the protocol that causes it. (Well, that's not totally true, but close enough) -hadriel _______________________________________________ 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
