16 Nov
2005
16 Nov
'05
8:38 a.m.
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
16 Nov
16 Nov
9 a.m.
New subject: [Serusers] difference between callsetup asterisk & ser and related security risks
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
9:54 a.m.
New subject: [Serusers] difference between callsetup asterisk & ser and related security risks
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).
I never saw a reINVITE if one party hangs up, just a BYE. MAybe this
depends on your extensions.cfg or sip.cfg settings.
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?
yes
What are the pro/contra's of both procedures?
asterisk: it atcs as a B2B-UA, thus asterisk has full control over the call.
ser: it just relays messages. The whole is an end2end service.
Eg. if you transfer a call, the whole transfer is done by the phones
when using ser. When using asterisk, the transferer initiates the
transfer, but the other party does not have a SIP signaling indication
that the call will be transfered.
Imo gives the asterisk way a lot more overhead, but is
more secure (2
depends on what you mean with secure. secure for the client or secure
for the ITSP?
clients keep communicating with asterisk, and are
unable to fake things
yes
(or less easely), there were an not compliant client
can bypass the
record-route of ser, and so avoiding accounting.
yes. If you have IP-IP calls and you do not charge them, there is no
reason why the phone should bypass the proxy (e.g. NAT traversal will
work better when using record-route).
If it is an IP-PSTN call, the GW should produce the accounting data.
klaus
Again, am I correct here?
thx
Arne
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6806
days inactive
6806
days old
2 comments
3 participants
participants (3)
-
Arne Van Theemsche -
Klaus Darilion -
sip