0
votes

I monitor a WebRTC session, found extra unknown(I don't know) data, now I am composing the same RTP audio session, I need to know it why.

Send PCMU (8bit, mono, 8000Hz) frame to WebRTC browser client, each frame is of 20 ms, so the payload size = 8000Hz * 1Byte(8bit) * 20ms/1000ms = 160 bytes, however in client received 170 bytes(can see from WireShark):

Frame 34012: 236 bytes on wire (1888 bits), 236 bytes captured (1888 bits) on interface 0
Ethernet II, Src: Tp-LinkT_4d:01:68 (e4:d3:32:4d:01:68), Dst: IntelCor_cb:c6:7c (24:77:03:cb:c6:7c)
Internet Protocol Version 4, Src: 111.198.38.42, Dst: 192.168.1.103
User Datagram Protocol, Src Port: 48244 (48244), Dst Port: 55003 (55003)
Real-Time Transport Protocol
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...1 .... = Extension: True
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    Payload type: ITU-T G.711 PCMU (0)
    Sequence number: 36871
    Timestamp: 1038276488
    Synchronization Source identifier: 0x4994b249 (1234481737)
    Defined by profile: Unknown (0xbede)
    Extension length: 2
    Header extensions
    Payload: 8037d1facad8535b355510e6b6880e8700eabfaed41c34b7...

Where is the extra 10 (170-160) bytes from? where is the extra 10 (170-160) bytes from?

2
Thanks for tidying my post :-)Wen
Solved, because I split my audio data into 20ms (size 160bytes) and send via RTP, in the client side, also received 170 bytes. Although still not knowing where the 10 extra comes from, but not a problem to me!Wen

2 Answers

2
votes

The rtp header extension bit was set, so the 10 extra bytes are probably that. Good chance its the "urn:ietf:params:rtp-hdrext:ssrc-audio-level" extension if your getting audio from a webrtc endpoint. Have a look at https://www.rfc-editor.org/rfc/rfc6464

1
votes

probably the SRTP auth tag which, if this uses 80 bits would be 10 bytes.