[asterisk-bugs] [JIRA] (ASTERISK-29433) res_rtp_asterisk: Server reflexive candidates use incorrect raddr for RTCP

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-29433:
-------------------------------------

    Target Release Version/s: 18.5.0

> res_rtp_asterisk: Server reflexive candidates use incorrect raddr for RTCP
> --------------------------------------------------------------------------
>
>                 Key: ASTERISK-29433
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29433
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 16.17.0, 18.4.0
>            Reporter: Chris
>            Assignee: Joshua C. Colp
>            Severity: Major
>              Labels: patch
>      Target Release: 16.19.0, 18.5.0
>
>         Attachments: ASTERISK-29433.diff, no_audio_reproduction.zip
>
>
> Frequently our field-testers are complaining about missing audio and video.
> After troubleshooting with the developer of our client SIP stack (AmSip/OSip2) we came to the conclusion that the root-cause is in Asterisk.
> In the cases where no audio (or video) is received, it seems that Asterisk is sending the media packets to the wrong port.
> See our engineer's detailed network analysis below.
> _________________________________
> FIRST OBSERVATION
> _________________________________
> From asterisk_tcpdump.cap
> packet 1243: asterisk (192.168.1.2) makes a STUN BINDING REQUEST from port 14429
> packet 1251: asterisk receive an answer MAPPED-ADDRESS: 78.22.132.194:14429
> This means the packet was received by stun server from the NAT IP 78.22.132.194 AND NAT PORT 14429
> This means the NAT has forwarded the packet **without** changing the PORT. (NAT are often changing port)
> This means the candidate should be:
> a=candidate:S4e1684c2 2 UDP 1694498814 78.22.132.194 14429 typ srflx raddr 192.168.1.2 rport 14429\r\n
> But it appears in SDP as:
> a=candidate:S4e1684c2 2 UDP 1694498814 78.22.132.194 14429 typ srflx raddr 192.168.1.2 rport 14428\r\n
> CONCLUSION: THIS IS AN ERROR FROM ASTERISK
> _________________________________
> SECOND OBSERVATION
> _________________________________
> Let's look at iphone_tcpdump.pcap  "with filter (udp.port == 12600) && (ip.addr == 192.168.1.2)"
> We can see many packets being sent to 192.168.1.2:14428, but nothing received. I guess
> this is expected.
> Let's look at asterisk_tcpdump.pcap  "with filter udp.port == 14428 && ip.addr == 192.168.0.201"
> packet 1529: We can see a a bind request being sent  + a retransmission
> The request is sent FROM 192.168.1.2 from port 14428 to 192.168.0.201on port 12601
> The request TID is :Message Transaction ID: 0e5c00008d4ca0783b1a7b48
> Then, asterisk receive a response:
> packet 1538 is the symmetric response. It contains a XOR-MAPPED-ADDRESS: 192.168.0.145:14428
> This response has been built from amsip.
> This response is coming from 192.168.0.201from PORT 12601
> Let's look  iphone_tcpdump.pcap if we can find this request + answer:
> Let's use the filter "(udp.port == 12601) && (ip.addr == 192.168.0.145 && udp.port == 14428)"
> The packet 721 is matching the request. It's coming on RTCP port (12601) but comes from the RTP port (14428)
> The packet 723 is correct and match the response
> amsip has correct processing: amsip understand this is coming to the RTCP port and establish the RTCP connection.
> Unfortunately, asterisk has sent the packet from port 14428 instead and this is NOT CORRECT.
> ____________________
> FINAL CONCLUSION
> ______________________
> Asterisk has sent packet 1529 from the wrong port.
> The fact that asterisk is using the wrong port (14428) in the RTCP candidate has no impact, but still it's WRONG.
> There was no NAT issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)