Subject: RE: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE

From: "Steve Langstaff" <[email-masked]>
Date: Thu, 25 Mar 2004 10:59:30 -0000

Some comments inline.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 25 March 2004 09:47
> To: Alex Bligh
> Cc: Paul Kyzivat; [email-masked]
> Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold
> etc, & SIP INVITE
> 
> 
> Some comments inline.
> 
> Alex Bligh wrote:
> 
> > 
> > [email-masked] wrote:
> > 
> >> This email thread starting with an implementors query on 
> session refresh
> >> for billing (yes again) but now has a life of it's own!.
> > 
> > 
> > Yes - but I'm not on a billing thread - too dangerous 
> ground. My take on
> > that is SIP should clear up properly. If that happens, the 
> billing should
> > take care of itself. But the question asked raised some 
> other questions.
> > 
> > I am actually asking 4 separate questions, I guess. Paul has 2:
> > 
> > --On 18 March 2004 18:02 -0500 Paul Kyzivat 
> <[email-masked]> wrote:
> > 
> >> You are raising two separate issues:
> >>
> >> 1) how the receiver knows the sender is still there when muted
> >>     or on hold
> 
> As Paul poitned out, RTCP is indeed for this purpose. This is 
> discussed 
> in RFC 3263, for example:
> 
> For recvonly and sendrecv streams, the port number and address in the
>     offer indicate where the offerer would like to receive the media
>     stream.  For sendonly RTP streams, the address and port number
>     indirectly indicate where the offerer wants to receive 
> RTCP reports.
>     Unless there is an explicit indication otherwise, reports 
> are sent to
>     the port number one higher than the number indicated.
> 
> which I think is clear that RTCP is still sent in the sendonly and 
> recvonly cases.
> 
> >>
> >> 2) how stupid devices like nats and fws know the stream is still
> >>     active (so the path is preserved) in the same situations
> 
> Now, this is a good question.
> 
> One option is to not actually signal hold using 
> sendonly/recvonly/inactive. Rather, if I put you on hold, I change 
> codecs so that the only media I'll accept is the comfort 
> noise payload, 
> or the more recently proposed RTP no-op payload which was defined for 
> this purpose. Or, even more extreme, don't signal anything - 
> implement 
> hold as purely a local UI operation. In both cases, the other 
> side may 
> not properly determine that you've put them on hold (one can debate 
> whether that is important). The latter approach will work off 
> the shelf 
> today and not require any kind of new protocol support from the other 
> end of the call.

Could sendonly/recvonly/inactive be modified so that they (can) periodically send no-op or CNG payloads to keep the NAT/Firewall happy, or do these RTP states preclude the sending of ANY RTP? 

With hindsight, should RTCP have used the same port pair as the associated RTP?

Implementing hold as a local UI operation would mean that the (held) source is still using bandwidth. If I'm at the end of a narrow pipe I'd probably not want my bandwidth used up by audio that I know is going to be junked, if at all possible.

> Another option is ICE, which uses STUN to do connectivity checks. It 
> makes sense to continue those checks during the session, for the 
> purposes of keeping the bindings active, and checking, in fact, that 
> they have not changed. The benefit here is that you can still signal 
> hold using sendonly/sendrecv/inactive; the checks using ICE 
> would occur 
> no matter what the value of these attributes.
> 
> Currently, ICE doesnt do mid-session keepalives, but that is 
> easily changed.
> 
> 
> > 
> > 
> > 3) how can a UA behind the stupid device, detected via STUN 
> or otherwise,
> >   in (2) negotiate via SIP that it needs a (desultory) 
> media stream to
> >   continue when the other end puts it on hold / mute etc.
> 
> That is addressed above. ICE has its own SDP attributes that 
> signal its 
> usage.
> 
> > 
> > 4) When is it acceptable (standards wise) to clear up a SIP 
> session when
> >   the media stream (be it RTP or RTCP one looks at) dies? 
> Can one assume
> >   that if the media stream dies, it is OK to close the 
> connection? If so,
> >   the converse must apply, i.e. that it is not OK to remove 
> the media
> >   session without renegotiation (and if so, every (all 2) UA's I've
> >   looked at are doing something wrong but that's a separate 
> issue). If not,
> >   how should a UA detect a stale session?
> 
> If the media session dies, and one end detects this, it should send a 
> BYE rather than just giving up.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  https://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
> 

--
Steve Langstaff.

_______________________________________________
Sip mailing list  https://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: Thu, 25 Mar 2004 09:35:37 -0500

> Could sendonly/recvonly/inactive be modified so that they (can) periodically send no-op or CNG payloads to keep the NAT/Firewall happy, or do these RTP states preclude the sending of ANY RTP? 

Of course they *could* be modified to permit this. But more would be 
needed - to negotiate whether they *should* periodically send no-ops.

>>Currently, ICE doesnt do mid-session keepalives, but that is 

amounts to the same thing using a different sort of no-op, and different 
notation in SDP to negotiate it. If the problem is NATs, and ICE is 
needed anyway for NATs, then this may be attractive.

In addition to changing ICE, this would also require further changes to 
RTP implementations to deal with mid-session ice messages.

	Paul