Subject: Re: [SIP] recvonly/sendonly in SDP

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 01:44:58 -0400

Changing this would break backwards compatibility.

We were aware of this at writing time, and in fact mention this:

> The interpretation of send-only and receive-only for multicast media
>    sessions differs from that for unicast sessions. For multicast,
>    send-only means that the recipient of the session description (caller
>    or callee) SHOULD only send media streams to the address and port
>    indicated. Receive-only means that the recipient of the session
>    description SHOULD only receive media on the address and port
>    indicated.

The reason is that multicast and unicast are quite different. For
everything else in the SDP sent in the INVITE, the information reflects
the perspective of the sender of the SDP. This is the reason we did it
this way. We could either be consistent with the meaning of the rest of
the parameters, or be consistent with multicast. We chose the former.

-Jonathan R.

Benny Prijono wrote:
> 
> Hello all,
> 
> As Henning has pointed out below regarding the meaning of
> recvonly/sendonly attribute in SDP body, it seems that there's an
> incompatibility between SDP draft and SIP one.
> 
> Has this been confirmed to the SDP authors? Because I got the
> impression that Henning was not sure about this. And if this is really
> the case, then has a consensus been made regarding which one to use?
> 
> Personally, although I have implemented them as in the SIP draft, I
> don't mind if it has to be changed.
> 
> cheers,
> Bennylp
> 
> Henning Schulzrinne wrote:
> >
> >
> > Finally, there's a small bug in the current definition of the send-only
> > and receive-only description in Section B.2. RFC 2327 says:
> >
> >  a=recvonly
> >        This specifies that the tools should be started in receive-only
> >        mode where applicable. It can be either a session or media
> >        attribute, and is not dependent on charset.
> >
> > This is presumably from the viewpoint of the receiver of the SDP. (This
> > would certainly be true if I used SDP to invite somebody to a multicast
> > conference.)  Thus, if the caller wants to only send, it should
> > logically include a 'recvonly' in its SDP, since that's what the
> > receiver of the SDP (the callee) would have to do.
> >
> > In the current SIP B.2 definition,
> >
> >    If a session description from a caller contains a media stream which
> >    is listed as send (receive) only, it means that the caller is only
> >    willing to send (receive) this stream, not receive (send). The same
> >    is true for the callee.
> >
> > This says the opposite: the caller that only sends would set the
> > description to send-only. It may be too late to fix this, depending on
> > whether anybody actually implements sendonly and recvonly.
> >
> > --
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> >
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip