DSCP marking

[GoogleCodeExporter]

Would have been really nice to mark packets with proper DSCP values. I think 
this will also help the VoIP quality over modern networks.

Original issue reported on code.google.com by lefteri...@gmail.com on 3 Nov 2010 at 5:26

[GoogleCodeExporter]

Ok,
It's probably already supported by pjsip. Don't know if it's the default value 
and don't remember if I've ported it to android (and if it's possible using 
android ndk features).
But open point.. I'll check that.

Thanks for pointing it out.

Original comment by r3gis...@gmail.com on 3 Nov 2010 at 7:47

• Changed state: Accepted

[GoogleCodeExporter]

Well, good news : that's supported by android NDK, and that's just a flag to 
turn on in pjsip to activate it (I've just built with this flag and no compiler 
error, hooray :D).
Then I'll have to add settings to activate qos in the android UI and it 
~should~ work then ;)

Original comment by r3gis...@gmail.com on 3 Nov 2010 at 11:09

• Changed state: Started

[GoogleCodeExporter]

Thank you!!! That was damn fast! :D

Original comment by lefteri...@gmail.com on 3 Nov 2010 at 12:10

[GoogleCodeExporter]

It's not yet in the trunk... but I'll push that ASAP :). I'll keep you in touch 
here when a dev build will be available to test this feature.

Maybe I could be envisaged to activate QoS by default. What do you think?
I don't know exactly what is the impact on network and on call quality (I'm not 
an IP specialist). I guess that it improves things but is there any 
inconvenient that could lead to turn this feature off by default?

Original comment by r3gis...@gmail.com on 3 Nov 2010 at 12:51

[GoogleCodeExporter]

Yes, I was thinking to tell you exactly that. There is no harm done whatsoever 
by having DSCP always on. The only thing that may change is the DSCP value as 
some companies have used different default values.

Original comment by lefteri...@gmail.com on 3 Nov 2010 at 1:08

[GoogleCodeExporter]

Actually, I don't think there is any need at all to add an option to the UI 
having QoS on or off as much as what the DSCP value should be, if you do have 
an option to change it of course.

Original comment by lefteri...@gmail.com on 3 Nov 2010 at 1:17

[GoogleCodeExporter]

Ok, so I'll activate this by default.
I'll add two options (for power users, so hidden by default unless user switch 
to expert setting mode) :
One to disable qos
One to change the value of DSCP (default will be 24 (0x18) which seems to 
correspond to DSCP CS3).

Original comment by r3gis...@gmail.com on 3 Nov 2010 at 1:40

[GoogleCodeExporter]

I am not sure how android's implementation is, but the default DSCP value for 
RTP packets should be 46 (all 6 bits set DS5-DS0) and for control packets 
should be 26 (wherever that is possible of course). CS3 (24) is not entirely 
correct.

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949
f2.shtml

Original comment by lefteri...@gmail.com on 3 Nov 2010 at 4:47

[GoogleCodeExporter]

First build with QOS is available : 0.00-15-10.
I forgot to change 24 to 26 as you advised in your previous comment, but you 
can do it by hand in advanced settings. I'm doing that right now in the code so 
that will be fine with next versions.

Let me know how it goes.

Original comment by r3gis...@gmail.com on 6 Nov 2010 at 4:36

• Changed state: Fixed

[GoogleCodeExporter]

I have just tested it and the QoS enable/disable works as it should. However, 
no matter what I used as a DSCP value, it did not change anything at all in the 
packets. The RTP packets were always 48 and control packets always 24. The RTP 
packets are the most important ones since they carry the voice. Control packets 
are secondary in importance. I suspect the value of 24 (CS3) that you have 
previously mentioned is used for the control packets only and not for the RTP 
ones. I think there should be 2 DSCP values, one for the RTP packets, and one 
for the signaling that you probably already have. Can you change both of these 
values with the Android NDK though?

Original comment by lefteri...@gmail.com on 6 Nov 2010 at 10:16

[GoogleCodeExporter]

