[asterisk-dev] [IAX] Separate QoS settings for signaling, voice and video packets

[Yousf Ateya]

IAX over one socket/port is a killer feature; Changing it is really hard.

I was thinking about changing qos on-fly. something like this:

if( is_control_packet && current_tos_is_not_high) setsockop(high_priority)
>
if( is_voice_packet && current_tos_is_high) setsockop(low_priority)
>
ast_sendto()
>

Don't know what is the long term effects of calling setsockopt many (really
many) times. I tried it for small application and it worked without
problems (untill now!).
Also I tried a mock up with this modification on a test setup. It gave more
stable connection on congested Internet connection (better delivery chance
for control packets).

My change in IAX was in transmit_trunk function (in chan_iax2.c). Change it
to be like this:


static int transmit_trunk(struct iax_frame *f, struct ast_sockaddr *addr,
> int sockfd)
> {
>     int res;
>
>
>     int tos_before=0,cos_before=0, tos, cos;
>     socklen_t toslen=sizeof(tos), coslen=sizeof(cos);
>     //tos and cos are already set to 184 and 5 (in iax.conf tos=ef and
> cos=5)
>     getsockopt(sockfd, IPPROTO_IP, IP_TOS,  &tos_before, &toslen);
>     getsockopt(sockfd, SOL_SOCKET, SO_PRIORITY, &cos_before, &coslen);
>
>     //lower tos and cos
>     tos = 160;
>     cos = 3;
>
>     setsockopt(sockfd, IPPROTO_IP, IP_TOS,  &tos, toslen);
>     setsockopt(sockfd, SOL_SOCKET, SO_PRIORITY, &cos, coslen);
>
>     res = ast_sendto(sockfd, f->data, f->datalen, 0, addr);
>     //return them to initial value
>
    setsockopt(sockfd, IPPROTO_IP, IP_TOS,  &tos_before, toslen);
>     setsockopt(sockfd, SOL_SOCKET, SO_PRIORITY, &cos_before, coslen);
>
>     if (res < 0) {
>         ast_debug(1, "Received error: %s\n", strerror(errno));
>         handle_error();
>     } else
>         res = 0;
>     return res;
> }
>


My trials was on recent Ubuntu on modern computers  (not windows, not
ancient OS). One IAX client, trunked connection with 100 concurrent calls.
NOTE: code is not multi-threading protected and calling
getsockopt/setsockopt  shall be removed in production code.


Is there any measurements to ensure that this doesn't break something else?
(increase CPU load insanely, doesn't scale up after x connections, ...)

I have a running test setup with this mockup if you need some debug logs.


On Sun, Mar 8, 2015 at 6:34 PM, Matthew Jordan <mjordan at digium.com> wrote:

>
> On Thu, Mar 5, 2015 at 5:27 AM, Yousf Ateya <y.ateya at starkbits.com> wrote:
>
> Asterisk provides a way to set tos and cos fields
>> <https://wiki.asterisk.org/wiki/display/AST/IP+Quality+of+Service> in IP
>> headers. But as stated in documentation:
>>
>> Since IAX connections combine signalling, audio, and video into one UDP
>> stream, it is not possible to set the TOS separately for the different
>> types of traffic
>>
>> So the packet priority is assigned to signaling, voice and video; which
>> minimizes the benefit of having packet priority.
>>
>> If there are separate settings for signaling and voice, users can
>> increase priority of signaling; to ensure that control packets get better
>> chance than voice packets.
>>
>
> The issue isn't that the settings for signalling and voice are combined,
> it is that signalling and voice information are multiplexed over a single
> socket. These quality settings are set on the socket that services both
> signalling and media; changing them on the fly between frames on a single
> socket would probably have "interesting" effects. Keep in mind that the
> settings determine the priority of packets being sent from the socket.
> Given how often signalling and media can change on a single socket for a
> number of chan_iax2 channels, you would defeat the purpose of setting
> TOS/COS if you changed them frequently.
>
> The only way you could overcome that would be to break apart the
> signalling and media onto different sockets. That has several drawbacks:
> (1) One of IAX2's strengths is its ability to pass media and signalling
> over a single port, which helps with NAT/firewalls
> (2) It would make chan_iax2 no longer compliant with its own RFC
> (3) It would certainly be a non-trivial amount of work. Since chan_iax2
> can really only be tested against itself, it makes verifying that such a
> change does not inject a large amount of risk into the driver rather
> difficult.
>
> --
> Matthew Jordan
> Digium, Inc. | Director of Technology
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
Yousf Ateya,
StarkBits
www.starkbits.com

-- 


This e-mail message is intended only for the use of the intended recipient(s).
The information contained therein may be confidential or privileged,
and its disclosure or reproduction is strictly prohibited.
If you are not the intended recipient, please return it immediately to its sender 
at the above address and destroy it. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150309/0f348b8f/attachment.html>