[SIPForum-discussion] Inactivity of media stream.

[Paul Kyzivat]

On 4/12/16 2:08 AM, Dauren Zhumagaliev wrote:
> Hello,
>
> I faced a problem of multicast streams processing during
> interoperability test on sip server. Remote side sends initial INVITE
> with two (m) lines: audio and video. Audio stream has normal connection
> information with address and udp port, all the necessary attributes
> presented as well. Video stream has connection information with the
> same  address, but port set to 0. There are no attributes: sendrecv or
> inactive inside both streams.
> My sip server considers null port or null address in the connection
> information or attributes "inactive"/"sendonly"/"recvonly" itself inside
> stream as command to change the mode of media stream, that's why it
> sends response 180 Ringing SDP with attribute "inactive" inside, but it
> sets normal address and port inside connection information. Remote side
> rejects my 180 Ringing SDP. They require null port for video stream in
> 180 response as it was offered in initial INVITE
> I want to prove equivalence of:
> - port = 0 in the connection information
> - address = 0.0.0.0 in the connection information
> - attribute = inactive in the media stream
> And if UAS receives port 0 in INVITE  it MAY send attribute "inactive"
> in response.
>
> I checked RFC3264 but didn't found out recommendations related exactly
> to my case. Could you please advice me some RFC which describes my issue?

I can't give references off the top of my head, but do note that 
"inactive" is quite different from the other forms. With inactive you 
are expected to continue sending RTCP. With port=0 or address=0.0.0.0 
you can't send anything.

Also, IIRC 3264 requires that if you get port=0 in an offer you MUST put 
port=0 in the answer.

The port=0 form is an indication that the m-line and associated media 
section of the SDP is not to be used. When it appears in an answer the 
O/A matching rules for other fields in that media section may not be 
followed. So you are well advised to not be upset to see that.

The address=0.0.0.0 form originated as the "old" way of doing "hold" in 
RFC2543 (the predecessor to RFC3261). It has been deprecated in favor of 
a=inactive. But it still has value in certain other cases. In 
particular, if an offerer or answerer wants to agree to establish a 
media stream, but isn't yet ready to terminate that media. It can use 
address=0.0.0.0 with a non-zero port. This can negotiate codecs, etc., 
yet no media will flow to it. (Media might still flow the other way.) 
Then, when ready, it can send another offer and fill in a valid address.

Note that 'sendonly' is usually shown as the way to do hold. It assumes 
you want music on hold and are prepared to send some sort of media. If 
you don't want to send any media, then 'inactive' is the solution. This 
is better than address=0.0.0.0 because the connections remain up and can 
be easily resumed. That is especially significant when there are NAT 
bindings.

	Thanks,
	Paul