We recently ran into something regarding RTCP – Generic NACK Feedback,
which was introduced with https://issues.asterisk.org/jira/browse/ASTERISK-27810
Me and my colleague read through RFC 4585 Section 6.2.1 “Generic NACK” but we
didn’t really find an answer to our question,
which is the following:
Asterisk sends Receiver Reports on the RTCP port (RTP+1), whereas
the NACK is sent on the RTP port which confuses the other end of our system
(rtpengine).
Is Generic NACK supposed to be sent to the RTP port or isn’t it supposed to be
sent on the RTCP port (which would make this a bug in the current
implementation)?
Maybe you guys can enlighten us somehow.
Since this is not configurable we had to patch this out on the Asterisk side
for now, but this is just a very dirty workaround.
I have copied the relevant infos from the wireshark capture below
RTCP Receiver report to RTCP port (41971):
Frame 19635: 124 bytes on wire (992 bits), 124 bytes captured (992 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.17.217.9, Dst: 172.17.217.10
User Datagram Protocol, Src Port: 11729 (11729), Dst Port: 41971 (41971)
Real-time Transport Control Protocol (Receiver Report)
[Stream setup by SDP (frame 1)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = Reception report count: 1
Packet type: Receiver Report (201)
Length: 7 (32 bytes)
Sender SSRC: 0x4ef37590 (1324578192)
Source 1
Real-time Transport Control Protocol (Source description)
[Stream setup by SDP (frame 1)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = Source count: 1
Packet type: Source description (202)
Length: 11 (48 bytes)
Chunk 1, SSRC/CSRC 0x4EF37590
[RTCP frame length check: OK - 80 bytes]
RTCP Receiver Report with Generic NACK to RTP port (41970):
Frame 20013: 92 bytes on wire (736 bits), 92 bytes captured (736 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.17.217.9, Dst: 172.17.217.10
User Datagram Protocol, Src Port: 11729 (11729), Dst Port: 41970 (41970)
Real-time Transport Control Protocol (Receiver Report)
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = Reception report count: 1
Packet type: Receiver Report (201)
Length: 7 (32 bytes)
Sender SSRC: 0x4ef37590 (1324578192)
Source 1
Real-time Transport Control Protocol (Generic RTP Feedback): NACK: 1 frames lost
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = RTCP Feedback message type (FMT): Generic negative
acknowledgement (NACK) (1)
Packet type: Generic RTP Feedback (205)
Length: 3 (16 bytes)
Sender SSRC: 0x4ef37590 (1324578192)
Media source SSRC: 0x42d0de62 (1120984674)
RTCP Transport Feedback NACK PID: 8089
RTCP Transport Feedback NACK BLP: 0x0000 (No additional frames lost)
[RTCP frame length check: OK - 48 bytes]
With best regards
Florian Floimair
Innovation - Software-Development
COMMEND INTERNATIONAL GMBH
A-5020 Salzburg, Saalachstraße 51
http://www.commend.com<http://www.commend.com/>
Security and Communication by Commend
FN 178618z | LG Salzburg
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
