Feature #67
Federated Calling
| Status: | Closed | Start date: | 04/11/2012 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | lee | % Done: | 0% | |
| Category: | - | Spent time: | - | |
| Target version: | OSTel Operations | |||
| Component: |
Description
Federated Calling between instances
History
#1 Updated by n8fr8 almost 6 years ago
- Assignee set to lee
- Priority changed from Normal to High
- Target version changed from Alpha Testbed Launch v1 to Alpha Testbed - Update 1
Federated calling is important. If we can make a ZRTP call between OStel and Tanstagi that would satisfy this requirement.
#2 Updated by lee almost 6 years ago
- Target version changed from Alpha Testbed - Update 1 to OSTel Operations
moving to public launch milestone.
#3 Updated by lee almost 6 years ago
I figured out a bottleneck in the authentication process for federated calling versus running FS as an anonymous proxy.
To give an example, XMPP federation works because users must "accept" a buddy request before they are allowed to send data. Since phone calls don't easily map to this pattern, there is no "accept" button for federated calling. XMPP also has a well defined TCP port for "server to server" communication. SIP has this capability as well but the servers must authenticate with each other to pass data.
A possible solution to this is to have a static table of domains that are allowed in the federation. If an incoming call arrives at foo.com from bar.com. bar.com is configured on foo.com as a member of the federation, the call is routed to the user at foo.com.
Another solution is to make a peering agreement between foo.com and bar.com to allow each endpoint to register with each other, opening a SIP channel between the two. This process is how most commercial "SIP Termination" providers let their users calls outside of their system.
#4 Updated by n8fr8 almost 6 years ago
lee wrote:
A possible solution to this is to have a static table of domains that are allowed in the federation. If an incoming call arrives at foo.com from bar.com. bar.com is configured on foo.com as a member of the federation, the call is routed to the user at foo.com.
I think this would be a good start, with partner servers like Tanstagi, Intimica, as well as IPTel and Callcentric if possible.
Another solution is to make a peering agreement between foo.com and bar.com to allow each endpoint to register with each other, opening a SIP channel between the two. This process is how most commercial "SIP Termination" providers let their users calls outside of their system.
Ah... so can you explain the difference between the first option and the second a bit more?
Can or should we do both?
#5 Updated by ex1st almost 6 years ago
Some considerations when planning a federation: who is managing which group is allowed in, what are the legal standards for disclosure of who is in the federation.
On a user experience side, we may run into a problem of routing calls. If I am 1003 on OStel and Nathan is 1003 on, let's say, WitnessPhone, then the android address book will not differentiate. This can become a security flaw with people impersonating others or accidental prank calling. While csipsimple dialing allows for dialing an email address (1003@ostel.me), the address book in android version 2.3.6 does not allow the number to be saved that way.
#6 Updated by n8fr8 almost 6 years ago
- Status changed from New to In Progress
ex1st wrote:
Some considerations when planning a federation: who is managing which group is allowed in, what are the legal standards for disclosure of who is in the federation.
Well you also have federation in the context of email, where anyone with a valid domain can email anyone else with a valid domain.
Obviously spam is an outgrowth of a very permissive federation model in this case, but otherwise, I would prefer to default to a very open model of federation that doesn't require any lawyers.
allows for dialing an email address (1003@ostel.me), the address book in android version 2.3.6 does not allow the number to be saved that way.
Hmm... which number field are you using? On my 2.3 device, there is an "Internet Calling" field in the contact form, and there I can enter a valid sip address which is user@domain.com or extension@domain.com
#7 Updated by ex1st almost 6 years ago
I may be getting a little ahead, worrying about how voice communication is litigated compared to the internet...
csipsimple uses the phone field in contacts not the internet call field. i can flag that to be added in the future. though I guess that depends on how federation works with regular mobile telephony and SMS, such as 3474398431@messaging.sprintpcs.com
#8 Updated by n8fr8 almost 6 years ago
ex1st wrote:
I may be getting a little ahead, worrying about how voice communication is litigated compared to the internet...
definitely beyond the bounds of technical network federation that we are discussing here. feel free to start another thread on legal issues.
csipsimple uses the phone field in contacts not the internet call field. i can flag that to be added in the future.
Csip has a "txt" dialing capability, so you can call people using user@foo.com style addresses. I would assume in that context it would store the address in the proper place. Regardless, the way that Csip stores numbers in the Contact app is beyond the scope of this ticket.
#9 Updated by lee almost 6 years ago
#10 Updated by lee almost 6 years ago
I would like to split this ticket into pieces, since it reads like an email thread now. I don't see it every getting closed.
#11 Updated by n8fr8 over 5 years ago
- Status changed from In Progress to Closed
I am closing this ticket out, but can we please insure that all the various issues are covered elsewhere?