Let's go through how SIP works in Asterisk compared with a SIP Proxy. Remember that Asterisk is not designed to be a SIP Proxy, it's designed to be a Multi-VOIP and PSTN PBX, a quite complicated task.
(I'm not going into all details (ACK, TRYING, RINGING etc))
We have two SIP users, Alice and Bob.
Alice calls BOB, both connected to Asterisk:
* Alice's UA sends an INVITE to [EMAIL PROTECTED] * Asterisk checks if bob is a valid user reachable within the context allowed by Alice's account * Asterisk answers the SIP call from Alice * Asterisk initiates another SIP call to Bob's UA with a NEW Invite * When Bob answers, Asterisk bridges the streams, performing codec conversion if necessary
In this scenario, we now have two different SIP dialogues (two separate SIP calls)
If both Alice and Bob are connected without NAT, have the same codec support and have canreinvite=yes * Asterisk send (re-)INVITEs to both, trying to get the RTP stream transferred so it goes directly from Alice to Bob Not all UAs support a re-INVITE and in public scenarios, a lot of UAs have broken NAT support so the RTP media stream stays with Asterisk.
The benefit of this is that Asterisk acting as a user agent server (Alice) and client (bob) can send early media to Alice, connect to voicemail or another extension than Bob if Bob had issued a forward - maybe a H.323 connection or PSTN connection somewhere.
------------ With a SIP proxy we have the following scenario:
* Alice's UA sends an INVITE to [EMAIL PROTECTED] * The proxy responsible for thte domain receives this and looks up bob in a user location or alias table * The proxy *FORWARDS* the same INVITE to [EMAIL PROTECTED], maybe several different locations * When Bob answers somewhere, the proxy cancels the call to the non-answering locations and forwards the OK to Alice * Alice ACKs the OK to bob and the call is UP
In this scenario, there's only one SIP dialogue, between Alice and Bob with the proxy in the middle of signalling, but acting as a proxy and not as a user agent (the proxy can't and should not answer or originate calls).
----------- So, back to the original question, in a large installation (many users) - how do you off-load Asterisk? There's no single truth here, but here's my opinion:
* If you are all on the same internal network, make sure the SIP phones support re-invites and use that. * If you have users all over the Internet, use a SIP proxy as a front-end to Asterisk You will still be forced to handle a lot of RTP streams (because of NAT), but can distribute that over a SIP-proxy network with SRV records, DNS round-robin techniques or forcing the users to register with different proxies.
There's been a couple of suggestions that we should make Asterisk a good SIP proxy. If you spend some time learning to understand Asterisk's architecture, you'll also understand that this would not really work. I'm not saying the SIP channel can't be improved, I'm just saying that it has to work with the rest of Asterisk's architecture. I might be totally wrong, but my gut feeling is that Asterisk in combination with a separate SIP proxy is a very powerful solution.
Clustering Asterisk servers somehow is also a good approach, but not here yet for SIP.
/O
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
