Subject: Re: [Sip] Re: SDP hold

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 Aug 2001 17:32:05 +0300

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:[email-masked]]
> >Sent: Wednesday, August 22, 2001 1:30 PM
> >To: 'Colin Perkins'; Gonzalo Camarillo
> >Cc: Jonathan Rosenberg; [email-masked]; 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
> >[email-masked]                     FAX:   (973) 952-5050
> >http://www.jdrosen.net                      PHONE: (973) 952-5000
> >http://www.dynamicsoft.com
> >
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[email-masked]]
> >> Sent: Wednesday, August 15, 2001 5:30 AM
> >> To: Gonzalo Camarillo
> >> Cc: Jonathan Rosenberg; [email-masked]; 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                              [email-masked]

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Vijaya Venkatachalam <[email-masked]>
Date: Mon, 27 Aug 2001 13:53:02 -0400

Hi,

Which all interfaces in 3GPP are using SIP?

Thanks,
Vijaya

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 27 Aug 2001 17:56:53 -0500

That's actually a question better asked in 3GPP SA2. They have a slew of
interfaces, each with a symbolic name like "The Sh interface".  There's also
some debate between various 3GPP groups as to which interfaces exist and
what to call them, for example "SIP+" and "ISC" interface(s).

In general, SIP is used between UE and P-CSCF, P-CSCF and P-CSCF,  P-CSCF
and I-CSCF, I-CSCF and S-CSCF, S-CSCF and AS, and AS-AS, and of course the
inverses of those. There's some debate about whether AS may also directly
interface to other SIP nodes withot using S-CSCF and I-CSCF, or may go
directly to I-CSCF or other firewall proxy without transiting S-CSCF. Mine
can -- why pay extra for more S-CSCF than one really needs? But it's
configurable so that people who really want to spend more money can do so .
. . Free enterprise loves Darwin's dead-end branches if they're well-funded.
There's also another edge-proxy node called a THIG that may appear in
various locations and speaks SIP.

--
Dean

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 29 Aug 2001 19:36:52 +0300

Just to add a few more interfaces using SIP in 3GPP.
The S-CSCF and BGCF, BGCF and BGCF, BGCF and MGCF, and S-CSCF and MRF.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: Vijaya Venkatachalam <[email-masked]>
Date: Wed, 29 Aug 2001 12:59:55 -0400

Hi Miguel,

For the BGCF to BGCF and the BGCF to MGCF, isn't TRIP
a better choice than SIP.

Vijaya

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 30 Aug 2001 07:34:47 +0300

> a better choice than SIP.

No, they are complementary protocols: SIP is the session control protocol,
whereas TRIP is good to exchange routes to the PSTN. Definitely it is possible
to run TRIP across BGCFs and TRIP for gateways between the MGCF and the BGCF.
These are not part of 3GPP Release 5, but certainly it is a possibility to 
explore for future releases. But still you need SIP to route the session.

/Miguel