Re: [Sip] Manyfolks and re-INVITE

William Marshall <wtm@research.att.com> Thu, 13 September 2001 14:02 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04148 for <sip-archive@odin.ietf.org>; Thu, 13 Sep 2001 10:02:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09283; Thu, 13 Sep 2001 09:28:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09252 for <sip@ns.ietf.org>; Thu, 13 Sep 2001 09:28:42 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03122 for <sip@ietf.org>; Thu, 13 Sep 2001 09:28:35 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id C25554CF17 for <sip@ietf.org>; Thu, 13 Sep 2001 09:28:08 -0400 (EDT)
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA19413 for <sip@ietf.org>; Thu, 13 Sep 2001 09:28:07 -0400 (EDT)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA34674 for sip@ietf.org; Thu, 13 Sep 2001 09:30:26 -0400 (EDT)
Date: Thu, 13 Sep 2001 09:30:26 -0400
Message-Id: <200109131330.JAA34674@fish.research.att.com>
To: sip@ietf.org
Subject: Re: [Sip] Manyfolks and re-INVITE
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

The sequence to change codecs mid-session would be identical to that
to establish a new session.  The new media streams could require
authorization, need resource reservations, etc, etc, etc.  The new
media stream could even require "ringing" if the end user needs to
do anything prior to the UAS accepting the codec change.  If any
of this fails, the mid-session codec change fails.

Nothing in the protocol prevents 1xx provisional responses to a mid-session
INVITE.  Nor does anything prevent a mid-session PRACK.

Bill Marshall
wtm@research.att.com

-----original message-----
Date: Thu, 13 Sep 2001 16:00:54 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Subject: [Sip] Manyfolks and re-INVITE

Hi,

Another question related to the manyfolks draft.

If we want to send a mid-call re-INVITE, for example to change codecs, I
assume that we will have to do the same procedure as in the beginning of
the call, with the 18x-, PRACK-, and COMET messages.

Now, since there is nothing wrong by sending 1xx provisional responses
for a mid-call request, isn't the 18x responses defined for the call
setup procedure? Also, I've never seen any example of the use of
mid-call PRACKs, even if I guess it's not illegal from a protocol point
of view either.

Comments on this?

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sip mailing list  http://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