As for RTP packets that's managed by the sip stack. I guess they put 48 for 
voice packets.
https://trac.pjsip.org/repos/wiki/QoS 
On my side I simply use PJ_QOS_TYPE_VOICE 
(https://trac.pjsip.org/repos/wiki/QoS#Design) for RTP packets. That's the 
level of the API I can play with. I could go further inside the SIP stack, but 
I resent in doing that cause forking the stack code means painful merges 
between their improvements and CSipSimple branch.

So as for RTP packet, maybe I could add an option to switch between type VIDEO 
(0x28 - that's what you advised me previously), VOICE (0x30) & type CONTROL 
(0x38). 
Do you think it would be enough or it would be better to have a finer control 
on the actual DSCP value for RTP packets?

Tagging with 24 SIP packets is done on all their example, that's the reason why 
I used for my first proposition.But you look like more an expert than pjsip 
devs on QoS stuff ;), reason why I'll adopt your proposition of 26.

I'll check why it doesn't take into account DSCP changes on my side.
Let me know if the setting for RTP should be enough and if it's important to 
set default RTP DSCP value to what pjsip stack call video (0x28) instead of 
audio (0x30)

Original comment by r3gis...@gmail.com on 6 Nov 2010 at 10:41

• Changed state: Started

[GoogleCodeExporter]

Keep it simple then. Avoid those painful merges and just leave it as is with 
simply a QoS on/off choice. Personally I am already happy that packets have 
some DSCP flags turned on, even with other values I do not use in my networks. 
It sounds a lot easier to me to simply, as a network admin, add a couple of 
lines and reclassify or change the RTP packets. If the sip stack doesn't give 
you an easy way to change RTP packets, then don't do it. From what you describe 
me it looks like pjsip's job to do that part. Leave it at 48 but their value is 
not a widely used one. It basically classifies the packets as internetwork 
control packets and I am not very sure why would their implementation have it 
like that. The DSCP value of 46 (0x2E) or also known as EF (Expedited 
Forwarding - RFC2598) or 184 (0xB8 as a full byte cisco-linksys/asterisk) if 
you prefer, is the one that warranties low jitter, low loss, low latency with 
guaranteed bandwidth which is exactly what you want for voice traffic and that 
is definitely the recommended one. I wouldn't recommend switching between Video 
and Voice as Video is another story and I am not sure I ever advised that. 
Video is of lower priority than Voice and you definitely don't want that for 
Voice packets.

As for the SIP/control packets, the difference between 24 and 26, is the drop 
probability. 26 has the lowest drop probability while 24 has a medium drop 
probability and again, you don't exactly care for a SIP/control packet when it 
will get there, as much as it _should_ get there and setting DSCP to 26 gives 
the packet a better chance than 24 to get there without getting lost somewhere 
in between.

QoS could be a bit confusing and as I already mentioned, not every one has to 
follow the same approach. I have googled a really nice doc about QoS. You may 
want to have a look at it specially at part 2 - Marking and Classifying.

http://www.rhyshaden.com/qos.htm

To sum it up, the ultimate approach would be to have two choices for the DSCP 
values, one for RTP packets and another second one for SIP/control packets. 
That way, you can adopt the app to any network setup you want. HOWEVER, I 
highly suspect it should be done through pjsip.

Hint: If both DSCP values are set to 0, it is the exact same thing as QoS set 
to off.

Original comment by lefteri...@gmail.com on 7 Nov 2010 at 1:52

[GoogleCodeExporter]

Thx a lot for all these precisions!

Indeed you're right for RTP packets that's done by pjsip stack. I was talking 
about audio and video type because that are the "type" the high level api allow 
me to set for RTP packets (for SIP control packets, I have to set the DSCP 
value).

I think that they give this high level API cause pjsip also support WMM & IEEE 
802.1p. In our case WMM is not supported and ieee is useless (unless maybe for 
some future wired android tablet...)

So I think that for now, I'll see what is going wrong for DSCP setting for SIP 
packets and change the label to precise that it applies to SIP packets and not 
to RTP ones - of course if the setting I try to change actually do something :) 
- else I'll remove the setting of DSCP value and ask on pjsip mailing list to 
see if they have any clue on that point.

Original comment by r3gis...@gmail.com on 7 Nov 2010 at 11:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

WMM is supported by Access points though. Even better, some modern WiFi 
chipsets (like Atheros for example) have hardware classification support for 
WMM/DSCP which is a very good thing for DSCP marked voice traffic!

In any case, if you need any further help with testing just let me know.

Original comment by lefteri...@gmail.com on 7 Nov 2010 at 7:47

[GoogleCodeExporter]

One more last addition to make, due to the fact that different VoIP providers 
may use different DSCP values, it may be a good idea to set each account 
separately.

Original comment by lefteri...@gmail.com on 9 Nov 2010 at 1:44

[GoogleCodeExporter]

Problem of WMM is that it's not supported by android NDK, not by AP ;).

As for one DSCP by account, unfortunately, not easy using pjsip. 
We could create different transport, but the configuration of CSipSimple will 
give headache to users. 
Actually in pjsip transports and accounts are two different things, and 
accounts use transport when they want to send something. We can attach a 
account to a transport or let the stack choose the best transport for what we 
are trying to do.

In order to keep thing simple I only create an UDP, a TCP (and in the future a 
TLS) transport, that all accounts can use.
I think that making one transport by account would be over-engineering for 
99,9% of users.
Not only most users have only one account, but allowing to customize this kind 
of stuff by account would be extremely difficult to understand for mainstream 
users.

As for DSCP value for control packets, I've change default value from 24 to 26. 
For RTP DSCP marking, I think that I'll not change the value since it would 
mean to modify the pjsip library (which I try to do as less as possible).

Original comment by r3gis...@gmail.com on 13 Nov 2010 at 5:43

• Changed state: NextRelease

[GoogleCodeExporter]

I think it already is good enough for now. What I am really surprised is that 
pjsip doesn't make it as easy for you to change the RTP value as change the SIP 
one.

