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?
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
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@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
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.
On 24/02/2023 06:07, Harald Welte wrote:
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.
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.
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.)
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@osmocom.org wrote:
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@osmocom.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-
Harald Welte -
Keith -
morteza ali Ahmadi -
Neels Hofmeyr -
Tomcsanyi, Domonkos