Closed GoogleCodeExporter closed 9 years ago
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
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
Thank you!!! That was damn fast! :D
Original comment by lefteri...@gmail.com
on 3 Nov 2010 at 12:10
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
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
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
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
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
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
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
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
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
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
[deleted comment]
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
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
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
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
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
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
[deleted comment]
- 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
[deleted comment]
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
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
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
Original issue reported on code.google.com by
lefteri...@gmail.com
on 3 Nov 2010 at 5:26