[Serdev] [Tracker] Resolved: (SER-319) nathelper/rtpproxy assigns port != 0 to rejected streams, thus enabling it

[Jan Janak (JIRA)]

     [ http://tracker.iptel.org/browse/SER-319?page=all ]

Jan Janak resolved SER-319.
---------------------------

    Resolution: Fixed

This has already been fixed by Maxim, so I am closing this ticket.

> nathelper/rtpproxy assigns port != 0 to rejected streams, thus enabling it
> --------------------------------------------------------------------------
>
>                 Key: SER-319
>                 URL: http://tracker.iptel.org/browse/SER-319
>             Project: SER
>          Issue Type: Bug
>          Components: NAT Traversal
>    Affects Versions: 2.0
>         Environment: iptel.org
>            Reporter: Stefan Sayer
>             Fix For: 2.0, Ipteldorf
>
>         Attachments: nathelper_rejected_stream.patch
>
>
> Rejected streams (port = 0) are enabled by nathelper/rtpproxy, which sets the port to a value != 0. 
> Example: Assume A calls B with an SDP offer that contains two streams, one audio and one video stream. Now B answers with an answer that contains a port != 0 for the audio stream, and a port == 0 for the video stream. After processing by nathelper/rtpproxy, both streams have a port not equal to zero - so A thinks B accepted both streams. 
> A simple fix  in nathelper is the attached patch, that not replaces the port in the SDP if the original port was zero.
> Alternatively this may be fixed in rtpproxy, transparently to nathelper, which would save one port (the one of the rejected stream B->A).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.iptel.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira