Hi Ovidiu
Thanks for your help.
The SIP proxy seems to me a better approach. I think I'll use also dialog module (if I success using it) and later mediaproxy.
Michel.
Ovidiu Sas wrote:
Hi Michel,
It all depends on what you want to do. Here are the two approaches and the associated issues:
- SIP Proxy:
- you don't have control over the negotiated codec(s)
- if the two parties agrees on a set of codecs, you don't know which
one will be used. Even worst, the parties may change the codec without renegotiating, since it is part of the negotiated set.
- you don't have control over the stream packetization.
- B2BUA:
- you may force a single code to be used.
- you may force the packetization for outgoing media, but you have
no control over the packetization of the incoming stream.
Computing the required bandwidth for VoIP calls is really tough unless you work with well known SIP UAs and you know what to expect.
Hope this helps, Ovidiu Sas
PS: you might wanna take a look at http://www.nslu2-linux.org/ There are several VoIP packages (openSER, rtpproxy, asterisk) that were ported to several embedded platforms including dd-wrt.
On 2/20/07, Michel Bensoussan michel@extricom.com wrote:
Klaus Darilion wrote:
Michel Bensoussan wrote:
"If the media goes directly from caller to callee I wonder why you need to know the bandwidth at all as the RTP packets may be out of your network."
I need to write a CAC (Call Admission Control) module for an 802.11 AP (Access Point). The idea is to use a SIP Proxy to monitoring bandwith utilization according to codec, and allow or disallow new sessions, depending on resources.
Do you need to know the bandwidth in advance (thus guessing the neede bandwidth during call setup and eventually deny the call setup if the required bandwidth can not be guaranteed) (a) or do you need to know the exact current bandwidth need (b)?
In case of (a) I think you need a B2BUA in the AP.
I just look for B2BUA in google (I didn't know it) and it's interesting. Guessing the bandwidth can be good for a first step but this is not enough.
In case of (b) you can parse the RTP sockets and then count the media packets routed by the AP to calculate the bandwidth.
Or you can port mediaproxy to the accesspoint and use thus
capabilities. Case (b) is of course the target and mediaproxy looks useful, even if I don't need the NAT features.
regards klaus
Regards, Michel.
Klaus Darilion wrote:
Michel Bensoussan wrote:
Klaus Darilion wrote: > Parsing the SDP does not give you the used codec as there may be > several codecs in the SDP and you do not know which codec is used > by the clients. This is true for INVITE message but as I understand (but I'm not familiar with SIP), in the OK message, we can determine which codec is used. No?
Not always. Often the 200 OK contains only one codec which will be used by both parties. But I think there may also be asynchronous codec (caller sends G711, callee sends G729).
> But for example you can use mediaproxy. Mediaproxy allows you to > retrieve the status of all current calls (codecs, bandwidth, ...) Well, the mediaproxy module needs an external proxy server. So it seems to be too heavy for my needs. The real time session statistics (from MediaProxy Server) will be very useful but I'm not sure it's a good idea to use the server it if I don't need the NAT traversal features.
If the media goes directly from caller to callee I wonder why you need to know the bandwidth at all as the RTP packets may be out of your network.
regards klaus
> > regards > klaus > > Michel Bensoussan wrote: >> Hello >> For each voice session I need to know the used codec (for >> bandwith calculation). For that I need to parse the SIP message >> body. >> I didn't find in OpenSER such a functionality. >> Is there a module that doing that? >> Or maybe someone is working on it? >> A suggestion for an open source? >> >> Thanks. >> >> Regards, >> Michel. >> >> >> >> _______________________________________________ >> Users mailing list >> Users@openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users > >
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users