On the QOS part,
LAN -> WAN
Packet Type : ANY (tried as well with TCP only)
Assigned minimum Garanteed : 50% with high priority (Which is 224 kbps
minimum)
What do you think about such configuration ?
And when I am sending some email, I can hear the person correctly, but
he cannot understand me correctly while sending information ... :-(
Stephane M wrote:
> Hi,
>
> I've got a Modem Router, which supports QoS service
>
> I gave high priority to my SIP protocol....
> But I still have some troubles, when I am on the phone and I am sending
> an email (for instance)
>
> I have the same problem at work, where I am using a Netgear FVX538.
>
> To give an example, at home I am using 'Billion BiPAC 7300G'
>
> On the QOS part,
> LAN -> WAN
> Packet Type : ANY (tried as well with TCP only)
SIP and RTP (the audio) tend to use RTP.
If you are using packet type any, then it is unlikely to succeed because
some types of packet don't have port numbers. You can only match them
by IP address.
You need to see what port numbers your phones are using for RTP. They
may be different with each call. Inbound audio may well use different
port numbers to outbound.
> And when I am sending some email, I can hear the person correctly, but
> he cannot understand me correctly while sending information ... :-(
In a SIP phone call, the 2 audio streams are largely independent of each
other.
If you try to send more data out than your outbound connection can cope
with, then the buffer in the router will fill. When the buffer fills,
packets are lost and you lose voice quality.
When a router is giving priority to a certain type of packets, then it
will drop other kinds of packets first. Or on a really good router, it
will send back ECN (explicit congestion notification) packets to try and
get the sender to slow down.
In my experience, I've never found the Qos features of consumer grade
routers to be much good. And in some cases they cause more harm than good.
In other cases, people try to buy a qos router to solve some other
problem which is giving poor call quality. A router that can give
priority will not magically fix a bad connection.
A CTX1000 is the best prioritisation device I know of at the moment.
I am bit surprised that the QoS is not so good actually...
Anyway...
I thought that SIP was the protocol for all VoIP communications ? I
mean, I thought that even the the Audio of the communciation, used this
protocol... !?!
Anyway, I found on ny phone, that RTP port is [ 16384 - 16482 ]
So I added, on my QoS service..
1) Do you know which protocol is using RTP ? (TCP/IP ???)
Concerning a previous 'post' on Secure VoIP, I didn't find anything on
SIPS, but found into the "line EXT" the SRTP private Key
Now, I will investigate on an ASterisk server, how I can add the key for
the communication...
Thanks for your help
Stephane
Tim a écrit :
> Stephane M wrote:
>> Hi,
>>
>> I've got a Modem Router, which supports QoS service
>>
>> I gave high priority to my SIP protocol....
>> But I still have some troubles, when I am on the phone and I am sending
>> an email (for instance)
>>
>> I have the same problem at work, where I am using a Netgear FVX538.
>>
>> To give an example, at home I am using 'Billion BiPAC 7300G'
>>
>
>
>> On the QOS part,
>> LAN -> WAN
>> Packet Type : ANY (tried as well with TCP only)
>
> SIP and RTP (the audio) tend to use RTP.
>
> If you are using packet type any, then it is unlikely to succeed because
> some types of packet don't have port numbers. You can only match them
> by IP address.
>
>> Local Application ports : 5000 - 5100
>> Remote Application ports : 5000 - 5100
>
> You need to see what port numbers your phones are using for RTP. They
> may be different with each call. Inbound audio may well use different
> port numbers to outbound.
>
>
>> And when I am sending some email, I can hear the person correctly, but
>> he cannot understand me correctly while sending information ... :-(
>
> In a SIP phone call, the 2 audio streams are largely independent of each
> other.
>
> If you try to send more data out than your outbound connection can cope
> with, then the buffer in the router will fill. When the buffer fills,
> packets are lost and you lose voice quality.
>
> When a router is giving priority to a certain type of packets, then it
> will drop other kinds of packets first. Or on a really good router, it
> will send back ECN (explicit congestion notification) packets to try and
> get the sender to slow down.
>
> In my experience, I've never found the Qos features of consumer grade
> routers to be much good. And in some cases they cause more harm than good.
>
> In other cases, people try to buy a qos router to solve some other
> problem which is giving poor call quality. A router that can give
> priority will not magically fix a bad connection.
>
> A CTX1000 is the best prioritisation device I know of at the moment.
>
> Tim
Stephane M wrote:
>
> I am bit surprised that the QoS is not so good actually...
The people who make routers seem to understand very very little about SIP.
If you really want Qos to work, stop faffing and buy a CTX1000.
> I thought that SIP was the protocol for all VoIP communications ? I
> mean, I thought that even the the Audio of the communciation, used this
> protocol... !?!
Not at all.
Session initiation protocol. SIP sets up the sessions. In the most
common case, they are 2 RTP audio sessions (one each way). The sessions
are described using SDP - which is carried in the SIP messages.
In practice SIP could setup anything. The ones I've heard talked about
are online gaming sessions and shared whiteboard sessions.
> Anyway, I found on ny phone, that RTP port is [ 16384 - 16482 ]
> So I added, on my QoS service..
Those will be the ports for which your phone requests RTP to be sent to.
Your inbound RTP.
Your SIP service provider may request that the RTP is sent outbound to
completely different ports.
> 1) Do you know which protocol is using RTP ? (TCP/IP ???)
RTP travels over UDP which travels over IP.
> Concerning a previous 'post' on Secure VoIP, I didn't find anything on
> SIPS, but found into the "line EXT" the SRTP private Key
> Now, I will investigate on an ASterisk server, how I can add the key for
> the communication...
For SRTP, you really need to use a new random key for each call.
I can run SIP training days if you want to learn a lot more quickly.
In article <evdfic$24c$1$8300dec7@news.demon.co.uk>,
Stephane M <Stephane@M.com> wrote:
>Hi Tim,
>
>Thanks for your feedback
>
>I am bit surprised that the QoS is not so good actually...
>Anyway...
>
>I thought that SIP was the protocol for all VoIP communications ? I
>mean, I thought that even the the Audio of the communciation, used this
>protocol... !?!
SIP is the Session Initiation Protocol. It controls the signaling between
the end-points. It does authentication, sends the dial codes, and lets each
end tell each other (to some extent) how to carry the call data between
each end-point.
>Anyway, I found on ny phone, that RTP port is [ 16384 - 16482 ]
>So I added, on my QoS service..
>
>1) Do you know which protocol is using RTP ? (TCP/IP ???)
RTP is the protocol. (Realtime Transport Protocol) It's UDP.
One issue you'll never be able to solve, no matter what router you use
is that once your data is out on the Internet you have absolutely zero
control over it.
All you can effectively do at your end is control data leaving your
network. If you do large uploads, (data leaving your network) then you
can prioritise your VoIP traffic over this.
However one thing you can't do is prioritise incoming VoIP traffic over
any other incoming traffic, and the reason for this is simple - by the
time you get the packet and decide to delay it (if it's not a VoIP packet)
it's too late. That packet has already come over the wire. There are
tricks that can help, but you can never successfully prioritise incoming
traffic, especially stuff with real-time contraints.
So if you are having issues, the best thing to do is simply shut down
all traffic when making calls. Not much help when a call comes in though,
and once on the 'net, it's anyones guess what'll happen to the packets,
so make sure you use a decent ISP who doesn't have a conjested internal
network of their own, and be prepared to pay for it!
But I think about companies, which want to install a VoIP system....
that seems to me not really suitable for companies..
you can't ask people to stop downloading while phoning :-)
So, I can't really see any possibility for professional use... Seems to
be a bit dodgy !??
I installed in the company an FVX538, thinking that I would be able to
use VoIP systems...
So, the only solution would be the CTX1000 ???
Stephane
Gordon Henderson a écrit :
> In article <evdfic$24c$1$8300dec7@news.demon.co.uk>,
> Stephane M <Stephane@M.com> wrote:
>> Hi Tim,
>>
>> Thanks for your feedback
>>
>> I am bit surprised that the QoS is not so good actually...
>> Anyway...
>>
>> I thought that SIP was the protocol for all VoIP communications ? I
>> mean, I thought that even the the Audio of the communciation, used this
>> protocol... !?!
>
> SIP is the Session Initiation Protocol. It controls the signaling between
> the end-points. It does authentication, sends the dial codes, and lets each
> end tell each other (to some extent) how to carry the call data between
> each end-point.
>
>> Anyway, I found on ny phone, that RTP port is [ 16384 - 16482 ]
>> So I added, on my QoS service..
>>
>> 1) Do you know which protocol is using RTP ? (TCP/IP ???)
>
> RTP is the protocol. (Realtime Transport Protocol) It's UDP.
>
> One issue you'll never be able to solve, no matter what router you use
> is that once your data is out on the Internet you have absolutely zero
> control over it.
>
> All you can effectively do at your end is control data leaving your
> network. If you do large uploads, (data leaving your network) then you
> can prioritise your VoIP traffic over this.
>
> However one thing you can't do is prioritise incoming VoIP traffic over
> any other incoming traffic, and the reason for this is simple - by the
> time you get the packet and decide to delay it (if it's not a VoIP packet)
> it's too late. That packet has already come over the wire. There are
> tricks that can help, but you can never successfully prioritise incoming
> traffic, especially stuff with real-time contraints.
>
> So if you are having issues, the best thing to do is simply shut down
> all traffic when making calls. Not much help when a call comes in though,
> and once on the 'net, it's anyones guess what'll happen to the packets,
> so make sure you use a decent ISP who doesn't have a conjested internal
> network of their own, and be prepared to pay for it!
>
> Gordon
Stephane M wrote :
> Thanks guys for all this information...
>
> But I think about companies, which want to install a VoIP system....
> that seems to me not really suitable for companies..
>
> you can't ask people to stop downloading while phoning :-)
No, however, you can have a separate connection for voice, or choose an
ISP that can prioritise your traffic for you.
Employing QoS locally won't achieve all that an ISP can by shaping your
traffic - after all, using your router to provide QoS does nothing for
your packets after they leave your router, if you know what I mean.
"Stephane M" <Stephane@M.com> wrote in message
news:461A9DBF.6020302@M.com...
> Gordon Henderson a écrit :
>> In article <evdfic$24c$1$8300dec7@news.demon.co.uk>,
>> Stephane M <Stephane@M.com> wrote:
>>> Hi Tim,
>>>
>>> Thanks for your feedback
>>>
>>> I am bit surprised that the QoS is not so good actually...
>>> Anyway...
>>>
>>> I thought that SIP was the protocol for all VoIP communications ? I
>>> mean, I thought that even the the Audio of the communciation, used this
>>> protocol... !?!
>>
>> SIP is the Session Initiation Protocol. It controls the signaling between
>> the end-points. It does authentication, sends the dial codes, and lets
>> each
>> end tell each other (to some extent) how to carry the call data between
>> each end-point.
>>
>>> Anyway, I found on ny phone, that RTP port is [ 16384 - 16482 ]
>>> So I added, on my QoS service..
>>>
>>> 1) Do you know which protocol is using RTP ? (TCP/IP ???)
>>
>> RTP is the protocol. (Realtime Transport Protocol) It's UDP.
>>
>> One issue you'll never be able to solve, no matter what router you use
>> is that once your data is out on the Internet you have absolutely zero
>> control over it.
>>
>> All you can effectively do at your end is control data leaving your
>> network. If you do large uploads, (data leaving your network) then you
>> can prioritise your VoIP traffic over this.
>>
>> However one thing you can't do is prioritise incoming VoIP traffic over
>> any other incoming traffic, and the reason for this is simple - by the
>> time you get the packet and decide to delay it (if it's not a VoIP
>> packet)
>> it's too late. That packet has already come over the wire. There are
>> tricks that can help, but you can never successfully prioritise incoming
>> traffic, especially stuff with real-time contraints.
>>
>> So if you are having issues, the best thing to do is simply shut down
>> all traffic when making calls. Not much help when a call comes in though,
>> and once on the 'net, it's anyones guess what'll happen to the packets,
>> so make sure you use a decent ISP who doesn't have a conjested internal
>> network of their own, and be prepared to pay for it!
>>
>> Gordon> Thanks guys for all this information...
>
> But I think about companies, which want to install a VoIP system....
> that seems to me not really suitable for companies..
>
> you can't ask people to stop downloading while phoning :-)
>
> So, I can't really see any possibility for professional use... Seems to be
> a bit dodgy !??
>
> I installed in the company an FVX538, thinking that I would be able to use
> VoIP systems...
>
> So, the only solution would be the CTX1000 ???
>
> Stephane
>
VoIP by design has multiple potential failure points and at best can only
equal conventional switched circuit telephony for reliability.
That said, I have found it to be reliable enough for a home environment,
whilst being cheaper and with better features. I would estimate that for me
it has been much more reliable than a mobile and that is all I need.
Depends what you're after I suppose, but the reliability would have to be
addressed in a business environment. Increased redundant/reserved bandwidth
solves some of the issues plus a commercial grade QoS system. But this is
only half the story.
Stephane M wrote:
>
> But I think about companies, which want to install a VoIP system....
> that seems to me not really suitable for companies..
If you do it right, then you are ok.
We don't use any normal phoneline for voice in the office. We use
analogue lines for outbound fax and the PDQ machine, but all voice comms
goes over VoIP.
It works really really well.
But
1) we use a really good ISP
2) All our internal cabling and such is very good
3) We use good quality phones
4) We have a CTX1000 [1]
5) The network is well managed - nobody uses bittorrent, skype or othe
network unfriendly applications.... during working hours.
6) We are near to the phone exchange. We use an AR7 chipset based ADSL
router, which we think are the best at holding up the line. We use
quality faceplate ADSL filters. So our ADSL holds up really well.
7) We use a good quality SIP service provider for our inbound numbers.
We have between 5 and 7 people in the office, using it all the time.
For business phonecalls.
If we didn't use VoIP, then we'd be paying BT for 3 or 4 ISDN2e lines.
Not cheap. Also we would have a different phonenumber - we moved and
took our numbers to VoIP.
> you can't ask people to stop downloading while phoning :-)
You can't.
> So, I can't really see any possibility for professional use... Seems to
> be a bit dodgy !??
Not true.
> I installed in the company an FVX538, thinking that I would be able to
> use VoIP systems...
Maybe not.
> So, the only solution would be the CTX1000 ???
Maybe.
As others have said, you a device on the inbound side of a WAN link does
have limited scope for providing QoS.
But, if you assume that most inbound traffic is TCP. That can be slowed
down by delaying the ACK's, sending ECN or plain dropping packets.
Also, with an ADSL connection the download is in the VoIP's favour.
There is much more download bandwidth than upload. Less chance the
download will be saturated.
In article <461A9DBF.6020302@M.com>, Stephane M <Stephane@M.com> wrote:
>Thanks guys for all this information...
>
>But I think about companies, which want to install a VoIP system....
>that seems to me not really suitable for companies..
>
>you can't ask people to stop downloading while phoning :-)
>
>So, I can't really see any possibility for professional use... Seems to
>be a bit dodgy !??
Yup.
But it all depends on how critical you feel that phone calls to your
business is. I don't think that there is any VoIP solution right now
that's as reliable as a BT socket on the wall, although you can get damn
close to it, and I know many people (including my self!) who do use VoIP
in a day to day business situation (and I sell it too, so while I want
it to work, I do let my clients know the limitations, as I see them)
The best solution at present (as far as I'm aware!) is a separate ADSL
line to a reputable ISP. (I use Zen) Be prepared to pay for it, and
if-possible, get a "business" line - ie. 20:1 contnetion inside the
network. Ask the ISP what their internal network contention is.
This can work out cheaper than an ISDN-30, while supporting up to 8
calls at g711 rates, or more than double that at GSM rates.
"Stephane M" <Stephane@M.com> wrote in message
news:461A9DBF.6020302@M.com...
> Thanks guys for all this information...
>
> But I think about companies, which want to install a VoIP system....
> that seems to me not really suitable for companies..
you are assuming that the VoIP traffic is for everything - there are lots of
variations.
there are IP Telephony / Voip systems out there that only use IP across a
LAN, and / or use a corporate WAN where QoS can be imposed across all
traffic with a central voice gateway.
And some telcos (not necessarily ISPs) will provide voice "trunks" via IP -
sort of gateway in the carrier core network.
>
> you can't ask people to stop downloading while phoning :-)
No - but you can design the combined network so it doesnt matter.
>
> So, I can't really see any possibility for professional use... Seems to
> be a bit dodgy !??
i have worked on IPT / voip systems for big call centres with several 100
users
it works really well, and is more flexible in some ways than a conventional
phone system (or they wouldnt have put it in....)
>
> I installed in the company an FVX538, thinking that I would be able to
> use VoIP systems...
>
> So, the only solution would be the CTX1000 ???
the issue is not what kit you use, but that incoming voice packets didnt get
"high priority / low delay / low jitter" treatment on their way to you.
Nothing you do to outbound traffic can completely solve that, although a few
of the workarounds suggested might improve your case.
Even then if something out there is flooding packets at your router, nothing
you do will turn off the inbound traffic, so any voice or other traffic you
do want to come in will struggle.
>
> Stephane
>
> Gordon Henderson a écrit :
> > In article <evdfic$24c$1$8300dec7@news.demon.co.uk>,
> > Stephane M <Stephane@M.com> wrote:
> >> Hi Tim,
> >>
> >> Thanks for your feedback
> >>
> >> I am bit surprised that the QoS is not so good actually...
> >> Anyway...
> >>
> >> I thought that SIP was the protocol for all VoIP communications ? I
> >> mean, I thought that even the the Audio of the communciation, used this
> >> protocol... !?!
> >
> > SIP is the Session Initiation Protocol. It controls the signaling
between
> > the end-points. It does authentication, sends the dial codes, and lets
each
> > end tell each other (to some extent) how to carry the call data between
> > each end-point.
> >
> >> Anyway, I found on ny phone, that RTP port is [ 16384 - 16482 ]
> >> So I added, on my QoS service..
> >>
> >> 1) Do you know which protocol is using RTP ? (TCP/IP ???)
> >
> > RTP is the protocol. (Realtime Transport Protocol) It's UDP.
> >
> > One issue you'll never be able to solve, no matter what router you use
> > is that once your data is out on the Internet you have absolutely zero
> > control over it.
> >
> > All you can effectively do at your end is control data leaving your
> > network. If you do large uploads, (data leaving your network) then you
> > can prioritise your VoIP traffic over this.
> >
> > However one thing you can't do is prioritise incoming VoIP traffic over
> > any other incoming traffic, and the reason for this is simple - by the
> > time you get the packet and decide to delay it (if it's not a VoIP
packet)
> > it's too late. That packet has already come over the wire. There are
> > tricks that can help, but you can never successfully prioritise incoming
> > traffic, especially stuff with real-time contraints.
> >
> > So if you are having issues, the best thing to do is simply shut down
> > all traffic when making calls. Not much help when a call comes in
though,
> > and once on the 'net, it's anyones guess what'll happen to the packets,
> > so make sure you use a decent ISP who doesn't have a conjested internal
> > network of their own, and be prepared to pay for it!
> >
> > Gordon
--
Regards
> Thanks guys for all this information...
>
> But I think about companies, which want to install a VoIP system....
> that seems to me not really suitable for companies..
It Depends. What are you intending to use VoIP for? Trunks or handsets? VoIP
handsets happily share a LAN with a few PCs, and for more complex
environments you can use VLANs to get what you want.
> you can't ask people to stop downloading while phoning :-)
You can't, but then if your VoIP is running over ADSL in the UK, lack of
downstream bandwidth is unlikely to be an issue - it's more likely to be
lack of upsteam bandwidth. And egress is a lot easier to control than
ingress.
> So, I can't really see any possibility for professional use... Seems to
> be a bit dodgy !??
It'll only be as good as the quality of the connection, and the amount of
available bandwidth. As others have mentioned, SIP+RTP uses a variety of
ports so it can be a bit of a fuck on to get it set up right. You might
find it easiest to prioritise traffic from specific hosts [ie your
handsets] over everything else.
> I installed in the company an FVX538, thinking that I would be able to
> use VoIP systems...
If you're using VoIP to save costs, then you're going to need to make a lot
of calls to save £200!
> So, the only solution would be the CTX1000 ???
There are probably others. You could get a dedicated DSL circuit at each end
for VoIP trunks, which would make some kind of sense given that you've got
a dual-WAN firewall. But of course that may well eliminate any cost
benefits of using VoIP.
--
<http://ale.cx/> (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
20:50:59 up 2 days, 7:09, 2 users, load average: 1.73, 1.32, 0.97
Yes. I'm just guessing.
On Apr 9, 9:48 pm, Stephane M <Steph...@M.com> wrote:
> I gave high priority to my SIP protocol....
> But I still have some troubles, when I am on the phone and I am sending
> an email (for instance)
On Mon, 09 Apr 2007 20:33:09 GMT, Herman wrote:
> VoIP by design has multiple potential failure points and at best can only
> equal conventional switched circuit telephony for reliability.
Errr .. no.
If Company X has a telephone service which is provided by one PRI into their
offices and the line is cut, their phone is dead.
If Company X uses VoIP and multihomes their internet connection across several
circuits, then their connection to the telco could stay up unless they lose
all of their circuits.
--
rgds, Andy Davidson Freelance keyboard jockey www.andyd.net
QoS Service ... does it really work ?? 
Linear Mode
