Re: [MMUSIC] Difficulties accepting and rejecting with bundling

["Ejzak, Richard P (Richard)" <[e-mail]>]

Agreed that an endpoint signaling a valid address and port is required to be capable of receiving RTP and RTCP, irrespective of what is signaled by the peer.

But ICE cannot succeed without valid addresses/candidates from both endpoints.  Consent cannot be established without valid addresses from both endpoints.  Many systems require symmetric RTP, which also is not possible without valid addresses from both endpoints.  So if either endpoint signals an unspecified address, then packets will not usually be able to flow in either direction.

It is not reasonable (or intelligent) for any intermediate to time out a session for a lack of packet transmissions that cannot possibly occur (or at least that frequently cannot occur).  This is the only compatibility concern identified with the asymmetric use of the unspecified address, but this concern is clearly misplaced for rtcweb applications where ICE and consent are mandatory.

Richard

> -----Original Message-----
> From: Dale R. Worley [mailto:[e-mail]]
> Sent: Monday, March 11, 2013 4:51 PM
> To: Ejzak, Richard P (Richard)
> Cc: [e-mail]
> Subject: Re: [MMUSIC] Difficulties accepting and rejecting with
> bundling
> 
> > 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