Subject: How to pack multiple GSM frames into one RTP packet

From: [email-masked]
Date: Mon, 17 Apr 2000 16:07:15 +0200 (MET DST)

Hi,

Apologies if this has come up before, I've searched and not found an answer.

How do you pack two GSM frames into one RTP packet? A GSM frame is
260 bits (32.5 octets) long.

Method #1: Since a single GSM frame is transmitted as 33 octets, i.e.
       the frame plus a nybble of padding, two GSM frames should be 
       transmitted in 66 octets. This is what RAT does.

Method #2: Since a single GSM frame is really 32.5 octets, two GSM
       frames should be transmitted as 65 octets. This is what another
       implementation I've seen does.

Maybe RFC1890 could say something like

	  RTP payloads with frames which do not end on octet
	  boundaries should (must?) be zero-padded to the next 
	  octet boundary. This applies even when several
	  frames are transmitted in one packet.

I note that this may cause problems for G.728. I don't know. Maybe it
should say the opposite, i.e. that no padding is allowed except at the
end of the packet. This has nothing to do with RTP padding. I can
think of efficient software and hardware codec implementations either
way.

Comments?

Matthias

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Mon, 17 Apr 2000 18:00:40 +0200

>        transmitted in 66 octets. This is what RAT does.

This is also what the current draft standards document says:
http://search.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.txt,
section 4.5.8.1:

   In the GSM packing used by RTP, the bits SHALL be packed beginning
   from the most significant bit. Every 160 sample GSM frame is coded
   into one 33 octet (264 bit) buffer. Every such buffer begins with a 4
   bit signature (0xD), followed by the MSB encoding of the fields of
   the frame. The first octet thus contains 1101 in the 4 most
   significant bits (0-3) and the 4 most significant bits of F1 (0-3) in
   the 4 least significant bits (4-7). The second octet contains the 2
   least significant bits of F1 in bits 0-1, and F2 in bits 2-7, and so
   on.

Note that this is the document that is intended to supersede RFC1890.

Gruesse, Carsten

PS.: And I apologize for having my hand in designing it that way 8 years
ago...