[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] multiple bodies in any SIP message
SoFrom sip-bounces at ietf.org Tue Dec 16 13:48:59 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-web-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E559D3A68ED;
Tue, 16 Dec 2008 13:48:58 -0800 (PST)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9E89D3A6817
for <sip at core3.amsl.com>; Tue, 16 Dec 2008 13:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fAzD0exPz6Sj for <sip at core3.amsl.com>;
Tue, 16 Dec 2008 13:48:56 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
[IPv6:2001:470:1f03:267::2])
by core3.amsl.com (Postfix) with ESMTP id 627A328C16A
for <SIP at ietf.org>; Tue, 16 Dec 2008 13:48:56 -0800 (PST)
Received: from [192.168.2.6] (pool-173-71-54-32.dllstx.fios.verizon.net
[173.71.54.32]) (authenticated bits=0)
by nostrum.com (8.14.3/8.14.3) with ESMTP id mBGLmZGt027761
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Tue, 16 Dec 2008 15:48:36 -0600 (CST)
(envelope-from rjsparks at nostrum.com)
Message-Id: <7A11A8B8-CBA3-4122-B11C-82AECBC222CA at nostrum.com>
From: Robert Sparks <rjsparks at nostrum.com>
To: Hadriel Kaplan <HKaplan at acmepacket.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC3137F2915B0 at mail>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 16 Dec 2008 15:48:35 -0600
References: <94081CC4-F9BE-4651-BE3D-9D5CEDC3CA8D at standardstrack.com><CA9998CD4A020D418654FCDEF4E707DF05C0F98E at esealmw113.eemea.ericsson.se><F779DAF0-507D-4BB0-BA8C-C687F1C7BB30 at standardstrack.com><CA9998CD4A020D418654FCDEF4E707DF05C0F9E2 at esealmw113.eemea.ericsson.se><E6C2E8958BA59A4FB960963D475F7AC31374B1F09C at mail><CA9998CD4A020D418654FCDEF4E707DF05C0F9E8 at esealmw113.eemea.ericsson.se><E6C2E8958BA59A4FB960963D475F7AC31374B1F0DE at mail>A<CA9998CD4A020D418654FCDEF4E707DF05C0F9EB at esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D00152A3FA at GBNTHT12009MSX.gb002.siemens.net><CA9998CD4A020D418654FCDEF4E707DF09914975 at esealmw113.eemea.ericsson.se><E6C2E8958BA59A4FB960963D475F7AC3137BF583BB at mail><38C7BE1B-FCD6-4D6E-B28F-623A975D9D3E at softarmor.com><49380797.4030505 at cisco.com><2F93A72B-CE0A-4055-B558-0092D309818C at softarmor.com><CA9998CD4A020D418654FCDEF4E707DF05C0FA0B at esealmw113.eemea.ericsson.se>
<C21A219D-9EB9-4173-83FB-80F518439AEB at softarmor.com>
<E6C2E8958BA59A4FB960963D475! F 7AC3137 F 2905ED at mai l>
<CA9998CD4A020D418654FCDEF4E707DF05C0FA13 at esealmw113.eemea.ericsson.se>
<E6C2E8958BA59A4FB960963D475F7AC3137F29156E at mail>
<CA9998CD4A020D418654FCDEF4E707DF05C0FA15 at esealmw113.eemea.ericsson.se>
<E6C2E8958BA59A4FB960963D475F7AC3137F2915B0 at mail>
X-Mailer: Apple Mail (2.929.2)
Received-SPF: pass (nostrum.com: 173.71.54.32 is authenticated by a trusted
mechanism)
X-Virus-Scanned: ClamAV 0.94.2/8768/Tue Dec 16 13:28:09 2008 on
shaman.nostrum.com
X-Virus-Status: Clean
Cc: SIP List <SIP at ietf.org>, Paul Kyzivat <pkyzivat at cisco.com>,
Dean Willis <dean.willis at softarmor.com>,
Christer Holmberg <christer.holmberg at ericsson.com>
Subject: Re: [Sip] multiple bodies in any SIP message
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Sorry for the slight deviation from topic, but its probably worth re-
highlighting here
that CANCEL is hop-hop and isn't capable of carrying information end-
end (like what
you'd expect to see when using SDP). ACK-non200 is similar.
RjS
On Dec 6, 2008, at 8:38 PM, Hadriel Kaplan wrote:
-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: Saturday, December 06, 2008 4:09 PM
So if the SIP message has body-parts, and one of them is actually
not
intended for that package but is instead just a generic add-on, like
geoloc for example, we need to dis-ambiguate that add-on body-
part(s) from the others.
It should be defined in what SIP messages geoloc information may be
transported, and what the receiver supporting it is supposed to do
with
it. As we do for SDP. SDP in CANCEL has no meaning, for example, so
it
is seen as a protocol error to send SDP in CANCEL.
Geoloc may be transported in any SIP request, afaik - except ACK and
CANCEL. Putting a body in any/all messages which is not for the
context of the message is not without precedent, I've been told.
Maybe this is just the first time that we really expect it to be
used? :)
A content type of "application/sdp" can be used in any request that
can carry mime bodies as far as I know. It just wouldn't make sense
to make it's C-D "session" in anything but INVITE, ACK, PRACK, and
UPDATE; and for the SUB/NOT/PUB you'd have to define a package for
using it.
BTW, CANCEL can't carry any body, afaict, if for no other reason
than the Content-* headers needed to do so can't be used in CANCEL.
(nor would we want it to be able to, for obvious reasons)
-hadriel
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
rry for the slight deviation from topic, but its probably worth re-
highlighting here
that CANCEL is hop-hop and isn't capable of carrying information end-
end (like what
you'd expect to see when using SDP). ACK-non200 is similar.
RjS
On Dec 6, 2008, at 8:38 PM, Hadriel Kaplan wrote:
-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: Saturday, December 06, 2008 4:09 PM
So if the SIP message has body-parts, and one of them is actually
not
intended for that package but is instead just a generic add-on, like
geoloc for example, we need to dis-ambiguate that add-on body-
part(s) from the others.
It should be defined in what SIP messages geoloc information may be
transported, and what the receiver supporting it is supposed to do
with
it. As we do for SDP. SDP in CANCEL has no meaning, for example, so
it
is seen as a protocol error to send SDP in CANCEL.
Geoloc may be transported in any SIP request, afaik - except ACK and
CANCEL. Putting a body in any/all messages which is not for the
context of the message is not without precedent, I've been told.
Maybe this is just the first time that we really expect it to be
used? :)
A content type of "application/sdp" can be used in any request that
can carry mime bodies as far as I know. It just wouldn't make sense
to make it's C-D "session" in anything but INVITE, ACK, PRACK, and
UPDATE; and for the SUB/NOT/PUB you'd have to define a package for
using it.
BTW, CANCEL can't carry any body, afaict, if for no other reason
than the Content-* headers needed to do so can't be used in CANCEL.
(nor would we want it to be able to, for obvious reasons)
-hadriel
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip