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

Alex Bligh <alex@alex.org.uk> Thu, 18 March 2004 20:26 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06606 for <sip-archive@odin.ietf.org>; Thu, 18 Mar 2004 15:26:04 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4459-0001Ya-Vh for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 15:25:36 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IKPZxK005924 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 15:25:35 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B444c-0001Vg-Q8; Thu, 18 Mar 2004 15:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4447-0001UG-I3 for sip@optimus.ietf.org; Thu, 18 Mar 2004 15:24:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06499 for <sip@ietf.org>; Thu, 18 Mar 2004 15:24:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4446-0000yo-00 for sip@ietf.org; Thu, 18 Mar 2004 15:24:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B443G-0000uT-00 for sip@ietf.org; Thu, 18 Mar 2004 15:23:38 -0500
Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1B442F-0000pV-00 for sip@ietf.org; Thu, 18 Mar 2004 15:22:35 -0500
Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id ED7F61FE69; Thu, 18 Mar 2004 20:22:31 +0000 (GMT)
Date: Thu, 18 Mar 2004 20:22:27 +0000
From: Alex Bligh <alex@alex.org.uk>
Reply-To: Alex Bligh <alex@alex.org.uk>
To: sip@ietf.org
Cc: Alex Bligh <alex@alex.org.uk>
Message-ID: <1393468762.1079641347@[192.168.100.5]>
X-Mailer: Mulberry/3.1.1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip