[ 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
_______________________________________________
Serdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/serdev
