Subject: Re: Fwd: Re: Define a unicast RTP session.

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 23:06:22 -0400

[email-masked] wrote:
> 
> I agree with you that, under RFC 1889, an SDP invite and its OK will create
> two sessions if the destination ports differ.  But if they don't (can this
> be done predictably?), there should be (is) one session.  Later drafts of
> RFC 1889 do specify that the destination ports in a session may differ, and
> thus might eventually cause trouble for SIP/SDP if its notion of a session
> changes, if there's not trouble now.

There is no trouble now. Whether you call it one or two sessions in any
case seems completely academic. The operation in either case, as I can
tell, is the same.

>  Then it might become difficult for
> SIP/SDP to correlate the two directions of flow (is this necessary?).

Sorry? How do you arrive at this conclusion? As the caller, I choose the
ports I will receive media on, and I am told the ports to send media
two. They are correlated since they are part of the same SIP call. Its
been working in SIP devices for a while.

-Jonathan R.
-- 
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

---

From: [email-masked]
Date: Fri, 1 Sep 2000 13:02:41 -0500

The literal understanding of the section 3 definition includes the
observation that the definition is singular, thus saying "For each
participant, _the_ session . . .".  It does not say "For each participant,
_a_ session . . .".  Subtle, but unambiguous.  So the session (not
necessarily the destination address) is common to all, regardless of the
caste.  Further proof: section 7.1, paragraph 1.  There, clouds are equated
to sessions, and a unicast cloud is defined by a pair of unicast addresses.
It requires no interpretation to call those destination addresses.
Therefore a unicast session is defined by two destination addresses (where
the destination port is still common).

This causes no problems for the MIB.  I see this might not be true for SDP.
Perhaps you could elaborate.  Here's my contribution:

I agree with you that, under RFC 1889, an SDP invite and its OK will create
two sessions if the destination ports differ.  But if they don't (can this
be done predictably?), there should be (is) one session.  Later drafts of
RFC 1889 do specify that the destination ports in a session may differ, and
thus might eventually cause trouble for SIP/SDP if its notion of a session
changes, if there's not trouble now.  Then it might become difficult for
SIP/SDP to correlate the two directions of flow (is this necessary?).
Anyway, this came after the definition of SDP (RFC 2327), so was not there
to muddy the waters when the SDP authors were considering the nature of a
session.  Bidirectional unicast sessions could have been explicitly
permitted from the beginning.

Vince Virgilio

Jonathan Rosenberg <[email-masked]> on 09/01/2000 12:40:49 AM

To:   "Strahm, Bill" <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>, Mark
      Baugher <[email-masked]>, [email-masked]
Subject:  Re: Fwd: Re: Define a unicast RTP session.

"Strahm, Bill" wrote:
>
> I think I'll step in as another one of the RTP MIB authors who had to
> wrangle with this issue...
>
> We took the definition from 1889 quite literally From section 3
>
>    RTP session: The association among a set of participants
>         communicating with RTP. For each participant, the session is
>         defined by a particular pair of destination transport addresses
>         (one network address plus a port pair for RTP and RTCP). The
>         destination transport address pair may be common for all
>         participants, as in the case of IP multicast, or may be
>         different for each, as in the case of individual unicast network
>         addresses plus a common port pair.  In a multimedia session,
>         each medium is carried in a separate RTP session with its own
>         RTCP packets. The multiple RTP sessions are distinguished by
>         different port number pairs and/or different multicast
>         addresses.
>
> Therefore in the case of unicast there ARE two sessions, because there
are
> two different destination transport addresses.  Did we get it right, I
hope
> so (we are on track to have an RFC issued).

This was my understanding, and is exactly the reason I claimed it was
two in the first place. Also, if one assumes that a single m line in SDP
means one session, then with SIPs usage of SDP we also get two sessions
- thats because one SDP is sent in the INVITE (indicating the receive
port pairs of the caller), and another, different SDP in the 200 OK
(indicating the receive port pairs of the callee). This is what I meant
by mentioning that the annexes in SIP should be checked for more info.

-Jonathan R.