Overview of Asterisk Versions:
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
Download Asterisk:
http://downloads.asterisk.org/pub/telephony/asterisk/
Download Asterisk Admin Guide:
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Exported+Documentation
Asterisk Module Stats (Find out what features are deprecated? Better start using the core applications for future support):
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States
Configuration and Operation:
https://wiki.asterisk.org/wiki/display/AST/Configuration+and+Operation
Great place to for VoIP knowledge base:
http://www.voip-info.org/
Information regarding Upgrade changes:
Please check the UPGRADE*.txt documentation in the Asterisk source you downloaded.
Extras:
Call Center Monitoring:
http://queuemetrics.com/
Operator Solution:
http://www.voiceoperatorpanel.com/
VoiceXML/CCXML Gateway:
http://www.voxeo.com/
http://www.vxml.org/frame.jsp?page=w3cprops.htm
Wednesday, October 12, 2011
Friday, September 30, 2011
Design Long Distance Access Code System in Asterisk
Why Long Distance Access code?
When any organization has hundreds and thousands of users, they don't want each and every user to have long distance dialing access. So, they requests telco to setup set of LD access codes and organization distribute those access codes to the desired users. It's just like password to access long distance dialing from desk phones.
You loose the control when teclo have the control over Long Distance Access codes for your PRI/T1/SIP lines. I was undergoing the same problem. So, I decided to design my own LD access code system.
Step1: Create a file called ldcodes.conf in /etc/asterisk directory and list all the long distance codes in there.
#vi ldcodes.conf
2545368 ; For Mr. Smith
2549347 ; For Mr. Nelson
2545238 ; For Mrs. Ann
2549638 ; For Mrs. Jessica
(Here we created 7 digit LD codes. Those are the LD codes provided to the respective users. Good thing with this is, if Mr. Smith's LD access code is compromised by some other users, you can simply delete that code and create new one for Mr. Smith. You don't have to call your Telco and go thru' the pain of 2-3 weeks to get it done)
Step2: Create a dialplan for long distance dialing in /etc/asterisk/extensions.conf
exten => _91XXXXXXXXXX,1,Verbose(1,--- ${STRFTIME(${EPOCH},,[%m/%d/%Y-%H:%M:%S])} Dialing Long Distance Number: ${EXTEN:1})
same => n,Set(counter=0)
same => n(Pass),read(ldcode,en/enter-long-distance-code)
same => n,Set(counter=$[${counter}+1])
same => n,Set(LDCODES=${SHELL(/usr/bin/less /etc/asterisk/ldcodes.conf|/usr/bin/grep ${ldcode}|/usr/bin/wc -l)})
same => n,Verbose(1,--- Entered code is ${ldcode} and LDCODES is ${LDCODES})
same => n,Verbose(1,--- Shell command executed ${SYSTEMSTATUS} )
same => n,GotoIf($[${counter} >= 5]?Hangup:)
same => n,GotoIf($[$[${LDCODES}=1] & $[${ldcode}>999999]]?Success:Pass)
same => n(Success),Dial(SIP/telco_trunk-out/${EXTEN:1})
same => n(Hangup),Hangup()
read() command asks the user to enter the long distance code. [Make sure that you make the recording enter-long-distance-code and place it under /var/lib/asterisk/sounds/en]
Set(MyVariable=${SHELL()) is the very important and useful command. This command returns the output of SHELL() to a MyVariable. In above case, it is LDCODES
In GotoIf() we are checking if the SHELL() command returned 1 or not & if LDcode provided by user is greater than 999999. If statement is true, go to SUCCESS else go to PASS label.
[Note: above GotoIf() logic always ensures that 7 digit matching is done. You can also achieve this by checking if user entered 7 digit LDcode or not]
To prevent the caller to make unlimited guess, we can limit the password attempts to 5 by using the counter as illustrated above in the dialplan (they are in black).
You can refer to
http://leifmadsen.wordpress.com/2009/07/17/howto-read-a-value-from-a-file-and-say-it-back/
It has good explanation of reading a file in asterisk.
When any organization has hundreds and thousands of users, they don't want each and every user to have long distance dialing access. So, they requests telco to setup set of LD access codes and organization distribute those access codes to the desired users. It's just like password to access long distance dialing from desk phones.
You loose the control when teclo have the control over Long Distance Access codes for your PRI/T1/SIP lines. I was undergoing the same problem. So, I decided to design my own LD access code system.
Step1: Create a file called ldcodes.conf in /etc/asterisk directory and list all the long distance codes in there.
#vi ldcodes.conf
2545368 ; For Mr. Smith
2549347 ; For Mr. Nelson
2545238 ; For Mrs. Ann
2549638 ; For Mrs. Jessica
(Here we created 7 digit LD codes. Those are the LD codes provided to the respective users. Good thing with this is, if Mr. Smith's LD access code is compromised by some other users, you can simply delete that code and create new one for Mr. Smith. You don't have to call your Telco and go thru' the pain of 2-3 weeks to get it done)
Step2: Create a dialplan for long distance dialing in /etc/asterisk/extensions.conf
exten => _91XXXXXXXXXX,1,Verbose(1,--- ${STRFTIME(${EPOCH},,[%m/%d/%Y-%H:%M:%S])} Dialing Long Distance Number: ${EXTEN:1})
same => n,Set(counter=0)
same => n(Pass),read(ldcode,en/enter-long-distance-code)
same => n,Set(counter=$[${counter}+1])
same => n,Set(LDCODES=${SHELL(/usr/bin/less /etc/asterisk/ldcodes.conf|/usr/bin/grep ${ldcode}|/usr/bin/wc -l)})
same => n,Verbose(1,--- Entered code is ${ldcode} and LDCODES is ${LDCODES})
same => n,Verbose(1,--- Shell command executed ${SYSTEMSTATUS} )
same => n,GotoIf($[${counter} >= 5]?Hangup:)
same => n,GotoIf($[$[${LDCODES}=1] & $[${ldcode}>999999]]?Success:Pass)
same => n(Success),Dial(SIP/telco_trunk-out/${EXTEN:1})
same => n(Hangup),Hangup()
read() command asks the user to enter the long distance code. [Make sure that you make the recording enter-long-distance-code and place it under /var/lib/asterisk/sounds/en]
Set(MyVariable=${SHELL()) is the very important and useful command. This command returns the output of SHELL() to a MyVariable. In above case, it is LDCODES
In GotoIf() we are checking if the SHELL() command returned 1 or not & if LDcode provided by user is greater than 999999. If statement is true, go to SUCCESS else go to PASS label.
[Note: above GotoIf() logic always ensures that 7 digit matching is done. You can also achieve this by checking if user entered 7 digit LDcode or not]
To prevent the caller to make unlimited guess, we can limit the password attempts to 5 by using the counter as illustrated above in the dialplan (they are in black).
You can refer to
http://leifmadsen.wordpress.com/2009/07/17/howto-read-a-value-from-a-file-and-say-it-back/
It has good explanation of reading a file in asterisk.
Saturday, June 18, 2011
VoIP quality: culprits and thresholds
VoIP or any real-time application are delay sensitive. One second network delay can impact several seconds of conversation. Broadly, VoIP degradation is the result of three major culprits:
1> Network Latency
2> Jitter
3> Packet Loss
Network Latency: It's the delay for the packets to travel from the speaker to the listener. If network latency is above 150ms on your VoIP environment, it will result in huge degradation in voice quality. More than 90% of time, your ISP is the culprit for high network latency.
Jitter: Delta in the end-to-end arrival time between the received packets. It's resulted because of varying network traffic and conditions on VoIP environment. Jitter below 25 ms is acceptable. Jitter Buffer can be adjusted to reduce the impact of jitter on voice quality. However Jitter Buffer can only handle jitter level up to 100ms.
Packet Loss: It is resulted of heavy network load and congestion. In VoIP environment, retransmission doesn't make any sense as conversation is real-time. Merely 10% (non-consecutive packets) of Packet Loss can cause serious impact on voice quality. Since VoIP uses UDP, it doesn't allow to monitor packet loss detection [ not quite true; RTCP should be able to tell packet loss]
Voice Quality is measured using two widely used factors: MOS (Mean Opinion Score) and R-value. MOS is measured by group of listeners scaling the quality from 1(unintelligible) to 5 (very clear) (defined in ITU P.800). R-value uses mathematical formula incorporating Network Latency, Jitter and Packet Loss and grades on the scale of 1(unintelligible) to 100(very clear) (defined in ITU-T G.107)
R-value-------MOS-------Remarks
90-100-------4.2+--------Very Satisfied
80-90------4.0-4.3-------Satisfied
70-80-------3.6-4.0------Some Unsatisfied
Wireshark can be used to pull the Network Latency and Jitter information from the packet capture done on your VoIP environment.
Access Voice quality SLA from Verizon
References:
Hacking VoIP Exposed by David Endler & Mark Collier
www.verizonbusiness.com
1> Network Latency
2> Jitter
3> Packet Loss
Network Latency: It's the delay for the packets to travel from the speaker to the listener. If network latency is above 150ms on your VoIP environment, it will result in huge degradation in voice quality. More than 90% of time, your ISP is the culprit for high network latency.
Jitter: Delta in the end-to-end arrival time between the received packets. It's resulted because of varying network traffic and conditions on VoIP environment. Jitter below 25 ms is acceptable. Jitter Buffer can be adjusted to reduce the impact of jitter on voice quality. However Jitter Buffer can only handle jitter level up to 100ms.
Packet Loss: It is resulted of heavy network load and congestion. In VoIP environment, retransmission doesn't make any sense as conversation is real-time. Merely 10% (non-consecutive packets) of Packet Loss can cause serious impact on voice quality. Since VoIP uses UDP, it doesn't allow to monitor packet loss detection [ not quite true; RTCP should be able to tell packet loss]
Voice Quality is measured using two widely used factors: MOS (Mean Opinion Score) and R-value. MOS is measured by group of listeners scaling the quality from 1(unintelligible) to 5 (very clear) (defined in ITU P.800). R-value uses mathematical formula incorporating Network Latency, Jitter and Packet Loss and grades on the scale of 1(unintelligible) to 100(very clear) (defined in ITU-T G.107)
R-value-------MOS-------Remarks
90-100-------4.2+--------Very Satisfied
80-90------4.0-4.3-------Satisfied
70-80-------3.6-4.0------Some Unsatisfied
Wireshark can be used to pull the Network Latency and Jitter information from the packet capture done on your VoIP environment.
Access Voice quality SLA from Verizon
References:
Hacking VoIP Exposed by David Endler & Mark Collier
www.verizonbusiness.com
Tuesday, May 17, 2011
Asterisk to Asterisk SIP call without Registration
I have worked on SIP trunking for long time and each time used registration method for Asterisk servers to talk with each other.
Syntax in sip.conf: register => ....
The problem with this is Asterisk Servers send registration requests to each other periodically adding more SIP signalling overhead. So, I thought why not establish the trunk between Asterisk Servers that doesn't require the Servers Registration.
B makes call to A using AsteriskServerA_Trunk
AsteriskServerB ---> [AsteriskServerA_Trunk] ---> AsteriskServerA
A makes call to B using AsteriskServerB_Trunk
AsteriskServerA ---> [AsteriskServerB_Trunk] ---> AsteriskServerB
AsteriskServerA:
/etc/asterisk/sip.conf
[AsteriskServerB_Trunk]
type=peer
fromdomain = [AsteriskServerA IP Add]
host = [AsteriskServerB IP Add]
outboundproxy = [AsteriskServerB IP Add]
context = Internal
[11111]
type=friend
host=dynamic
username=11111
mailbox=11111
AsteriskServerB:
/etc/asterisk/sip.conf
[AsteriskServerA_Trunk]
type=peer
fromdomain = [AsteriskServerB IP Add]
host = [AsteriskServerA IP Add]
outboundproxy = [AsteriskServerA IP Add]
context = Internal
[22222]
type=friend
host=dynamic
username=22222
mailbox=22222
Dialplan in ServerA:
extensions.conf
[Internal]
exten => 22222,1,Verbose(1,-----Check the trunk )
same => n,Dial(SIP/AsteriskServerB_Trunk/22222)
exten => 11111,1,Verbose(1,----Dialing local number)
same => n, Dial(SIP/11111)
Dialplan in ServerB
extensions.conf
[Internal]
exten => 11111,1,Verbose(1,-----Check the trunk )
same => n,Dial(SIP/AsteriskServerA_Trunk/11111)
exten => 22222,1,Verbose(1,----Dialing local number)
same => n, Dial(SIP/22222)
Now you can use free SIP based SoftPhones like X-lite, Zoiper and register extension 11111 with Server A and extension 22222 with Server B. Then make a test call from 11111 to 22222 and vice-versa. It should work.
If you need any assistance, you can email me at erdevendra@gmail.com
Syntax in sip.conf: register => ....
The problem with this is Asterisk Servers send registration requests to each other periodically adding more SIP signalling overhead. So, I thought why not establish the trunk between Asterisk Servers that doesn't require the Servers Registration.
B makes call to A using AsteriskServerA_Trunk
AsteriskServerB ---> [AsteriskServerA_Trunk] ---> AsteriskServerA
A makes call to B using AsteriskServerB_Trunk
AsteriskServerA ---> [AsteriskServerB_Trunk] ---> AsteriskServerB
AsteriskServerA:
/etc/asterisk/sip.conf
[AsteriskServerB_Trunk]
type=peer
fromdomain = [AsteriskServerA IP Add]
host = [AsteriskServerB IP Add]
outboundproxy = [AsteriskServerB IP Add]
context = Internal
[11111]
type=friend
host=dynamic
username=11111
mailbox=11111
AsteriskServerB:
/etc/asterisk/sip.conf
[AsteriskServerA_Trunk]
type=peer
fromdomain = [AsteriskServerB IP Add]
host = [AsteriskServerA IP Add]
outboundproxy = [AsteriskServerA IP Add]
context = Internal
[22222]
type=friend
host=dynamic
username=22222
mailbox=22222
Dialplan in ServerA:
extensions.conf
[Internal]
exten => 22222,1,Verbose(1,-----Check the trunk )
same => n,Dial(SIP/AsteriskServerB_Trunk/22222)
exten => 11111,1,Verbose(1,----Dialing local number)
same => n, Dial(SIP/11111)
Dialplan in ServerB
extensions.conf
[Internal]
exten => 11111,1,Verbose(1,-----Check the trunk )
same => n,Dial(SIP/AsteriskServerA_Trunk/11111)
exten => 22222,1,Verbose(1,----Dialing local number)
same => n, Dial(SIP/22222)
Now you can use free SIP based SoftPhones like X-lite, Zoiper and register extension 11111 with Server A and extension 22222 with Server B. Then make a test call from 11111 to 22222 and vice-versa. It should work.
If you need any assistance, you can email me at erdevendra@gmail.com
Friday, February 25, 2011
DTMF issue on Asterisk
IVR and DTMF doesn't work very well if you have VoIP and PSTN connectivity.
IVR to work with VoIP<-->PSTN system perfectly, DTMF coding must be precise which can't be achieved perfectly with VoIP system (no matter if it is CISCO, AVAYA or Asterisk) all the time.
VoIP<-->VoIP is not a problem as DTMF code is passed as RTP payload and they know what to do with it.
VoIP<----RTP Payload------------RTP Payload------>VoIP
But with VoIP<-->PSTN, those DTMF tone has to be converted to RTP payload or RTP payload has to be converted back to DTMF tone, which doesn't happen precisely all the time.
VoIP <----RTP Payload--------------------DTMF------>PSTN
Q: How can I troubleshoot DTMF on asterisk?
Ans: You can go to /etc/asterisk/logger.conf and add dtmf for logging.
#vi /etc/asterisk/logger.conf
[logfiles]
full => verbose,debug,dtmf
Reload logger in asterisk
#asterisk -rv
CLI> logger reload
Perform test calls.
#tail -f /var/log/asterisk/full [ to see the realtime data logging ]
Press Ctrl + C to get out of the real time data monitoring
Q: I am having issues with duplicate DTMF. It appears that my asterisk box is receiving doubled DTMF signals. What could I do to fix it?
Ans: You have to change the setting in /etc/asterisk/chan_dahdi.conf. Add relaxdtmf=yes in that file.
Please ignore trunkgroups setting if that's not applicable in your environment. You simply need is relaxdtmf=yes under [channels] context
#vi /etc/asterisk/chan_dahdi.conf
[trunkgroups]
trunkgroup => 2,24,48
spanmap => 1,2,l
spanmap => 2,2,0
[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
callerid=asreceived
relaxdtmf=yes
;This is PSTN Connection (G2)
context=From_Dahdi
switchtype=national
signalling=pri_cpe
group=2
channel => 1-23
channel => 25-47
Q: What kind of DTMF signalling should I prefer?
Ans: Out-of-band technique or RFT2833 is the most appropriate one and it's default on asterisk. You can explicitly specify
dtmfmode=auto [ Use rfc2833 if offered, inband otherwise ]
or
dtmfmode=rfc2833
If you are using SIP channels/trunks, define dtmfmode in sip.conf under [general] context
For more info you can visit www.voip-info.org
IVR to work with VoIP<-->PSTN system perfectly, DTMF coding must be precise which can't be achieved perfectly with VoIP system (no matter if it is CISCO, AVAYA or Asterisk) all the time.
VoIP<-->VoIP is not a problem as DTMF code is passed as RTP payload and they know what to do with it.
VoIP<----RTP Payload------------RTP Payload------>VoIP
But with VoIP<-->PSTN, those DTMF tone has to be converted to RTP payload or RTP payload has to be converted back to DTMF tone, which doesn't happen precisely all the time.
VoIP <----RTP Payload--------------------DTMF------>PSTN
Q: How can I troubleshoot DTMF on asterisk?
Ans: You can go to /etc/asterisk/logger.conf and add dtmf for logging.
#vi /etc/asterisk/logger.conf
[logfiles]
full => verbose,debug,dtmf
Reload logger in asterisk
#asterisk -rv
CLI> logger reload
Perform test calls.
#tail -f /var/log/asterisk/full [ to see the realtime data logging ]
Press Ctrl + C to get out of the real time data monitoring
Q: I am having issues with duplicate DTMF. It appears that my asterisk box is receiving doubled DTMF signals. What could I do to fix it?
Ans: You have to change the setting in /etc/asterisk/chan_dahdi.conf. Add relaxdtmf=yes in that file.
Please ignore trunkgroups setting if that's not applicable in your environment. You simply need is relaxdtmf=yes under [channels] context
#vi /etc/asterisk/chan_dahdi.conf
[trunkgroups]
trunkgroup => 2,24,48
spanmap => 1,2,l
spanmap => 2,2,0
[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
callerid=asreceived
relaxdtmf=yes
;This is PSTN Connection (G2)
context=From_Dahdi
switchtype=national
signalling=pri_cpe
group=2
channel => 1-23
channel => 25-47
Q: What kind of DTMF signalling should I prefer?
Ans: Out-of-band technique or RFT2833 is the most appropriate one and it's default on asterisk. You can explicitly specify
dtmfmode=auto [ Use rfc2833 if offered, inband otherwise ]
or
dtmfmode=rfc2833
If you are using SIP channels/trunks, define dtmfmode in sip.conf under [general] context
For more info you can visit www.voip-info.org
Tuesday, February 15, 2011
G711 vs G729 Which one to choose?
G711 is ITU-T standard for audio compression and decompression (i.e codec). It uses pulse code modulation (PCM) technique i.e sampling the audio signal and digitize each sample (voltage) to binary (0's and 1's).
Sender side:
Human Voice/Audio ---> Filter --> 4Khz ----> Nyquist Sampling at 8Khz ----> A/D converter [each sample changed to 8 bit] ----> 64Kb per second
Thus data rate of G711 is 64Kbps
Receiver side:
Digital data is converted back to audio using D/A converter.
It is very simple, less CPU intensive and widely used. However, if bandwidth is expensive, it's not a good option. There are various codecs. Most efficient (bandwidth wise *NOT* CPU wise) one is G729.
Wikipedia: G729 does coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP).
G729 uses complex algorithms to synthesize the speakers' voice. It uses vocoder [ tone generator + white noise generator + filter] to shape the sound as the nose, lip, throat, tounge and vocal cavity do. Vocoder itself generates robotic tone which is not acceptable. Thus G729 also uses samples of speakers' voice to adjust the vocoder setting properly and it compares synthetic voice with actual voice to come up with *CODE*. Then that CODE and vocoder settings are sent to the receiver. Receiver generates the sound using the provided CODE and vocoder settings.
Isn't that cool? However, it's CPU intensive.
G711 is free, however G729 requires license ( $10 per channel).
Summary:
Sender side:
Human Voice/Audio ---> Filter --> 4Khz ----> Nyquist Sampling at 8Khz ----> A/D converter [each sample changed to 8 bit] ----> 64Kb per second
Thus data rate of G711 is 64Kbps
Receiver side:
Digital data is converted back to audio using D/A converter.
It is very simple, less CPU intensive and widely used. However, if bandwidth is expensive, it's not a good option. There are various codecs. Most efficient (bandwidth wise *NOT* CPU wise) one is G729.
Wikipedia: G729 does coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP).
G729 uses complex algorithms to synthesize the speakers' voice. It uses vocoder [ tone generator + white noise generator + filter] to shape the sound as the nose, lip, throat, tounge and vocal cavity do. Vocoder itself generates robotic tone which is not acceptable. Thus G729 also uses samples of speakers' voice to adjust the vocoder setting properly and it compares synthetic voice with actual voice to come up with *CODE*. Then that CODE and vocoder settings are sent to the receiver. Receiver generates the sound using the provided CODE and vocoder settings.
Isn't that cool? However, it's CPU intensive.
G711 is free, however G729 requires license ( $10 per channel).
Summary:
- G711 sends actual sample of speakers' voice, while G729 sends the vocoder settings and calculated CODE required to generate the voice.
- Data rate: G711 = 64Kbps , G729 = 8Kbps
- G711 uses high bandwidth but it's not CPU intensive. G729 uses less bandwidth but it's CPU intensive
- Unlike G711,G729 is not free
- In VOIP implementation, G711 uses 87Kbps and G729 uses 32 Kbps (with all TCP/IP overhead)
SIP Communication ( SIP Signalling and Media transport)
SIP (Session Initiation Protocol: RFC 3261) Communication involves SIP signaling ( initiate, modify and terminate sessions/calls) and MEDIA transport (using RTP).
In what conditions Asterisk is forced to handle the media stream?
In following conditions, Asterisk involves in media between the phones/UAs.
Why Asterisk is not SIP Proxy? [ from voip-info.org ]
Asterisk, as a server, is a SIP Registrar, location server and also acts as a useragent endpoint (softphone).
If it is 'controlling' or relaying a call from a SIP phone to another SIP phone, it simply acts as an endpoint UA to the originating call leg and then creates a new call to the receiving phone. Therefore, it stays "in the middle of the call," maintaining state and controlling, and optionally bridging, each remote endpoint. The audio channels (RTP) may go directly from phone to phone or may go through Asterisk's media bridge.
Asterisk can thus be described best as a "back-to-back user agent" (B2BUA), which is also consistent with the use of the term "PBX". Because of this architecture, fairly simple SIP functions, such as REFER (transfer) involve more aspects of the Asterisk core. On the other hand, the architecture provides additional power and flexibility, because each call leg can just as easily be replaced with a different technology channel (ZAP, H323, MGCP, etc) and, thus, Asterisk becomes a powerful media gateway.
SIP Proxy usually doesn't involve in the media stream between the phones, it simply handles SIP signalling. A SIP proxy handles call control on behalf of other user agents (UA) and usually does not maintain state during a call and therefore is never the endpoint of a call.
For more info click here
In what conditions Asterisk is forced to handle the media stream?
In following conditions, Asterisk involves in media between the phones/UAs.
- If one of the clients is configured with canreinvite=NO, Asterisk will not issue a re-invite at all and will not redirect the media path.
- If the clients use different codecs, Asterisk will not issue a re-invite.
- If the Dial( ) command contains ''t'', ''T", "h", "H", "w", "W" or "L" (with multiple arguments) Asterisk will not issue a re-invite.
Why Asterisk is not SIP Proxy? [ from voip-info.org ]
Asterisk, as a server, is a SIP Registrar, location server and also acts as a useragent endpoint (softphone).
If it is 'controlling' or relaying a call from a SIP phone to another SIP phone, it simply acts as an endpoint UA to the originating call leg and then creates a new call to the receiving phone. Therefore, it stays "in the middle of the call," maintaining state and controlling, and optionally bridging, each remote endpoint. The audio channels (RTP) may go directly from phone to phone or may go through Asterisk's media bridge.
Asterisk can thus be described best as a "back-to-back user agent" (B2BUA), which is also consistent with the use of the term "PBX". Because of this architecture, fairly simple SIP functions, such as REFER (transfer) involve more aspects of the Asterisk core. On the other hand, the architecture provides additional power and flexibility, because each call leg can just as easily be replaced with a different technology channel (ZAP, H323, MGCP, etc) and, thus, Asterisk becomes a powerful media gateway.
SIP Proxy usually doesn't involve in the media stream between the phones, it simply handles SIP signalling. A SIP proxy handles call control on behalf of other user agents (UA) and usually does not maintain state during a call and therefore is never the endpoint of a call.
For more info click here
Subscribe to:
Posts (Atom)