[Asterisk-Users] SIP audio port usage

[Rich Adamson]

> So the more reliable way to do QoS is with MAC adress and not on a port basis.
> Am I right ?
> 
> Thanks for your help,
> 
> Adrien
> 
> On 9/19/05, Rich Adamson <radamson at routers.com> wrote:
> >
> > > I know that SIP is using port 5060 for session initiation, but which port
> > > does it use for audio ? is it dynamically assigned ?
> >
> > Its dynamically assigned on a per-call basis.
> >
> > Asterisk assigns the port based on contents of rtp.conf.
> >
> > Remote sip phones assign port numbers based on whatever the manufacturer
> > happened to choose (no industry standard). E.g., Cisco uses 32,768 to
> > something around 40,000, while xlite uses something in the area of 8,000.
> > The various manufacturers are not consistent at all.

A very common way of handling QoS is to rely on the TOS (Type of Service)
bits located in the IP header. Those bits are set in asterisk packets 
via a statement like:
 tos=lowdelay
in sip.conf and iax.conf.

There are similar type parameters available in most quality sip phones.

However, once the bits are set properly, its then up to your router and/or
switch to queue the packets properly for transmission over the network.

The majority of the soho routers and switches do not have code to
actually handle that queuing, and even if you have a device that does
properly handle it, the prioritization of the packets is "outbound"
traffic only. Your internet service provider would have to do something
to prioritize the inbound traffic to you, and most won't do that. In addition,
the majority of the backbone Internet providers don't pay any attention
to any QoS settings.

The QoS parameters work very nicely in corporate networks where support
personnel understand the concepts and monitor their resources, but isp's
and itsp's generally don't have a clue (or don't care).

There are other software packages that will help prioritize packets
to/from the Internet, and most of them use some form of trickery to
accomplish the goal. For example, outbound http packets are delayed allowing 
rtp packets to be sent without delay, resulting in a form of QoS. By delaying
the http packets (sent outbound), the remote web server essentially is
placed in a wait state causing it not to forward any packets to your 
site, resulting in a form of inbound QoS.

Those types of QoS will not handle streaming packets such as those
associated with listening to music or watching videos. 

For the most part, QoS across the Internet (regardless of whose equipment
you use) is not very effective today since the majority of isp's and
backbone suppliers have not implemented QoS. As one example, you could
have the most expensive Cisco router on your end with properly implemented
QoS prioritization, but if I sent a large number of icmp or other fake
packets to your IP address, I'd consume all available bandwidth leaving
your rtp packets no way to reach your site reliably.

For home and small offices that rely on DSL type facilities, implementing
QoS can improve the quality as generally the outbound bandwidth is
significantly less then inbound bandwidth. In those cases, prioritizing
outbound traffic (on the low bandwidth portion) may help, but it still
won't do much for inbound traffic.

The exact same issues apply regardless of whether you rely on the TOS
bits or MAC address method of prioritizing traffic. The TOS bits just
happens to be a far more common method.