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

From: Alex Bligh <[email-masked]>
Date: Thu, 18 Mar 2004 20:22:27 +0000

100% of the 2(!) vendors I have tested do not appear to send any media
stream packets unidirectionally (when one end is muted) or bidirectionally
(re-invite when other party put on hold by UA). This appears not to be in
conflict with any standard. However, I feel (perhaps incorrectly) a media
keepalive would be useful so intervening NAT/f/w stuff stays open. Clearly
this is simple in the mute case (as the muted device can just send whatever
it likes when it likes), but how about in the re-invite case where the UA
appears to be being told "no I don't want a media stream". Is there some
way of saying "but I have to send you a very small keepalive media stream
or the transient entry in my stateful mid-device will disappear, and please
don't send me port-unreachables either"?

The other reason this would be useful is it would allow UAs (including
media gateways) to reliably respond to lack of media stream (RTP etc.) and
shut down a hanging SIP session - from what I can see with the UAs I'm
looking at, one side putting the other on hold, or both ends being on mute,
is going to tear down a SIP session if this sort of switch is enabled
without keepalives.

Alex

_______________________________________________
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, 18 Mar 2004 18:02:53 -0500

Alex,

You are raising two separate issues:

1) how the receiver knows the sender is still there when muted
    or on hold

2) how stupid devices like nats and fws know the stream is still
    active (so the path is preserved) in the same situations

For (1), the answer is supposed to be RTCP. Even when a stream is on 
hold (via SENDONLY or INACTIVE) RTCP is supposed to flow.

But (2) is more difficult. Ideally the stupid devices would be smart 
enough to use the same answer as (1). If they don't, then something will 
need to dribble thru the RTP stream.

The issue of what devices actually do this is another matter altogether.

	Paul

---

From: Alex Bligh <[email-masked]>
Date: Thu, 18 Mar 2004 23:25:11 +0000

[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:

>     active (so the path is preserved) in the same situations

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.

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?

> For (1), the answer is supposed to be RTCP. Even when a stream is on hold
> (via SENDONLY or INACTIVE) RTCP is supposed to flow.

OK. It doesn't (where I've looked) but as you point out, that's a separate
issue. Also it seems to me this will break for the same reason as below

> need to dribble thru the RTP stream.

Sadly we are stuck with stupid devices; if we didn't, we wouldn't need
a number of other bodges either. For the same reason we seem to need
STUN et al., I don't think this will work in practice.

Alex

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Mar 2004 14:56:46 -0500

>   how should a UA detect a stale session?

It is *always* acceptable to close the connection, whether the media 
stream is operational or not. (You can hangup whenever you like.)

Converses don't always follow, but I think it is true that you must not 
remove a media session without first either terminating the session or 
else renegotiating the session to remove the media stream. As a result, 
I think a non-functional media stream is indicative that something is 
wrong with the call.

I do think there should be some standardized handling of error 
conditions in order to further interoperability in the face of errors. 
This is important so that fault tolerance can be achieved in 
heterogeneous systems.

For instance, if an endpoint detects a problem with a media stream, it 
should probably test the signaling path and other endpoint by sending a 
reinvite. (This will not only test the path, but it provides an 
opportunity for kicking a fault tolerant backup into action.)

If the reinvite fails, it is appropriate to terminate the connection. If 
it succeeds, but problems with the media stream persist, then further 
actions may be required - e.g. changing the media termination parameters 
at one or both ends. Right now this is hard, because the two ends don't 
necessarily have the same understanding of what the current status is, 
and there isn't any standard way of saying this particular reinvite is 
for the purpose of fixing media problems.

	Paul

---

From: Alex Bligh <[email-masked]>
Date: Tue, 23 Mar 2004 22:14:45 +0000

--On 22 March 2004 14:56 -0500 Paul Kyzivat <[email-masked]> wrote:

> else renegotiating the session to remove the media stream. As a result, I
> think a non-functional media stream is indicative that something is wrong
> with the call.

So, to be clear, a UA wishing to keep the call alive [SHOULD|MUST] not
terminate a media stream without signaling this via renegotiation? (as
otherwise it could be mistaken for a fault which the other UA and/or media
proxies on the way MAY take as an indication to drop the call). IE is this
is SHOULD NOT or a MUST NOT?

Alex

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Mar 2004 17:43:12 -0500

> is SHOULD NOT or a MUST NOT?

Hmm. I don't know which would be better.

I also don't know where such normative language would go. It will 
probably be tricky to get this right - to precisely define "terminate a 
media stream". The details of that are almost certainly media dependent.

In case of SDP, maybe it means "stop sending SRTP".

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Mar 2004 04:46:38 -0500

Some comments inline.

>> 1) how the receiver knows the sender is still there when muted

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.

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

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.

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

>   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

---

From: Alex Bligh <[email-masked]>
Date: Thu, 25 Mar 2004 11:25:07 +0000

> recently proposed RTP no-op payload

that would solve most of my issues - I had missed that.

> If the media session dies, and one end detects this, it should send a BYE
> rather than just giving up.

You are presupposing it is detectable. In order to be able to distinguish
between a dead (or half dead) media session, and merely that one end has
intentionally stopped streaming media, you either have to mandate the use
of a no-op payload, or mandate a reinvite. The latter only partly solves
the problem in that it doesn't particularly help the dumb (non-SIP
inspecting) firewall/NAT in the middle.

I can't help thinking though that it should be mandatory that if the
underlying media stream changes (e.g. mute is pressed AND the UA no longer
wants to send a media stream, or if hold is pressed and the UA no longer
wants to send or receive a media stream), then a reinvite is sent, rather
than unilaterally changing something which has been negotiated by SIP. Then
we just have the issue of whether a keepalive no-op media stream is better
than none at all (which is more a media issue than a SIP issue per se).
Whether a UA uses "the recently proposed no-op payload" (haven't seen
that) or (if the other end doesn't support it), merely sends the occasional
packet of (in audio terms) silence using a supported CODEC, would be
down to implementation.

Alex

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Mar 2004 09:20:39 -0500

> BYE rather than just giving up.

I agree that just giving up is bad, and that sending BYE is a better 
alternative. But it isn't the only one.

In this situation it makes some sense to try to diagnose and possibly 
repair the situation. For diagnosis, one thing to do is to test the 
signaling path by sending a reinvite or update. If the reinvite 
succeeds, and didn't change the media descriptions, and media still 
doesn't flow, then it might help to try changing things in the media path.

This is all stuff that will happen implicitly if you send a BYE and then 
one of the users retries the call, which is a common action when your 
phone call goes dead or is unexpectedly disconnected. Doing it 
automatically would provide a better user experience.

Reinviting has another potential benefit: if the far end is redundant, 
the reinvite might trigger a failover to the backup, and therefore fix a 
call that wouldn't otherwise be fixed.

I think this is preferable to sending BYE because it does no harm. 
Automatically sending BYE may kill a call that might have eventually 
recovered. It removes a degree of choice from the user. The user always 
has the option to hangup (hence send BYE) when he gets tired of 
listening to nothing. (This assumes there is a user controlling the UA. 
If it is an automated device the choices should be different.)

	Paul