RE: [Sipping] Re: New Draft on TISPAN analysis for SIP solutionsconcerning the simulation Services

"Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com> Tue, 05 July 2005 21:35 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpv4m-0000fd-JP; Tue, 05 Jul 2005 17:35:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpv4j-0000dp-Sn for sipping@megatron.ietf.org; Tue, 05 Jul 2005 17:35:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02514 for <sipping@ietf.org>; Tue, 5 Jul 2005 17:35:23 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpvKD-0000rk-0S for sipping@ietf.org; Tue, 05 Jul 2005 17:51:32 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7B3A64F0001; Tue, 5 Jul 2005 23:23:31 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 23:23:30 +0200
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 23:23:30 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Sipping] Re: New Draft on TISPAN analysis for SIP solutionsconcerning the simulation Services
Date: Tue, 05 Jul 2005 23:23:29 +0200
Message-ID: <D60C37C9EF5C39459E0F4EF508E560A2CDC486@esealmw113.eemea.ericsson.se>
Thread-Topic: [Sipping] Re: New Draft on TISPAN analysis for SIP solutionsconcerning the simulation Services
Thread-Index: AcWBZKFdLDV5QIeESh2hq9YJ3GhoxAAQarHQ
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: David R Oran <oran@cisco.com>, Miguel Garcia <Miguel.An.Garcia@nokia.com>
X-OriginalArrivalTime: 05 Jul 2005 21:23:30.0203 (UTC) FILETIME=[CA36AEB0:01C581A7]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Content-Transfer-Encoding: quoted-printable
Cc: sipping WG <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Hi David,

This mail is not specific to the AoC service, but more to the generic issue about message body processing by proxies.

RFC3261 says that a "pure" proxy must not add to, modify or remove a message body (if it does, it will become a B2BUA, or whatever we want to call it...).

However, does RFC3261 forbid a "pure" proxy from inserting a new body? That is, if I understood correctly, what you are proposing in the AoC case. At least I can't find any text in RFC3261 preventing it.

Having said that, however, I guess it really goes down to the details what we mean by "modifying a message body". 

For example, a proxy receives an SDP body in a SIP response. It now adds a new X body to the SIP response, without touching the SDP data, and forwards the response.

Now, if we only look at the separate bodies (SDP and X) I guess it should be allowed, because the proxy has not modified the SDP body data it received - it just added a new X body.

BUT, from a SIP message perspective the message body HAS been modified, from SDP to multipart/MIME (needed to carry both the SDP body and the X body) - again, even if the SDP data hasn't changed.

So, IS it ok by a proxy to add new bodies, as long as the existing bodies don't change, even if they may be grouped differently from a SIP message perspective (from SDP to multipart mime, for example)?

Regards,

Christer
LM Ericsson




> -----Original Message-----
> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On
> Behalf Of David R Oran
> Sent: 5. heinäkuuta 2005 16:19
> To: Miguel Garcia
> Cc: sipping WG
> Subject: Re: [Sipping] Re: New Draft on TISPAN analysis for SIP
> solutionsconcerning the simulation Services
> 
> 
> Would you please provide justification in the draft for why this  
> should be a header and not a body? I can't for the life of me figure  
> out why this can't be done with a body (which would require  
> essentially no change to SIP, only a MIME registration) since 
> proxies  
> do nothing with the header I can discern.
> 
> Thanks, Dave.
> 
> On Jul 1, 2005, at 2:56 AM, Miguel Garcia wrote:
> 
> 
> > And I have also submitted another draft that proposes a P- header  
> > to support the Advice of Charge service.
> >
> > Until the draft is officially distributed, it can be retrieved from:
> >
> > http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-etsi- 
> > ngn-p-headers-00.txt
> >
> > /Miguel
> >
> > Jesske, R wrote:
> >
> >
> >
> >> Dear all,
> >> A new draft regarding the analysis of the requirements on TISPAN  
> >> simulation services as described in draft-jesske-sipping-tispan- 
> >> requirements-01  is now available.
> >> It can be fond under:
> >> http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispan- 
> >> analysis-00.txt We would like to start the discussion on 
> solutions  
> >> for the requirements we stated in draft-jesske-sipping-tispan- 
> >> requirements-01 (http://www.ietf.org/internet-drafts/draft-jesske- 
> >> sipping-tispan-requirements-01.txt).
> >> This draft should be seen as a discussion basis and brainstorming  
> >> of some people thinking about SIP solutions.
> >> Every comment and discussion is welcome and helps to find 
> a solution.
> >> Thank you.
> >> Best Regards
> >> Roland
> >> Deutsche Telekom AG
> >> T-Com Zentrale
> >> Roland Jesske, TE332-2
> >> Section TE33; Signalling, Gateways and Switching Systems
> >> Am Kavalleriesand 3, 64295 Darmstadt, Germany
> >> Phone:  +49 6151 83-5940
> >> Fax:      +49 6151 83-4577
> >> email:   r.jesske@t-com.net
> >>
> >>
> >
> > -- 
> > Miguel A. Garcia           tel:+358-50-4804586
> > sip:miguel.an.garcia@openlaboratory.net
> > Nokia Research Center      Helsinki, Finland
> >
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> >
> >
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP