Why are there inbound and outbound boundaries with phones but not with Facebook/Google/Apple voice chats? Can we answer that question by looking at the smallest bits and pieces ourselves? I think so. But, what is the implication behind all these?
OK. In my diagram above, when lines, connections touch, it means they are associated. The purple inbound dialings do not touch any trunk lines, which means the inbound dialings are not associated with any particular trunk line. The orange PBX outbound dialing does not touch any phone line and is not associated with any phone protocol. The PBX outbound dialing, however, does touch SIP trunk line, which means it only goes out on the SIP trunk and not H323 protocol. So, all that means is that an inbound dialing does not care what the outbound trunk or protocol will be; an outbound dialing does not care what the inbound phone or protocol is. This is the essence of the PSTN call leg and the essence of VOIP.
For the green VOIP signal dash lines, the corresponding configs are in pjsip.aor.conf ,
[101] type=aor [102] type=aor |
[SIP-to-CUCM]
type=aor contact=sip:10.1.10.76:5060 |
[10.1.10.76]
type=friend
context=from-trunk
host=10.1.10.76
port=1720
|
[ekiga223]
IP=10.1.10.223
port = 1720
type=peer
context=from-external
|
. The purple inbound dialings are in extensions_additional.conf ,
[ext-did-0002]
exten => 18001231101,1,Set(__DIRECTION=INBOUND)
exten => 18001231101,n(dest-ext),Goto(from-did-direct,101,1)
exten => 18001231102,1,Set(__DIRECTION=INBOUND)
exten => 18001231102,n(dest-ext),Goto(from-did-direct,102,1)
[ext-did-0002]
exten => 18001231101,1,Set(__DIRECTION=INBOUND)
exten => 18001231101,n(dest-ext),Goto(from-did-direct,101,1)
exten => 18001231102,1,Set(__DIRECTION=INBOUND)
exten => 18001231102,n(dest-ext),Goto(from-did-direct,102,1)
exten => 18004561203,1,Set(__DIRECTION=INBOUND)
exten => 18004561203,n(dest-ext),Goto(from-did-direct,203,1)
, and outbound dialings are also in extensions_additional.conf ,
[outrt-1] ; siptrunk
exten => _1800321XXXX,1,Macro(user-callerid,LIMIT,EXTERNAL,)
exten => _1800321XXXX,n,Macro(dialout-trunk,2,${EXTEN:7},,off)
[outrt-2] ; h323trunk
exten => _1800654XXXX,1,Macro(user-callerid,LIMIT,EXTERNAL,)
exten => _1800654XXXX,n,Macro(dialout-trunk,1,${EXTEN:7},,off)
. The FreePBX GUI generates the entire extensions_additional.conf and pjsip_aor.conf . ooh323.conf is entirely manually created. All configurations are downloadable here, https://drive.google.com/file/d/0B2NfHoyfFf1aTWR6QUxQQVhkQWc .
The GUI dialogs are
The voice-vlan enabled router configuration is as https://drive.google.com/file/d/0B2NfHoyfFf1aNXRhMnJyU01Zb0E .
The CUCM GUI screenshots are
So, a call leg becomes a proxy in the TCP/IP/HTTP world so that the destination and source phones do not know the IP address of each other. The very definition of protocol proxy. It provides some isolation("does not care") of parts of the network while requiring the border routers to have the insights into the protocol. Speaking of proxy, do you know that this very page you are viewing is a proxy'ed page when you are at blog.mpls-phone.com, which is 34.225.89.249 . The true IP address of the web server is google's blogger web server IP address. That will be yet another posting about the Apache configuration that made the proxy.The GUI dialogs are
|
|
The voice-vlan enabled router configuration is as https://drive.google.com/file/d/0B2NfHoyfFf1aNXRhMnJyU01Zb0E .
The CUCM GUI screenshots are
No comments:
Post a Comment