Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER?

gao.yang2@zte.com.cn Wed, 13 October 2010 08:12 UTC

Return-Path: <gao.yang2@zte.com.cn>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FEF3A67D4 for <sipcore@core3.amsl.com>; Wed, 13 Oct 2010 01:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.072
X-Spam-Level:
X-Spam-Status: No, score=-100.072 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
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 SrNRlT0JYZYq for <sipcore@core3.amsl.com>; Wed, 13 Oct 2010 01:12:58 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 80E383A67B6 for <sipcore@ietf.org>; Wed, 13 Oct 2010 01:12:57 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Wed, 13 Oct 2010 16:11:43 +0800 (CST)
Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.3337783744; Wed, 13 Oct 2010 16:13:58 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9D8Ar7M013547; Wed, 13 Oct 2010 16:10:53 +0800 (CST) (envelope-from gao.yang2@zte.com.cn)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DB6B2E@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006
Message-ID: <OFCA036CC4.B32F19B9-ON482577BB.00295E76-482577BB.002CE9FF@zte.com.cn>
From: gao.yang2@zte.com.cn
Date: Wed, 13 Oct 2010 16:08:34 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-13 16:10:40, Serialize complete at 2010-10-13 16:10:40
Content-Type: multipart/alternative; boundary="=_alternative 002CE9FD482577BB_="
X-MAIL: mse3.zte.com.cn o9D8Ar7M013547
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2010 08:12:59 -0000

> As far as I know, there are no explicit restrictions.
> 
> One could, however, ask whether it's allowed to include headers that
> are not to be used in the triggered INVITE, but in later associated 
requests.

RFC3261 section 19.1.5

An implementation MUST include any provided transport, maddr, ttl, or
   user parameter in the Request-URI of the formed request.  If the URI
   contains a method parameter, its value MUST be used as the method of
   the request.  The method parameter MUST NOT be placed in the
   Request-URI.  Unknown URI parameters MUST be placed in the message's
   Request-URI.

   An implementation SHOULD treat the presence of any headers or body
   parts in the URI as a desire to include them in the message, and
   choose to honor the request on a per-component basis.

An implementation SHOULD NOT honor these obviously dangerous header
   fields: From, Call-ID, CSeq, Via, and Record-Route.

>From the above text, it seams that the rules for embedded headers is not 
as emphatic as transport, maddr, ttl and user parameter. So, I suggest 
that one specific embedded headers could have a specific usage guidelines, 
especially these headers with dangerous header fields.

I'd like to point out that I am not going to say that people's 
understanding of embedded headers(for pure audio usage) is not correct.

> You CAN also embed SDP information.

Are there any defined rules for such embedded SDP information? If there 
are, could you show me.

Thanks,

Gao


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.