Re: [MMUSIC] Difficulties accepting and rejecting with bundling

Dale,

I don't think the hold argument below hold. 
More inline

Dale R. Worley wrote:
>> From: "Ejzak, Richard P (Richard)"
> <richard.ejzak@alcatel-lucent.com>
>> 
>>> 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; 

In 2543 hold indicated by the offerer sending 0.0.0.0.
It would we awkward if I sent out a valid offer and being suddenly 
held by the answerer.
Further this pratice is no longer recommended since 3264, i.e. I don't we 
need to bother anymore.

I think from the cited text of 3264 it is clear what receipt of 0.0.0.0 
from the answerer means. 

Regards
Thomas

> 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
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic