You can actually modify that behaviour with Asterisk somewhat to allow reinvites to go straight from client to client (and make it work more like default SER), and can add in MediaProxy to the SER mix to make it work a little more like default Asterisk (passing everything through a central location) as well as mucking a bit with the routing. It's STILL really passing off the RTP traffic to somewhere else, however... even if that somewhere else may be on the same server.
But yes... your assumption of basic behaviour is correct.
SER creates almost a P2P scenario for communications... with a central server passing the command channel back and forth, but the data being passed directly between clients to limit both overhead and the possible number of additional hops between clients.
Of course, this means that SER alone is unable to do things like allow VoIP companies that connect to the PSTN to adhere to the new FCC-mandated silliness (CALEA provisions). But as MOST people are going to forward PSTN traffic through something like Asterisk ANYway (since SER has no way of keeping track of the RTP data itself, there's no way to terminate RTP sessions mid-stream... which could get pricy :) ), then it's not that big an issue.
The basic different between the two pieces of software is that Asterisk is a full-featured phone software component. Its SIP portion, however, is not the world's best SIP rendition. However, it has a good many other things that SER doesn't have for dealing with phone communications, and its primary concern is handling a phone call, data and all.
SER is a SIP messaging server. It doesn't natively have all the bells and whistles of Asterisk, nor can it do many of the things Asterisk can do because SER is less concerned with the data and more concerned with the communication path between clients. This commincation might have an RTP component (which SER would pass off elsewhere or let the UAs take care of), but it might just be SIP messages back and forth.
On Wed, 16 Nov 2005 14:38:45 +0100 (CET), Arne Van Theemsche wrote
Hi,
I've been spending days on tcpdumping callsetups with ser OR asterisk as registar. This is my conclusion, can somebody confirm this?
On asterisk: -asterisk maintains 2 independendly sipsessions between 2 clients, where asterisks stays the contact in the sipheaders. After picking up the call, asterisk sends an re-invite in the sip-body (address), and remains the contact for sipmessages. If someone hangs up, asterisk sends an re-invite to the other party, for redirecting stream back to asterisk, and then sending the bye to the other client (the one who didn't hang up).
on ser: ser receives the invite, looking up the address of the callee, and sending the invite through to the callee, the contact header allways stays the caller's uri, but ser put's a record-route in the sipmessage, so that the bye first is send to the ser machine, and then to the other party.
Am I seeing things correct here?
What are the pro/contra's of both procedures?
Imo gives the asterisk way a lot more overhead, but is more secure (2 clients keep communicating with asterisk, and are unable to fake things (or less easely), there were an not compliant client can bypass the record-route of ser, and so avoiding accounting.
Again, am I correct here?
thx Arne
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers