gomac / sipdroid

Automatically exported from code.google.com/p/sipdroid
GNU General Public License v3.0
0 stars 0 forks source link

Nokia mobile phones cannot play ALAW codec transmitted by Sipdroid (or Android) #110

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Please do not label this bug as a duplicate or dismiss it before I have a
chance to clarify it to your liking and provide whatever additional
information you need.

--
What steps will reproduce the problem?
1. Register Nokia e61 or e51 SIP client (with userA) and Sipdroid (with
userB) to an Asterisk server locally. No NAT, no firewall, just direct
local IP addresses.
2. For both users, do: 
disallow=all
allow=alaw
3. Call using either SIP client (Nokia or Sipdroid) to the other one.

On the Asterisk server, sip show channels shows:

192.168.2.193 userA 1fa7dc7126b 00102/00000 0x8 (alaw) No Tx: ACK         

127.0.0.1     userB 22850632879 00101/00002 0x8 (alaw) No Rx: ACK         

So, it's clear that the two phones are communicating using the alaw codec.

----- What is the expected output? What do you see instead?

Sound is heard on the Sipdroid side, but no sound is heard on the Nokia.

----- What version of the product are you using? On what operating system?

Nokia e61 built-in SIP client with latest firmware
Nokia e51 built-in SIP client with latest firmware
Sipdroid 1.0.4

Please provide any additional information below.

To prove this is a codec incompatibility, I did the following:

1. Register Nokia SIP client (with userA) and Sipdroid (with userB) to an
Asterisk server locally. No NAT, no firewall, just direct local IP addresses.
2. For the Nokia user (userA), do: 
disallow=all
allow=ulaw

For Sipdroid user (userb), do:
disallow=all
allow=alaw

3. Call using either SIP client (Nokia or Sipdroid) to the other one.

Note that above, step (2) is different from before in that I am allowing
only ulaw codec for userA, and only ulaw codec for userB. This will force
the Asterisk server to transcode alaw to ulaw (and vice-versa), thus
forcing the Nokia and Sipdroid not to transmit raw data to each other directly.

After making a call this is what's seen on the Asterisk server:

192.168.2.193 userA 3e812fb904d 00102/00000 0x4 (ulaw) No Tx: ACK         

127.0.0.1     userB 29246818105 00101/00002 0x8 (alaw) No Rx: ACK         

The result is clear audio both ways. I can't find another explanation for
this other than Nokia not understanding the raw alaw data sent by Sipdroid.

This was reproduced with both Nokia e61 and e51.

I can provide any additional information required.

Original issue reported on code.google.com by iiordanov@gmail.com on 8 Aug 2009 at 7:24

GoogleCodeExporter commented 9 years ago
Check with Asterisk command "rtp debug" whether RTP packets pass through your 
Asterisk 
server in both scenarios.

Original comment by pmerl...@googlemail.com on 8 Aug 2009 at 7:38

GoogleCodeExporter commented 9 years ago
Thanks for looking into this!

The output looks different, which is probably because in the ALAW to ALAW case, 
the
Asterisk server is doing no transcoding.

I decided to throw in a third case, which is Nokia to Linphone, which is also 
ALAW to
ALAW, and works fine. See furthest below for that case. It looks like the Nokia 
ALAW
to Sipdroid ALAW case, but the *size of the packets is different*.

Below, 192.168.2.193 is the Nokia, and 192.168.2.161 is Sipdroid. Note the size 
of
the packets the Nokia is sending (1024) when it's talking to Sipdroid directly.
Sipdroid still replies with packets of size 160. 

On the other hand, when the Nokia is talking to Linphone, both it and Linphone 
are
sending packets of size 160. Could it be that due to some part of the 
negotiation, it
is expecting different size packets from Sipdroid?

======================================================================
Nokia ALAW to Sipdroid ALAW scenario:
............................
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 001024)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 001024)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 001024)
Sent RTP P2P packet to 192.168.2.161:21000 (type 08, len 000160)
............................

Nokia ULAW TO Sipdroid ALAW scenario:
............................
Got  RTP packet from    192.168.2.161:21000 (type 08, seq 000058, ts 059392, 
len 001024)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044781, ts 059384, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044782, ts 059544, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044783, ts 059704, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044784, ts 059864, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044785, ts 060024, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044786, ts 060184, 
len 000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027417, ts 634154064, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038902, ts 634154064, 
len
000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027418, ts 634154224, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038903, ts 634154224, 
len
000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027419, ts 634154384, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038904, ts 634154384, 
len
000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027420, ts 634154544, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038905, ts 634154544, 
len
000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027421, ts 634154704, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038906, ts 634154704, 
len
000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027422, ts 634154864, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038907, ts 634154864, 
len
000160)
Got  RTP packet from    192.168.2.161:21000 (type 08, seq 000059, ts 060416, 
len 001024)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044787, ts 060344, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044788, ts 060504, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044789, ts 060664, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044790, ts 060824, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044791, ts 060984, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044792, ts 061144, 
len 000160)
Sent RTP packet to      192.168.2.193:16384 (type 00, seq 044793, ts 061304, 
len 000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027423, ts 634155024, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038908, ts 634155024, 
len
000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027424, ts 634155184, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038909, ts 634155184, 
len
000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027425, ts 634155344, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038910, ts 634155344, 
len
000160)
Got  RTP packet from    192.168.2.193:16384 (type 00, seq 027426, ts 634155504, 
len
000160)
Sent RTP packet to      192.168.2.161:21000 (type 08, seq 038911, ts 634155504, 
len
000160)
............................

Nokia ALAW to Linphone ALAW scenario:
............................
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.193:16384 (type 08, len 000160)
Sent RTP P2P packet to 192.168.2.155:7078 (type 08, len 000160)
............................

Original comment by iiordanov@gmail.com on 8 Aug 2009 at 8:20

GoogleCodeExporter commented 9 years ago
This is a duplicate of issue #10.

Sorry for linking the issue to the wrong one when you first posted it. Problem 
is the 
length of packets which gets converted by Asterisk when it transcodes.

Original comment by pmerl...@googlemail.com on 8 Aug 2009 at 8:56

GoogleCodeExporter commented 9 years ago

Original comment by pmerl...@googlemail.com on 3 Sep 2009 at 8:22