Re: [MMUSIC] Offer/Answer PT Questions - text proposal

[Paul Kyzivat <[e-mail]>]

On 3/4/16 7:28 AM, Drage, Keith (Nokia - GB) wrote:
> My assumption is that the term “session” in RFC 3264 is inherited from
> RFC 3261 when used in the context of SIP. That definition is as follows:
>
>        Session: From the SDP specification: "A multimedia session is a
>
>           set of multimedia senders and receivers and the data streams
>
>           flowing from senders to receivers.  A multimedia conference is
>
>           an example of a multimedia session." (RFC 2327 [1]) (A session
>
>           as defined for SDP can comprise one or more RTP sessions.)  As
>
>           defined, a callee can be invited several times, by different
>
>           calls, to the same session.  If SDP is used, a session is
>
>           defined by the concatenation of the SDP user name, session id,
>
>           network type, address type, and address elements in the origin
>
>           field.
>
> I’d note that we have definitions of both “multimedia session” and
> “communication session” in RFC 7656. My assumption is that the
> definition above relates to “communication session”.

I'll agree that one or the other of the above was probably intended. In 
any case I have some difficulty distinguishing between the two.

Looking to 3264 for answers, I find the following in the introduction:

    ... Unlike multicast,
    where there is a global view of the session that is used by all
    participants, unicast sessions involve two participants, and a
    complete view of the session requires information from both
    participants, and agreement on parameters between them.

    As an example, a multicast session requires conveying a single
    multicast address for a particular media stream.  However, for a
    unicast session, two addresses are needed - one for each participant.
    As another example, a multicast session requires an indication of
    which codecs will be used in the session.  However, for unicast, the
    set of codecs needs to be determined by finding an overlap in the set
    supported by each participant.

    As a result, even though SDP has the expressiveness to describe
    unicast sessions, it is missing the semantics and operational details
    of how it is actually done.  In this document, we remedy that by
    defining a simple offer/answer model based on SDP.  In this model,
    one participant in the session generates an SDP message that
    constitutes the offer - the set of media streams and codecs the
    offerer wishes to use, along with the IP addresses and ports the
    offerer would like to use to receive the media.  The offer is
    conveyed to the other participant, called the answerer.  The answerer
    generates an answer, which is an SDP message that responds to the
    offer provided by the offerer.  The answer has a matching media
    stream for each stream in the offer, indicating whether the stream is
    accepted or not, along with the codecs that will be used and the IP
    addresses and ports that the answerer wants to use to receive media.

 From this, I am inclined to think that "multimedia session" is the 
intended meaning of "session".

Also, note that the above speaks specifically of *two* participants. I 
interpret this as meaning that it was written without consideration for 
multimedia sessions involving participants other than the offerer and 
the answerer.

I think we all agree that we now have common cases of O/A being used to 
join more than two participants into a multimedia session. But since it 
doesn't adequately consider this situation we have considerable 
ambiguity about how that should work. And work will be required to fix this.

> Given that we have a currently open revision of the SDP specification,
> it might be worth making a more robust definition by reference in that
> document.

Agreed.

	Thanks,
	Paul

> Note that RFC 7656 also gives the definition of RTP session.
>
> Regards
>
> Keith
>
> *From:*mmusic [mailto:[e-mail]] *On Behalf Of *EXT Roman
> Shpount
> *Sent:* 03 March 2016 16:20
> *To:* Christer Holmberg
> *Cc:* Paul Kyzivat; [e-mail]
> *Subject:* Re: [MMUSIC] Offer/Answer PT Questions - text proposal
>
> On Thu, Mar 3, 2016 at 2:14 AM, Christer Holmberg
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>      >> IF we agree that the PT binding is per session, and not per
>     direction, we can update that part of 3264, because THAT’s what
>     causing Martin’s issue.
>      >>
>      >> RFC 3264 might be slightly ambiguous about the answer since it
>     does not even define the "session", but it never states that binding
>     is per direction. It states
>      >> that binding MUST NOT change for the duration of a session with
>     no direction mentioned in this restriction. This mean we might need
>     a clarification but not necessarily an update.
>
>     Well, technically it is an update to RFC 3264, even if the new text
>     only clarifies existing text :)
>
> The biggest problem with RFC 3264 is coming from the fact that term
> "session" is not even defined and things like RTP session are not even
> mentioned.
>
>      >Bigger problem is that this requirement is unimplementable with
>     3pcc and routinely ignored. This is definitely a problem and needs
>     an update to resolve.
>
>     But then, is it a good idea to say that the PT binding is for the
>     whole O/A session? What preventing us from saying that it is per
>     direction? The fact that it would conflict with the RTP session
>     definition?
>
> If there are more then two parties in the RTP session, i.e. if one of
> the parties in O/A is an RTP forwarder, the same PT cannot possibly be
> assigned to different codecs in different directions. This is why PT
> binding is per O/A session.
>
> _____________
> Roman Shpount
>