Direction and perCallInfo (Q11)

The information in this article applies to:

When TransportChannelInfo is used in RTPSession for the rtpAddress and rtcpAddress fields, TransportChannelInfo.sendAddress and recvAddress are mutually exclusive--if there is a value for one, there shall not be a value for the other (but one or the other shall be present). Otherwise the incoming audio stream, for example, would have to share cname, ssrc, sessionId, and assocSessionIds with the outgoing audio stream, and this is simply not possible.

So, for the typical point-to-point call with audio and video in both directions, there would be a SEQUENCE OF two RTPSessions for perCallInfo.audio and a SEQUENCE OF two RTPSessions for .video. For each media, one of the two RTPSessions would be for the incoming stream and the other would be for the outgoing stream. In the incoming-stream RTPSession, values would be present for the rtpAddress.recvAddress and rtcpAddress.recvAddress fields, but the rtpAddress.sendAddress and rtcpAddress.sendAddress fields would not have values. Conversely, the out-going RTPSession would have values for the rtpAddress. and rtcpAddress.sendAddress fields but not for the .recvAddress fields. (Whew!)

However, the perCallInfo.h245 and .callSignaling fields would always have values for both the sendAddress and recvAddress fields. This is because 1. no attributes are shared between directions, as would be the case with RTPSession, and 2. there is only one TransportChannelInfo for each of these fields, not a SEQUENCE-OF them.