RE: [Sip] Question on RFC3840/3841
"Christer Holmberg" <christer.holmberg@ericsson.com> Fri, 18 January 2008 09:28 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnWQ-0007V4-8A; Fri, 18 Jan 2008 04:28:22 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFnWP-0007Ux-2C for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 04:28:21 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnWO-0007Up-Lj for sip@ietf.org; Fri, 18 Jan 2008 04:28:20 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFnWN-0005I9-DD for sip@ietf.org; Fri, 18 Jan 2008 04:28:20 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5BDA520E10; Fri, 18 Jan 2008 10:28:00 +0100 (CET)
X-AuditID: c1b4fb3c-aaaedbb0000007e0-45-4790712038da
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 40B3220DD8; Fri, 18 Jan 2008 10:28:00 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 10:27:59 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Question on RFC3840/3841
Date: Fri, 18 Jan 2008 10:27:59 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF041F586C@esealmw113.eemea.ericsson.se>
In-Reply-To: <478633C4.2060209@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Question on RFC3840/3841
Thread-Index: AchTmf6noFFXdaVITfq5Wi/PDr3BpAGGXRgA
References: <CA9998CD4A020D418654FCDEF4E707DF03F7A681@esealmw113.eemea.ericsson.se> <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> <CA9998CD4A020D418654FCDEF4E707DF03FA6BD8@esealmw113.eemea.ericsson.se> <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> <478629C1.5090404@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF03FD0FDC@esealmw113.eemea.ericsson.se> <478633C4.2060209@cisco.com>
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, sip@ietf.org
X-OriginalArrivalTime: 18 Jan 2008 09:27:59.0797 (UTC) FILETIME=[6AA0D650:01C859B4]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
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>
Errors-To: sip-bounces@ietf.org
Hi Paul, >RFC3840 by itself, without 2533, is *not* sufficient to >understand how to do the matching. > >I put an appendix in RFC 4596 that gives an algorithm without >reference to 2533. I *think* it is right, but of course it is >not normative. > >Note that IMO none of this is intuitive or straightforward. >Every time I get a detailed question on it I have to do a >bunch of review before I can answer it. (But maybe that's >just because I don't have enough neurons left.) And I thought SIP was supposed to be easy... One question: In chapter 6 (I guess that is what you call the annex) of 4596 you say: "The simplification is primarily because a particular feature tag may only appear once in each Contact, Accept-Contact, or Reject-Contact header." However, as seen before, a particular feature tag may appear more than once, but in different A-C headers (or ac-values within a single header). For example: Accept-Contact: *;tagQ Accept-Contact: *;tagQ And, from a matching perspective, does it really matter if the feature tags were taken from one or more A-C headers? For example: Isn't: Accept-Contact: *;tagY,tagW ...identical to: Accept-Contact: *;tagY Accept-Contact: *;tagW ...or: Accept-Contact: *;tagY, *;tagW They will all cause: (& (tagY) (tagW)) Or? Regards, Christer > > Paul > > Christer Holmberg wrote: > > Paul, > > > > Regarding the matching, are you saying that reading RFC3840 > is enough > > to understand how the matching is done in a "SIP > environment"? Or, do > > I also need to read RFC2533? > > > > I have some questions on the matching, but I will come back to them > > later. I still have some reading to do. > > > > Regards, > > > > Christer > > > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 10. tammikuuta 2008 16:21 > >> To: Mahesh Anjanappa > >> Cc: Christer Holmberg; sip@ietf.org > >> Subject: Re: [Sip] Question on RFC3840/3841 > >> > >> > >> > >> Mahesh Anjanappa wrote: > >>> Yes the ';' is a mistake. But i'm not sure if each > Contact should > >>> contain "alice@atlanta.com" > >> Well, it has to have a URI to be syntactically correct. > >> > >> Your problem is that you are trying to express something > that cannot > >> be expressed with the callee caps syntax. It only maps to > a subset of > >> the syntax supported by RFC 2533. > >> > >>> because the predicate that i'm trying to represent is as follows > >>> meanig to say alice supports a communication which whose > >> capability is > >>> Duplex Audio + One Way Video. > >> You just can't say that. Sorry. > >> > >> A little history may help you to understand, though it won't solve > >> your > >> problem: > >> > >> The initial draft for callerprefs came out a very long > time ago. (The > >> earliest draft I have is -03 which came out in november of > 2000.) It > >> set the basic syntax and the initial set of capabilities. > >> > >> It was however very weak on the semantics of matching. I > eventually > >> got involved because I was interested in it and identified many of > >> the semantic issues. Jonathan and I worked on it for a long time. > >> Eventually, because of some review comments I think, > Jonathan tried > >> to define the semantics using RFC 2533 because it was a > standard that > >> seemed to be at least partially suitable to the task. (In > retrospect > >> this may not have been such a good idea, since it adds an > additional > >> layer of complexity.) > >> > >> RFC 2533 syntax is much richer. But it was not a goal to > provide that > >> richness. (Mapping that all onto SIP header syntax would > be awful.) > >> It was only used as an intermediate form to define the > semantics of > >> the SIP headers. > >> > >> Its understood that there are lots of things one might want to > >> express that you can't express. > >> > >> If you aren't already aware of it, you might want to look > at RFC 4596 > >> (Guidelines for Usage of the Session Initiation Protocol > (SIP) Caller > >> Preferences Extension). > >> > >> Paul > >> > >>> If each of the COntact contains alice@atlanta.com wouldnt it be > >>> interpreted as " alice supports duplex audio and oneway video > >>> separatley and not both at the same time". > >>> Actually i'm not quite sure how to represesnt the > predicate in the > >>> Contact header correctly, hence my Queries. It all stems from the > >>> statement which you too noted " There MUST only be one > >> instance of any > >>> feature tag in feature-param." in RFC 3840 > >>> > >>> > >>> Predicate: > >>> ------------ > >>> & ( & (sip.audio) (sip.duplex=full) ) > >>> ( & (sip.video) (sip.duplex=receive-only) ) > >>> > >>> regards > >>> Mahesh > >>> ----- Original Message ----- From: "Christer Holmberg" > >>> <christer.holmberg@ericsson.com> > >>> To: "Mahesh Anjanappa" <mahesha@samsung.com>; "Paul Kyzivat" > >>> <pkyzivat@cisco.com> > >>> Cc: <sip@ietf.org> > >>> Sent: Thursday, January 10, 2008 11:30 AM > >>> Subject: RE: [Sip] Question on RFC3840/3841 > >>> > >>> > >>> > >>> Shouldn't each Contact also contain "alice@atlanta.com"? > >>> > >>> Also, why do you have ";" at the end of each Contact? > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Mahesh Anjanappa [mailto:mahesha@samsung.com] > >>>> Sent: 10. tammikuuta 2008 6:16 > >>>> To: Paul Kyzivat > >>>> Cc: sip@ietf.org; Christer Holmberg > >>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>> > >>>> hi Paul, > >>>> Sorry there is a mistake in Contact header i > described.Following is > >>>> what i wanted to: > >>>> Contact:sip:alice@atlanta.com; > >>>> Contact:audio;duplex=full; > >>>> Contact:video;duplex=recieve-only; > >>>> > >>>> Thanks > >>>> Mahesh > >>>> ----- Original Message ----- > >>>> From: "Mahesh Anjanappa" <mahesha@samsung.com> > >>>> To: "Paul Kyzivat" <pkyzivat@cisco.com> > >>>> Cc: <sip@ietf.org>; "Christer Holmberg" > >>>> <christer.holmberg@ericsson.com> > >>>> Sent: Wednesday, January 09, 2008 10:48 PM > >>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>> > >>>> > >>>>> Thanks Paul. > >>>>> So would it be right if i have a Contact Headers describing > >>>> Duplex Audio & > >>>>> one-way Video Capabilities as follows? > >>>>> > >>>>> Contact:sip:alice@atlanta.com; > >>>>> Contact:sip:audio;duplex=full; > >>>>> Contact:sip:video;duplex=recieve-only; > >>>>> > >>>>> NOTE: The Predicate(for above) for which i'm attempting > is & ( & > >>>>> (sip.audio) (sip.duplex=full) ) > >>>>> ( & (sip.video) (sip.duplex=receive-only) ) > >>>>> > >>>>> regards > >>>>> Mahesh > >>>>> > >>>>> ----- Original Message ----- > From: "Paul Kyzivat" > >>>> <pkyzivat@cisco.com> > >>>>> To: "Mahesh Anjanappa" <mahesha@samsung.com> > >>>>> Cc: "Christer Holmberg" <christer.holmberg@ericsson.com>; > >>>> <sip@ietf.org> > >>>>> Sent: Wednesday, January 09, 2008 7:55 PM > >>>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>>> > >>>>> > >>>>>> > >>>>>> Mahesh Anjanappa wrote: > >>>>>>> hi > >>>>>>> That is my understanding as well. But if that is the case > >>>> then it should > >>>>>>> apply to Contact header as well > >>>>>>> when describing Capabilities using Feature parameters in > >>>> Contact Header. > >>>>>>> But i'm not sure if it applies the same way. I had posted > >>>> this question > >>>>>>> long ago but didnt get any comments on it. > >>>>>> The rule forbidding multiple instances of a parameter > >>>> applies to all > >>>>>> headers, so it applies to Contact. E.g. the following > >> is illegal: > >>>>>> Contact:sip:alice@atlanta.com;methods="INVITE";methods="CANCEL" > >>>>>> > >>>>>> Paul > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > > > _______________________________________________ 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
- [Sip] Question on RFC3840/3841 Christer Holmberg
- Re: [Sip] Question on RFC3840/3841 Mahesh Anjanappa
- [Sip] Re: Question on RFC3840/3841 Paul Kyzivat
- Re: [Sip] Question on RFC3840/3841 Paul Kyzivat
- Re: [Sip] Question on RFC3840/3841 Mahesh Anjanappa
- [Sip] RE: Question on RFC3840/3841 Christer Holmberg
- [Sip] Question on Accept ABNF Christer Holmberg
- Re: [Sip] Question on RFC3840/3841 Mahesh Anjanappa
- RE: [Sip] Question on RFC3840/3841 Christer Holmberg
- Re: [Sip] Question on RFC3840/3841 Mahesh Anjanappa
- Re: [Sip] Question on RFC3840/3841 Paul Kyzivat
- RE: [Sip] Question on RFC3840/3841 Christer Holmberg
- Re: [Sip] Question on RFC3840/3841 Paul Kyzivat
- RE: [Sip] Question on RFC3840/3841 Christer Holmberg
- [Sip] Question on RFC3840/3841 - matching of list… Christer Holmberg