Original comment by lefteri...@gmail.com on 13 Nov 2010 at 6:07

[GoogleCodeExporter]

I'd like to run CSipSimple on an Android phone that uses wifi over meshnet 
radios.  The radios use an odd ball DSCP value (0xB8) to assign low delay and 
high throughput.  Is there anyway I can configure CSipSimple to use this value 
for both RTP and session initiation IP packets?

Original comment by Lou.F...@gmail.com on 23 Jun 2011 at 1:30

[GoogleCodeExporter]

I'd like just to share information of what I tested and observed about DSCP and 
WMM values.
This is not a truly defective issue but could be a handset issue, but it is 
interesting.

Just take a look at WMM access category.
https://docs.google.com/spreadsheet/ccc?key=0AvKYNIIWvvX3dGNWNldwMFFNaC1YUXhMQnB
yOXZZa3c

AF*1 value gives the Background access category for WMM... The current default 
DSCP value 26 gives the lowest access category instead of Best Effort for WMM 
function.
I changed it to 24. 

Cellphone
1.LG Optimus One (Model No.:LG-P500h) with Android 2.3.3.
2.CSipSimple version is 0.03-01 r1108

If anyone can monitor 802.11 frames and has another smartphone, please test 
this and let me know the result.

Thanks.

Original comment by luca_...@yahoo.co.jp on 28 Jan 2012 at 5:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

 - Have you a link to the RFC corresponding?
On my side I use those provided by default by pjsip (see 
http://trac.pjsip.org/repos/wiki/QoS )
Where in public it's specified that the value from cisco are the good one ? A 
standard is not something that is specified by only one manufacturer. This was 
the conception of Internet Exporer in the past. The real standards are those 
from W3C. Here it goes the same with SIP. Something implemented by one 
manufacturer is *never* a standard. A standard is something proposed to the 
rest of the world and then adopted and formalized by a third party community 
(such as IETF, ISO etc).
For now what I know of this TOS value : it is highly dependent on the equipment 
manufacturer and no one behaves the same way. (cisco, linsys, snom, aastra, 
grandstream... I just did a new search on google and found this one : 
http://kb.smartvox.co.uk/ip-phones/sip-configuration/voip-qos-settings-part-2/ )

 - You *CAN* configure the *values* you want in CSipSimple settings :D. It's already available since a while ;).
Just go in expert setting mode (see 
http://code.google.com/p/csipsimple/wiki/ExpertSettingMode?wl=en). You can 
configure the SIP DSCP marking val and in account settings the per account RTP 
DSCP value.
No need to full restart csipsimple. Just enable the settings and set the values 
you wish; go out from the setting and it will be applied. If you notice it's 
not applied, check that you enabled QoS in settings, and send me wireshark + 
logs from the app (see HowToCollectLogs wiki page)

Original comment by r3gis...@gmail.com on 25 Feb 2013 at 5:24

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the details.

For the DSCP SIP value, it's just to revert to initial value that was present 
before comment #12 here. Can you review comment #12 from lefterists here (that 
I consider as the reference post here because explains well things) and tell me 
if it makes sense to you too ?
If so, and if I correctly understand the post, I should leave value 26 instead 
of 24 by default as ensures better packets will not be lost somewhere.

For the DSCP RTP value, after reviewing the code, there is indeed a problem, 
the default get the value from control layer values. 
I'll fix that right now to use 184.
Just one thing I'm puzzled with : in your comment I see decimal:46 (in hexa 
46=0x2E) hexa:0xb8 (which gives me in decimal 184).
As your comment mixes the two values I'm a little bit confused on what you 
advise as default value exactly. In comment 12 (that mention the two values) it 
is more clear about the purpose of these values and (again if I correctly 
understand) I would say the good one is 184 (0xb8). Does that make sense for 
you too?

Original comment by r3gis...@gmail.com on 25 Feb 2013 at 9:45

[GoogleCodeExporter]

You can see my doc 
https://docs.google.com/spreadsheet/ccc?key=0AvKYNIIWvvX3dGNWNldwMFFNaC1YUXhMQnB
yOXZZa3c
You can ignore the column I to K as they are L2 QoS.

ToS and DSCP are different as ToS uses all 8 bits in the header field and DSCP 
uses only the first 6 bits of it and ignore the rest of 2 bits.

General priority(0-7) is defined by only first 3 bits, and more specific 
priority for each priority is graded into 3 drop probabilities from Low to High 
by 3 bits from 4th bit to 6th bit.

So, if you talk about DSCP, you should pick up first 6bits, in this case it is 
"10 1110", which is 46 in decimal.
If you talk about ToS, it's "1011 10xx" that is 184 if you put 00 in the end.

Original comment by luca_...@yahoo.co.jp on 25 Feb 2013 at 10:37

[GoogleCodeExporter]

Ok !! Understood ! Thanks a lot for doc it helped me a lot to understand.

Original comment by r3gis...@gmail.com on 25 Feb 2013 at 11:10