Subject: [MMUSIC] Port changeability in response to Invite -- expected behavior?

From: Kathy Kwan <[email-masked]>
Date: Fri, 2 Aug 2002 16:20:34 -0700

To the SIP/MMUSIC community,
 
I was looking at the method proposed by Rosenberg and Schulzrinne in the
IETF Internet Draft entitled "Models for Multiparty Conferencing in SIP"
(dated July 2002, expires Jan 2003), Section 7, entitled "Centralized
Signaling, Distributed Media".    This method describes the conferencing
case where a server controls the SIP connections with all participants, and
uses third party call control to enable media connections to go directly
between the participants.   Hence, the signaling is centralized, but media
is distributed.  In order for the method to work, an inherent assumption is
made that the original ports do not change in the response to an Invite.
Two examples of this assumption are shown in the call flow diagram of
"Centralized Signaling, Distributed Media" Figure 7:
 
(1)      If a participant is taken off hold, the participant cannot change
its ports in its response.
 
In Figure 7, participant  D is taken off hold in the very last Invite
transaction between D and the server.   It is assumed that D does not change
its ports D1,D2, and D3 in its Invite 200 OK response.   
 
(Perhaps there is a way to interleave invites using provisional responses
that could fix this particular case, but if that exists, the response could
be delayed by as long as it takes to receive the responses from all other
participants in the conference.)
 
(2)      If a participant receives a re-Invite for any reason, the
participant must maintain its original offered ports in the response.
 
In Figure 7, parties A, B and C are assumed to not change their original
ports when they receive a re-Invite from the server asking for an additional
port for D.   According to Figure 7, A, B, and C are not put on hold when D
arrives, so this case is distinct from (1) above.     
 
My questions are:
 
(3)      What assumptions can be made about the ports being able to change
in the response to an Invite?    Is there documentation of this in any RFCs?

Perhaps a media attribute could be used to request that the ports don't
change if it is not already implied in either of the cases above?
 
(4)      There are two ways to convey hold described below.   Is the
expectation for port behavior the same for both cases of hold?
 
The original way to convey hold is to set the IP address to 0.0.0.0.  This
case does not require RTCP to be sent during the hold period.   A new method
to convey hold is to use the media attributes "a=inactive", "a=sendonly" or
"a=recvonly", depending on the direction of the hold.  Because of the
different implications for the hold methods, particularly for RTCP, I am
asking this question with both methods in mind.
 
Thank you in advance for your comments.
 
Regards,
Kathy Kwan
Interval Media

---

From: "Victor Paulsamy" <[email-masked]>
Date: Tue, 6 Aug 2002 20:14:39 -0700

Cathy: Comments inline ...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Kathy Kwan
Sent: Friday, August 02, 2002 4:21 PM
To: [email-masked]'; [email-masked]'
Cc: Kathy Kwan
Subject: [Sip] Port changeability in response to Invite -- expected
behavior?

  My questions are:

  All aspects of a session can be changed as a result of a reINVITE. In this
example that you refere to, the address/port MUST NOT change.

      The first one is (0.0.0.0) used by old UAs and using media attributes
to convey hold status is used by new UAs (perhaps bis05 onwards). However,
they do not imply anything with regards to the port that can otherwise be
changed using a reINVITE

  Regards,

  --victor

  Regards,

  Kathy Kwan

  Interval Media