Subject: RE: [Sip] Re: SDP hold

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Aug 2001 03:25:41 -0400

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 10:32 AM
> To: Sean Olson (EUS)
> Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; [email-masked]'; 'mmusic'
> Subject: Re: [Sip] Re: SDP hold
> 
> 
> > 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.

Well, this is a little bit different. Port zero means "tear down this
stream". This would result, for example, in the closure of any windows that
were popped up for video rendering of the stream. I think Sean's case is
where we neither send RTP/RTCP, but the stream is only temporarily suspended
and can be revived. A better question, is whether we really need this
additional case. I'd rather limit them to things we really need.

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

Hmm, I though I had sent out an email on this open issue as well.... I'll
resend if I don't see it in the archives.

-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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Aug 2001 16:09:52 +0300

Hi,

I think it would be a good idea to bring this question to the Megaco
mailing list. There are lots of people working on Media Gateways there,
so maybe they have some kind of solution for this.

I can write down a few lines, and also CC the mail to the SIP list
(since I guess most of us aren't on the Megaco list...).

Regards,

Christer Holmberg
Ericsson Finland

Jonathan Rosenberg wrote:
> _______________________________________________
> 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: Gonzalo Camarillo <[email-masked]>
Date: Fri, 24 Aug 2001 18:00:47 +0300

Hello Christer,

> so maybe they have some kind of solution for this.

Well, feel free to forward this mail to the MEGACO list.

Regards,

Gonzalo

-- 
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]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 24 Aug 2001 18:06:57 +0300

Hello,

> additional case. I'd rather limit them to things we really need.

Yes, I agree that we do not want to resolve theoretical problems. We
have enough "real" problems to work on.

Anyway, if we do not want to *receive* neither RTP nor RCTP we set
c=0.0.0.0
If we do not want to *send* RTP we mark the stream as recvonly or
inactive.
We only have to figure out how to signal the fact that we will not
*send* RCTP.

If, as Jonathan suggested, somebody needs this capability (he or she
should speak up) we can work on it.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Aug 2001 16:54:46 +0300

Hi,

I am not sure I like the use of c=0.0.0.0 for putting RTCP on "hold",
for the same reason I don't like it for putting RTP on hold: when people
start sending RTP/RTCP using IPv6 we have to define a new mechanism
anyway...

So, I think we should define a long-term solution, which is not
dependent on the IP version - or whatever protocol/network we use. One
though could be to define the RTCP as a separate stream. But then I
guess the problem is to "map" the RTCP to RTP, especially in an
multistream environment.

Regards,

Christer Holmberg
Ericsson Finland