[asterisk-dev] Question regarding RTCP - NACK

[Floimair Florian]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190211/3f1a083c/attachment.html>