22 Feb
2023
22 Feb
'23
10:28 p.m.
Hi, I have developed a UMTS core network using a home nodeB (HNB) which the
mobile phones (or UEs) can register on my network and get the required
services such as call service. I have implemented all the required
procedures for call service and I can establish a successful call for my
connected UEs.
In one of the most important procedures, i.e **Call Proceeding**, I have
identified the coding of speech transferred between UEs and core. Here is
my coding options (in wireshark):
GSM A-I/F DTAP - Call Proceeding
Protocol Discriminator: Call Control; call related SS messages (3)
.... 0011 = Protocol discriminator: Call Control; call related
SS messages (0x3)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
00.. .... = Sequence number: 0
..00 0010 = DTAP Call Control Message Type: Call Proceeding (0x02)
Bearer Capability 1 - (Spare)
Element ID: 0x04
Length: 6
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: Spare
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information
transfer capability
..00 .... = Spare bit(s): 0
.... 0010 = Speech version indication: GSM full rate speech
version 2(GSM EFR) (0x2)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information
transfer capability
..00 .... = Spare bit(s): 0
.... 1000 = Speech version indication: GSM full rate speech
version 5(FR AMR-WB) (0x8)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information
transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech
version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information
transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech
version 3(HR AMR) (0x5)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information
transfer capability
..00 .... = Spare bit(s): 0
.... 0001 = Speech version indication: GSM half rate speech
version 1(GSM HR) (0x1)
So I can see the RTP packets transferred between UE and core. An instance
is mentioned here (in wireshark):
Real-Time Transport Protocol
[Stream setup by RANAP (frame 2950)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: DynamicRTP-Type-96 (96)
Sequence number: 56611
[Extended sequence number: 56611]
Timestamp: 424448575
Synchronization Source identifier: 0x5c260101 (1545994497)
RFC 2198: Redundant Audio Data
Header 1: PT=ITU-T G.728
0... .... = Follow: Not set
.000 1111 = Payload type: ITU-T G.728 (15)
Payload: 0028ba44776b3eee7a050039cdaa521cc20ac08d2bcf1818…
I have aggregated all RTP packets payload. How can I convert the aggregated
bytes to a hearable audio?
--
*When there is much light, The shadow is deep...*
24 Feb
24 Feb
2:29 a.m.
On Wed, Feb 22, 2023 at 11:58:24PM +0330, morteza ali Ahmadi wrote:
I have aggregated all RTP packets payload. How can I
convert the aggregated
bytes to a hearable audio?
Firstly you need to be aware that 3G audio uses IuUP -- the RTP payload
includes an IuUP header followed by the AMR audio data. To see this in
wireshark, you need to go to Preferences / Protocols / IuUP and mark
[x] Dissect IuUP Payload bits.
osmo-mgw has implemented the IuUP to AMR conversion: if one side of an MGCP
endpoint has VND.3GPP.IUFP and the other has AMR, osmo-mgw will decapsulate the
AMR from the IuUP, i.e. forward plain AMR.
Next I guess you will convert the AMR to something you can play back, AFAIK
https://gitea.osmocom.org/osmocom/gapk is capable of that?
Also wireshark is supposed to be able to play back an RTP stream. See the menu
item Telephony / RTP. It hasn't worked for me yet, not sure what I'm doing
wrong, but I also never tried for more than two minutes.
This is a rough outline, you'll have to figure out all the details...
~N
10:15 a.m.
AFAIR Wireshark cannot play our RTP streams because it has a very limited set of codecs,
mostly focusing on regular VoIP audio.
Cheers,
Domi
24.02.2023 dátummal, 1:29 időpontban Neels Hofmeyr
<nhofmeyr(a)sysmocom.de> írta:
On Wed, Feb 22, 2023 at 11:58:24PM +0330, morteza ali Ahmadi wrote:
I have aggregated all RTP packets payload. How
can I convert the aggregated
bytes to a hearable audio?
Firstly you need to be aware that 3G audio uses IuUP -- the RTP payload
includes an IuUP header followed by the AMR audio data. To see this in
wireshark, you need to go to Preferences / Protocols / IuUP and mark
[x] Dissect IuUP Payload bits.
osmo-mgw has implemented the IuUP to AMR conversion: if one side of an MGCP
endpoint has VND.3GPP.IUFP and the other has AMR, osmo-mgw will decapsulate the
AMR from the IuUP, i.e. forward plain AMR.
Next I guess you will convert the AMR to something you can play back, AFAIK
https://gitea.osmocom.org/osmocom/gapk is capable of that?
Also wireshark is supposed to be able to play back an RTP stream. See the menu
item Telephony / RTP. It hasn't worked for me yet, not sure what I'm doing
wrong, but I also never tried for more than two minutes.
This is a rough outline, you'll have to figure out all the details...
~N 
2:07 p.m.
On Fri, Feb 24, 2023 at 09:15:29AM +0100, Tomcsanyi, Domonkos wrote:
AFAIR Wireshark cannot play our RTP streams because it
has a very limited set of codecs, mostly focusing on regular VoIP audio.
it can play GSM. Our patches for AMR codec support unfortunately were refused
even after everyone assumed the patents had expired and hence no IPR issues
were known anymore.
We'd still love to get AMR codec support in - especailly since wireshark
wouldn't even contain the codec itself but just link to a system-installed
libopencore-amrnb which probably every distribution ships these days.
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
25 Feb
25 Feb
5:49 a.m.
On 24/02/2023 06:07, Harald Welte wrote:
On Fri, Feb 24, 2023 at 09:15:29AM +0100, Tomcsanyi,
Domonkos wrote:
Are those patches published in a repo someplace? maybe even rebased on
something recent :-)
I'd love to locally build a version with support via libopencore to play
AMR, I'm so bored of save the payload... convert raw to amr... open in
vlc/audacity.
AFAIR Wireshark cannot play our RTP streams
because it has a very limited set of codecs, mostly focusing on regular VoIP audio.
it can play GSM. Our patches for AMR codec support unfortunately were refused
even after everyone assumed the patents had expired and hence no IPR issues
were known anymore. We'd still love to get AMR codec support in -
That would indeed be wonderful, hard to imagine and reason, after all,
one is only DE-coding as so many programs already do. (such as the two I
mention above.)
28 Feb
28 Feb
1:12 p.m.
Thanks Neels, It is it is necessary to mention that I have used an IP
access module as HNB and it is connected to my core. So the RTP packets are
received from HNB and I send my RTP packets to HNB (call connection is
established before). I have attached my RTP pcap file. I don't know how I
can convert this log (RTP packet payloads which you said has IuUP header)
to an AMR file.
I have removed the IuUP header (4 bytes) from payload and concatenated all
payloads but the result is not a valid AMR bytes!
Also I think osmo-mgw will not be able to convert IuUP bytes to AMR in
offline mode.
Can you help me more?
On Fri, Feb 24, 2023 at 3:45 PM Harald Welte <laforge(a)osmocom.org> wrote:
On Fri, Feb 24, 2023 at 09:15:29AM +0100, Tomcsanyi,
Domonkos wrote:
--
*When there is much light, The shadow is deep...*
AFAIR Wireshark cannot play our RTP streams
because it has a very
limited set of codecs, mostly focusing on regular VoIP
audio.
it can play GSM. Our patches for AMR codec support unfortunately were
refused
even after everyone assumed the patents had expired and hence no IPR issues
were known anymore.
We'd still love to get AMR codec support in - especailly since wireshark
wouldn't even contain the codec itself but just link to a system-installed
libopencore-amrnb which probably every distribution ships these days.
--
- Harald Welte <laforge(a)osmocom.org>
https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)
476
days inactive
482
days old
5 comments
5 participants
participants (5)
-
Harald Welte -
Keith -
morteza ali Ahmadi -
Neels Hofmeyr -
Tomcsanyi, Domonkos