Re: [MMUSIC] Difficulties accepting and rejecting with bundling

[[e-mail] (Dale R. Worley)]

> From: "Ejzak, Richard P (Richard)" <[e-mail]>
> 
> > it does not see media.  (It does not suffice for the answerer to
> > provide a null transport address and non-zero port for the MD, or for
> > the answerer to send "a=inactive", as an intermediate entity may see
> > the MD as being accepted and expect the offerer to send RTCP.)
> 
> Considering the following text from RFC 3264:
> 
> "Of course, when used, the port number MUST NOT be zero, which would
> specify that the stream has been disabled.  An agent MUST be capable
> of receiving SDP with a connection address of 0.0.0.0, in which case
> it means that neither RTP nor RTCP should be sent to the peer."
> 
> There is no ambiguity here about the meaning of zero port.
> 
> While this text could be interpreted to not specifically preclude
> the peer that indicates an unspecified address from sending RTCP to
> the peer indicating a valid address, this seems really far-fetched
> to me.  Sending this RTCP would be pointless and wasteful since by
> definition it would have nothing to report on and there is no
> possibility to receive reports.  
> 
> If would be nice to eliminate this ambiguity by ending the quoted
> sentence "...neither RTP nor RTCP should be sent to either peer."
> 
> The text also says that the peer indicating an unspecified address
> "...doesn't know the addresses and ports at the time..."  Again, it
> seems like a real stretch to assume that the peer can send RTCP if
> it doesn't have an address or port available for receipt of RTP.

Sorry, I was hasty in writing the message.  What I should have said is

    (It does not suffice for the answerer to
    provide a null transport address and non-zero port for the MD, or for
    the answerer to send "a=inactive", as an intermediate entity may see
    the MD as being accepted and expect the answerer to send RTCP.)
                                            ^^^^^^^^

The problem being that an offer with a real address and an answer with
a null address historically has meant that the answerer has put the
call on hold; the answerer is expected to send media to the offerer
but the offerer is not expected to send media to the answerer.  The
answerer is also expected to send RTCP, but of course the offerer
cannot send RTCP (as it has no address to send it to).

If the answerer specifies "a=inactive" with a real address, then
neither the offerer nor the answerer should send media, but both are
expected to send RTCP:

    RFC 4566, section 6, item "a=inactive"

      a=inactive

         This specifies that the tools should be started in inactive
         mode.  This is necessary for interactive conferences where
         users can put other users on hold.  No media is sent over an
         inactive media stream.  Note that an RTP-based system SHOULD
         still send RTCP, even if started inactive.  [...]

Combining the two techniques suppresses everything but expectation of
RTCP from the answerer to the offerer.

Unfortunately, I expect dialog-stateful SBCs to pay attention to that
RTCP in order to time out abandoned dialogs.

Dale