Subject: RE: [Sip] Re: SDP hold

From: "Christian Huitema" <[email-masked]>
Date: Mon, 27 Aug 2001 15:21:30 -0700

Yep. In fact, if you consider things like NAT traversal, you probably
want to also send a modicum of RTP packets for sessions that are on
hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are
going to loose your mappings, and the "going off hold" will be tricky.

-- Christian Huitema

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: Monday, August 27, 2001 2:43 PM
> To: 'Jonathan Rosenberg'; 'Colin Perkins'; 'Gonzalo Camarillo'
> Cc: [email-masked]; 'mmusic'
> Subject: RE: [Sip] Re: SDP hold
> 
> I sure think RTCP should be sent.
> 
> Dave.

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Aug 2001 19:11:03 -0400

> going to loose your mappings, and the "going off hold" will be tricky.

This is not a nice thing. I believe the current plan is to represent
going on hold changing SDP to a:sendonly or a:inactive. If you send me
SDP that says a:sendonly, then I am obligated to respond a:recvonly.
Once I have declared myself recvonly, do you really want me to send
on the RTP port? 

That is certainly an interesting interpretation of "recvonly".
I realize there are some important pragmatics going on here, but
it is really doing violence to the terminology.

	Paul Kyzivat
	Cisco Systems

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Aug 2001 19:11:03 -0400

Paul Kyzivat
	Cisco Systems

---

From: Christer Holmberg <@lmf.ericsson.se>
Date: Tue, 28 Aug 2001 09:28:09 +0300

Hi,

My question is: do we really care? To my understanding, the only thing
that SIP is concerned about is to put the actual MEDIA on hold - period.
The need, or no-need, of RTCP may then be depending on the network
architecture etc, and it's a bearer level issue, so it could be
configurable elsewhere.

We should remember that even if we put media on hold, we still have a
stream, and depending on the bearer network (IP, ATM,...) there may be
some "stream signalling" (RTCP, for example). So, if one really wants to
make sure that nothing is sent he/she may simply remove the stream
completely...

Regards,

Christer Holmberg
Ericsson Finland