Obitalk as a SIP trunk.
Usetheforceobiwan:
I follow what you are saying and you are right I might have flawed logic (just ask my ex boss) but isn't the translation from Sip to Obitalk being done on the remote side? And with that in mind, why isn't the PNN reference on the IP phone to the Obi # of the PBX side Obi? That seems to make more sense.
QBZappy:
http://blog.obihai.com/2013/03/using-obi202-with-ip-phone-as-ip-pbx.html
On OBi #2, set up the following parameters:
- ...
- SP1/InboundCallRoute = {>(1001):pp}
- OBiTALK Service/InboundCallRoute = {1001>:sp1}
This concept is not translation. This technique is used to simply route the calls, no transcoding/translation is done (I think). OBi<->sip.
giqcass:
Quote from: Usetheforceobiwan on December 06, 2013, 10:20:58 pm
I follow what you are saying and you are right I might have flawed logic (just ask my ex boss) but isn't the translation from Sip to Obitalk being done on the remote side? And with that in mind, why isn't the PNN reference on the IP phone to the Obi # of the PBX side Obi? That seems to make more sense.
You are looking at this like it's the mailing address when it's clearly the return address.
Quote from: QBZappy on December 06, 2013, 09:45:13 pm
@Usetheforceobiwan
It remains to be seen if something like "ANYTHING@500111101.pnn.obihai.com:5061" can be used in any useful manner. This wont work because it is not exactly a SIP addressing schema. There is one dot too many.
I agree this is not a sip address but there is nothing stopping you from having multiple dots in a sip address. I have working sip addresses with considerably more then one dot in them.
I don't believe anything useful can be done(from the user side) with ANYTHING@500111101.pnn.obihai.com:port because the part of the address 500111101(or whatever your Obi number is) never appears to be assigned an ip address. pnn.obihai.com is hosted on Amazon with the bulk of Obis infrastructure. I think 500111101.pnn.obihai.com is being replaced by the ObiTalk service with the external IP address of OBI#1 using and internal database on the initial sip invite through the ObiTalk servers.
Usetheforceobiwan:
I still don't see why the remote IP phone needs to point to the pnn.obihai.com proxy. If anything, it appears to be redundant.
Here is my take on how a call is made in this scheme. On the remote side, the remote IP phone establishes a session with the remote Obi using a straight SIP connection that should stay within the remote location's LAN. Then the remote Obi takes that session and continues it by routing it through the Obitalk cloud to the PBX side Obi. On the PBX side, the PBX Obi routes the call via SIP to the PBX.
Doesn't pointing to the pnn.obihai.com address appear to confuse session connections that should be either exclusively internally LAN based or externally cloud based?
giqcass:
I'm no expert but here is how I see this set up working. The IP Phone sends a sip request to OBi 1. It can not actually register with Obi 1 but it looks like it might make it believe it is.
Obi 1 sends that request through Obi Talk.
Obitalk translates the 500111101.pnn.obihai.com:5061 to a useable return sip address.
1001@yourIpAdress:5061
That address is passed to Obi2 via Obitalk to pp(ob500222202)
Obi2 forwards a sip request to the PBX from 1001@yourIpAdress:5061
The two devices now talk to each other independent of OBi1.
What happens when calls go the other way appears to work about the same because Obi2 is registered as an extension on the PBX.
Anything look wrong about my assumptions?
Navigation
[0] Message Index
[#] Next page
[*] Previous page