Development access

[Moc]

Hi,

I'm working to improve the Rtp stack so call work with multiple call
platform (Recent changes I've made allowed it to follow correct
timestamp and made it work with FreeSwitch, and Im guessing will fix
it for multiple other SIP client/server).

So I'm looking at getting SVN commit access so I can commit and
improve on this project. There is alot of stuff to be done, but it
show great potential to use android as a sip softphone client.

thanks

Marc O. Chouinard

[Pascal Merle]

Please give some more details about your changes here (could include
the most important lines of code, too). If they are approved you get a
member. Thanks!

[Moc]

Most of my changes rightnow are in sipdroid/media/RtpStreamSender.java
the biggest issue was how the time and sample was calculated. For
example time was increased based on the size it was read of the PCM16
stream, so in this case, double of what time is suposed to be. Second
it didn't use the frame_size value as the timing (Will have to be
changed at multiple place to reflect the real type of value).

The part that I've ripped out is the 10 buffer input rotation defined
with : (ring+delay)%(frame_size*10). Is there an actual reason why
this is there, also delay is always set to 0, and I don't see what use
it is to actually add force delay.

Used AudioRecord.getMinBufferSize(8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT) instead of the hard coded value of
6144 for the PCM read buffer.

So rightnow, the change I made follow the frame_size set in
UserAgentProfile.java. So normally is 20ms and has to be 20ms UNLESS
we provide a ptime value in the SDP media (I couldn't figure out how
to do this correctly yet). If not some rtp stack will reject the
audio.

Things I have to do, create a configuration menu for Codec, to be able
to select ALAW/ULAW frame_size (20ms,30ms...), if possible add a low
bitrate codec (I saw some GSM java stack, never touch them), also add
support for other hz frequency for support of G722 or other codec. I
got issue with hangup not been detected and incoming call that doesn't
seem to work. Also I couldn't get video to work between my Polycom
VVX 1500 phones, so it something I want to try to get working.

Let me know if you need anything else. For the moment, I would commit
the basic fix, and work after on getting those codec menus (I've never
played with menu yet)...

Marc O.

[Pascal Merle]

Most of your changes cannot pass into the code.

1) AudioRecord.read returns the size in shorts. So it's right, not
twice as much.

2) A delay > 0 was introduced to get video and audio in sync.

3) Frames are 1024 samples because otherwise you get terrible jitter
in the packets.

4) Low bitrate and wideband codecs cannot be run in Java on Android
because such implementations would be too slow.

The only change I have made to the source based on your findings is
obeying the MinBufferSize. The value chosen was already bigger than
MinBufferSize on the G1 but better to be on the safe side for future
devices. Thanks!

I will stay tuned on your test results with the Polycoms or other
ideas you get for development.

[bkw]

On Jun 18, 3:51 pm, Pascal Merle <pmerl...@googlemail.com> wrote:
> Most of your changes cannot pass into the code.
>
> 1) AudioRecord.read returns the size in shorts. So it's right, not
> twice as much.
>
> 2) A delay > 0 was introduced to get video and audio in sync.
>
> 3) Frames are 1024 samples because otherwise you get terrible jitter
> in the packets.

Are you sending 1024 samples? from what Moc has said you're not, he
changes it to 160 and it sounds fine. If you're sending 1024 its 100%
WRONG you should be sending multiples of 10ms. If you wish to keep
doing this then you should increment your timestamps by 960 and
include 960 samples and with ulaw or alaw thats 960 bytes of data. If
you get jitter then you should implement a jitter buffer with smaller
20ms packets and stop sending these insanely large packets. You
should also put the a=ptime value in the SDP if you're doing a non-
standard. Either case it should be configurable. 128ms audio packets
do not work.

> 4) Low bitrate and wideband codecs cannot be run in Java on Android
> because such implementations would be too slow.

Isn't there a speex codec in java?

> The only change I have made to the source based on your findings is
> obeying the MinBufferSize. The value chosen was already bigger than
> MinBufferSize on the G1 but better to be on the safe side for future
> devices. Thanks!
>
> I will stay tuned on your test results with the Polycoms or other
> ideas you get for development.

I would highly recommend you make these options configurable. Your
device will NOT interop unless you do multiples of 10.

/b

[Pascal Merle]

According to RFC 1890 4.2 Guidelines for Sample-Based Audio Encodings:
An RTP audio packet may contain any number of audio samples, ... The
duration of an audio packet is determined by the number of samples in
the packet.

What you are proposing here is only valid for Frame-Based Audio
Encodings which G.711 is not.

I don't mind accepting a change for configurable payload lengths if
the resulting jitter is compensated for.

[Brian West]

You can continue to do it the way you're doing and never interop with
real world implementations. The RFC says one thing... then you have
the real world. They don't meet at all in the middle.

What you're doing will not work in the real world. If you have jitter
then you need a jitter buffer or a better network. Sending larger
packets also results in greater audio distortion when you loose a
packet.

I'm speaking from real world development and deployment experience...
1024 samples will not work in MANY situations.

/b
FreeSWITCH.org

[Pascal Merle]

The RFCs are defining the SIP standard. That's what Sipdroid and PBXes
comply with and what the real world is. Tell me where it does not
meet, what your "real world" is.

I invite you to follow Moc changing the 1024 to 160 samples (it's just
one line) and test. You will find it does not improve at all.

[Brian West]

Only if you kill the daft 1024 samples per packet which will never work.

/b

On Jun 20, 2009, at 7:42 PM, Pascal Merle wrote:

>
> Sipdroid also seems to be running with your FreeSWITCH, see
> http://groups.google.com/group/sipdroid-users/browse_thread/thread/151856c09de0b5a3
> So I really don't understand your point regarding this code change.
> >

[Brian West]

Either way you clearly do not want to be compliant with anything
else. I'm done.

[Brian West]

On Jun 20, 2009, at 7:32 PM, Pascal Merle wrote:

>
> The RFCs are defining the SIP standard. That's what Sipdroid and PBXes
> comply with and what the real world is. Tell me where it does not
> meet, what your "real world" is.

RFC is funny. I'm telling you 1024 samples won't work everywhere...
Just ignore me thats fine.

>
>
> I invite you to follow Moc changing the 1024 to 160 samples (it's just
> one line) and test. You will find it does not improve at all.

Working vs not working at all is an improvement then yes.

/b

[Brian West]

That odd ticking could be the fact we only do 120ms MAX of ulaw ..
you're sending 128ms... so you have 8ms of clicking... again I would
fix it..

/b

[Pascal Merle]

One device has now been found that does not work with the 1024 samples
but does work with 160 samples (issue http://code.google.com/p/sipdroid/issues/detail?id=110#c3).
So adding an option for configurable payload lengths would really be
good.

Sorry that I thought this won't be an improvement when I asked you if
it really improves changing this number and how. In the meantime also
a native development kit (NDK) became available for Android to make
the suggested codec implementations possible.

Would you like to work on adding a configuration option, and also
continue the discussion on the codecs etc.?