This is the exact text as found in the RFC4566
5.14. Media Descriptions ("m=")
m=<media> <port> <proto> <fmt> ...
A session description may contain a number of media descriptions.
Each media description starts with an "m=" field and is terminated by
either the next "m=" field or by the end of the session description.
A media field has several sub-fields:
<media> is the media type. Currently defined media are "audio",
"video", "text", "application", and "message", although this list
may be extended in the future (see Section 8).
<port> is the transport port to which the media stream is sent.
The meaning of the transport port depends on the network being used as
specified in the relevant "c=" field, and on the transport
protocol defined in the <proto> sub-field of the media field.
Other ports used by the media application (such as the RTP Control
Protocol (RTCP) port ) MAY be derived algorithmically from the
base media port or MAY be specified in a separate attribute (for
example, "a=rtcp:" as defined in ).
If non-contiguous ports are used or if they don't follow the
parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:"
attribute MUST be used. Applications that are requested to send
media to a <port> that is odd and where the "a=rtcp:" is present
MUST NOT subtract 1 from the RTP port: that is, they MUST send the
RTP to the port indicated in <port> and send the RTCP to the port
indicated in the "a=rtcp" attribute.
For applications where hierarchically encoded streams are being
sent to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that
used for IP multicast addresses in the "c=" field:
I need a copy of the whole SDP to give you accurate responses to your questions...
I will assume an IP (v4) conncetion over UDP for this answer.
When you call
The connection line and multiple other lines are read to determine what type of socket and protocol to use to setup the RtpClient.
An existing socket can be given to override this information for whatever reason deemed necessary, e.g. NAT or otherwise.
If there was no existing socket passed then a new socket is created which will be used to receive data from the Rtp port and Rtcp ports specified in the Media Description; When the new socket is created it is also optionally connected based on the 'connect'
parameter which defaults to false.
During 'TransportContext.Initialize' => 'punchHole' is an option which defaults to true.
If the IPAddress is on the same subnet then it is assumed that there is no outbound or inbound restriction on the connection, if not 4 bytes of data are sent to the remote ports to ensure that the router you are behind will allow traffic through from the remote
IP and port. This is known as
UDP Hole Punching.
When the remote EndPoint is not reachable a ConnectionReset error will occur if the remote host indicates that the port is closed, the remote host indicates this by echoing the data you send back via ICMP.
The RtpClient translates this into a fallback mode where it will receive from ANY port from the RemoteIP until data arrives.
Once data arrives the RemoteRtp and RemoteRtcp ports are set according.
You can detect when this occurs via
TransportContext.RemoteRtp.Port == 0
What I would do is start with a port >= 1000 <= 15000 for local networks and port >= 30000 for remote networks.
You can find out what ports are open to you by using the
function or using the
for your network adapter if supported.
contains an SDP which indicates the connection address and ports which are already known to be available for the recipients to use.
You don't have to worry about what ports they can receive or other such nuances such as what IP address they can receive from because the data is coming from your router outside your network and from your PC within your network.
When they receive the
they will say okay the data is coming from 'IP X (Your External IP) @ Port Y (RTP) and Z (RTCP)'
They will setup a socket to receive from X @ Y and Z.
They will then send back an
with an SessionDescription which has their connection address and a Media Description indicating the destination ports they expect data to send data on if required to.
This forms a two way mapping from your source to their destination ports which you control and a mapping from their source ports which you do not control to where you must receive data from (destination end point) but only if you want to.
If you cannot receive data at those ports for whatever reason or the client cannot receive data on your ports for whatever reason the
must be responded to accordingly. Thus you or the client may respond to the
or otherwise to indicate this mapping does be completed as expected.
Please let me know if I can make that example any clearer.