16 Nov
2005
16 Nov
'05
9 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers