Re: [Sip] Re: SDP hold

Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se> Thu, 23 August 2001 14:35 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24396 for <sip-archive@odin.ietf.org>; Thu, 23 Aug 2001 10:35:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06926; Thu, 23 Aug 2001 10:18:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06837 for <sip@ns.ietf.org>; Thu, 23 Aug 2001 10:18:08 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23938 for <sip@ietf.org>; Thu, 23 Aug 2001 10:16:49 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7NEI2v26835; Thu, 23 Aug 2001 16:18:03 +0200 (MEST)
Received: from lmf.ericsson.se (rmt160216.am.ericsson.se [138.85.160.216]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA15869; Thu, 23 Aug 2001 16:17:55 +0200 (MET DST)
Message-ID: <3B8513E5.625F03D5@lmf.ericsson.se>
Date: Thu, 23 Aug 2001 17:32:05 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Sean Olson (EUS)" <sean.olson@ericsson.com>
CC: 'Jonathan Rosenberg' <jdrosen@dynamicsoft.com>, 'Colin Perkins' <csp@purple.cs.ucl.ac.uk>, "'sip@ietf.org'" <sip@ietf.org>, 'mmusic' <confctrl@isi.edu>
Subject: Re: [Sip] Re: SDP hold
References: <F9211EC7A7FED4119FD9005004A6C87004C858F2@eamrcnt723.exu.ericsson.se>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

"Sean Olson (EUS)" wrote:
> 
> I thought the entire point of the inactive attribute
> was to specify a stream that did not send RTP -or- RTCP.

This attribute is used to put a call on hold. That is, when you put
somebody on hold the stream will be "sendonly". If at that point of time
you are put on hold as well, the media stream will be "inactive".
Therefore, RTCP is still sent.

> If we accept the following:
> 
> 1) send-only: RTP one way, RTCP two way
> 2) recv-only: RTP one way, RTCP two way
> 3) send-recv: RTP two way, RTCP two way
> 4) inactive:  no RTP, RTCP two way

Yes, bullet number 4 defines perfectly the semantics of the inactive
attribute.

> 5) XXX: no RTP, no RTCP ???
> 
> Then what is used to specify the fifth item
> (no RTP, no RTCP)?

This is currently defined by setting the port number to zero. That is, I
offer you a particular media stream and you set its port to zero in the
200 OK. It means that no RTP and no RTCP will be sent over that media
stream.

This brings me to related topic:

Right now, once you have answer with port=zero, you cannot re-use that
stream during the session. That is, every re-INVITE you send will
contain that media line with the port set to zero, but media will never
flow to it.

It has been brought up (by 3GPP among others) that it might be useful to
be able to re-use that stream in a future. If I want to add a new media
stream to the session, I can use that media line by changing the port
number to a non-zero value in a re-INVITE.

Well, I am triggering a new discussion here (I would like to see
opinions on this), but I believe that the semantics of the inactive
attribute are pretty clear. 

Regards,

Gonzalo


> /sean
> 
> >-----Original Message-----
> >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> >Sent: Wednesday, August 22, 2001 1:30 PM
> >To: 'Colin Perkins'; Gonzalo Camarillo
> >Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> >Subject: RE: [Sip] Re: SDP hold
> >
> >
> >So, here is an important question on the inactive attribute.
> >If a stream is
> >inactive, is RTCP sent? I think it probably should,
> >actually... RTCP helps
> >to keep state alive in various places, and this session is
> >still alive, just
> >suspended.
> >
> >THoughts?
> >
> >-Jonathan R.
> >
> >
> >---
> >Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> >Chief Scientist                             First Floor
> >dynamicsoft                                 East Hanover, NJ 07936
> >jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> >http://www.jdrosen.net                      PHONE: (973) 952-5000
> >http://www.dynamicsoft.com
> >
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk]
> >> Sent: Wednesday, August 15, 2001 5:30 AM
> >> To: Gonzalo Camarillo
> >> Cc: Jonathan Rosenberg; sip@ietf.org; mmusic
> >> Subject: Re: [Sip] Re: SDP hold
> >>
> >> >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.
> >> >It can be either a session or media attribute, and is not
> >> dependent on
> >> >charset.
> >

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip