Subject: [Sip] Question on RFC3840/3841

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 9 Jan 2008 11:24:28 +0100

Hi,

Chapter 9 of RFC3840 says:

"There are additional constraints on the usage of feature-param that
cannot be represented in a BNF. There MUST only be one instance of any
feature tag in feature-param."

Chapter 10 of RFC3840 says:

"Furthermore, there can only be one instance of any feature tag in
feature-param."

So, this means that the following is NOT allowed:

Accept-Contact: *;myTag,myTag

However, since an Accept-Contact header can contain multiple ac-values,
each with its own sets of ac-parameters (including feature-params), the
following should be allowed:

Accept-Contact: *;myTag, *;myTag

...or:

Accept-Contact: *;myTag
Accept-Contact: *;myTag

Correct?

Regards,

Christer

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Mahesh Anjanappa <[email-masked]>
Date: Wed, 09 Jan 2008 19:00:36 +0530

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.

regards
Mahesh

----- Original Message ----- 
From: "Christer Holmberg" <[email-masked]>
To: <[email-masked]>
Cc: "Paul Kyzivat" <[email-masked]>
Sent: Wednesday, January 09, 2008 3:54 PM
Subject: [Sip] Question on RFC3840/3841

Hi,

...or:

Accept-Contact: *;myTag
Accept-Contact: *;myTag

Correct?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jan 2008 09:21:41 -0500

> Accept-Contact: *;myTag,myTag

The above isn't syntactically correct. I presume you meant to write:

Accept-Contact: *;myTag;myTag

And yes, that isn't allowed.

> Accept-Contact: *;myTag, *;myTag

Yes.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jan 2008 09:25:46 -0500

Mahesh Anjanappa wrote:
> 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:[email-masked];methods="INVITE";methods="CANCEL"

Paul

---

From: Mahesh Anjanappa <[email-masked]>
Date: Wed, 09 Jan 2008 22:48:26 +0530

Thanks Paul.
So would it be right if i have a Contact Headers describing Duplex Audio & 
one-way Video Capabilities as follows?

    Contact:sip:[email-masked];
    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

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 9 Jan 2008 19:34:15 +0100

Hi,

>>"Furthermore, there can only be one instance of any feature tag in feature-param."
>>
>>
>>

Yes.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 9 Jan 2008 20:34:14 +0100

Hi,
 
I appologize if the following issue has already been dealt with.
 
In RFC3261 the ABNF for the Accept header is the following:
 
Accept              =  "Accept" HCOLON[ accept-range *(COMMA accept-range) ]
accept-range    =  media-range *(SEMI accept-param)
media-range     =  ( "*/*" / ( m-type SLASH "*" )  / ( m-type SLASH m-subtype )) *( SEMI m-parameter )
accept-param   =  ("q" EQUAL qvalue) / generic-param
qvalue               =  ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] )
generic-param  =  token [ EQUAL gen-value ]
gen-value         =  token / host / quoted-string
...
m-parameter     =  m-attribute EQUAL m-value
m-attribute       =  token
m-value            =  token / quoted-string

Now, when I receive: Accept: xxxx/yyyy;myParam=isThis

...how does my parser know whether "myParam" is a m-parameter, or an accept-param?

In RFC2616 (HTTP) it is solved by specifying that the first accept-param MUST be a "q" value, so unless you also have a "q" m-parameter you know that anything that comes before "q" is m-parameter, and the rest (including "q" is accept-param):
 
accept-params  = ";" "q" "=" qvalue *( accept-extension )

RFC2616 also says:
 
"Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality
factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params."
 
...and:
 
"Note: Use of the "q" parameter name to separate media type
 parameters from Accept extension parameters is due to historical
 practice. Although this prevents any media type parameter named
 "q" from being used with a media range, such an event is believed
 to be unlikely given the lack of any "q" parameters in the IANA
 media type registry and the rare usage of any media type
 parameters in Accept. Future media types are discouraged from
 registering any parameter named "q"."

Now, RFC3261 DOES say that Accept follows the syntax defined in RFC2616, but then it is confusing that the 3261 Accept ABNF is not identical.

Regards,
 
Christer

---

From: Mahesh Anjanappa <[email-masked]>
Date: Thu, 10 Jan 2008 09:46:17 +0530

hi Paul,
Sorry there is a mistake in Contact header i described.Following is what i 
wanted to:
Contact:sip:[email-masked];
Contact:audio;duplex=full;
Contact:video;duplex=recieve-only;

Thanks
Mahesh

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 10 Jan 2008 07:00:25 +0100

Shouldn't each Contact also contain "[email-masked]"?

Also, why do you have ";" at the end of each Contact?

Regards,

Christer 

> -----Original Message-----
> From: Mahesh Anjanappa [mailto:[email-masked]] 
> Sent: 10. tammikuuta 2008 6:16
> To: Paul Kyzivat
> Cc: [email-masked]; Christer Holmberg
> Sorry there is a mistake in Contact header i 
> described.Following is what i wanted to:

---

From: Mahesh Anjanappa <[email-masked]>
Date: Thu, 10 Jan 2008 18:13:06 +0530

Yes the ';' is a mistake. But i'm not sure if  each Contact should contain 
"[email-masked]"
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.
If each of the COntact contains [email-masked] 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:
------------

regards
Mahesh
----- Original Message ----- 
From: "Christer Holmberg" <[email-masked]>
To: "Mahesh Anjanappa" <[email-masked]>; "Paul Kyzivat" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 10, 2008 11:30 AM
Subject: RE: [Sip] Question on RFC3840/3841

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jan 2008 09:20:49 -0500

Mahesh Anjanappa wrote:
> Yes the ';' is a mistake. But i'm not sure if  each Contact should 
> contain "[email-masked]"

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 [email-masked] 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
> ----- Original Message ----- From: "Christer Holmberg" 
> <[email-masked]>
>> > ----- Original Message ----- > From: "Paul Kyzivat" 
>> <[email-masked]>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 10 Jan 2008 15:42:14 +0100

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

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 10. tammikuuta 2008 16:21
> To: Mahesh Anjanappa
> Cc: Christer Holmberg; [email-masked]
> 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.
> 
> 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
> 
> > interpreted as " alice supports duplex audio and oneway video 
> > separatley and not both at the same time".
> > Contact header correctly, hence my Queries. It all stems from the 
> > statement which you too noted " There MUST only be one 
> instance of any

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jan 2008 10:03:32 -0500

Christer,

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.)

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 18 Jan 2008 10:27:59 +0100

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?
> > 
> >> 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.
> >>
> >> earliest draft I have is -03 which came out in november of 
> 2000.) It 
> >> set the basic syntax and the initial set of capabilities.
> >>
> 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 
> 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.
> >>
> >>>>> NOTE: The Predicate(for above) for which i'm attempting 
> is & ( & 
> >>>>> (sip.audio) (sip.duplex=full) )
> >>>>> This list is for NEW development of the core SIP Protocol Use 
> >>>>> [email-masked] for questions on 
> current sip Use 
> >>>>> [email-masked] for new developments on the
> >> application of sip
> >>>>
> >>>
> > 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 18 Jan 2008 14:26:24 +0100

Hi,

One question is I have is related to the matching of list values.

First, when a user registers the SIP methods is supports, it can be a
list of methods (e.g. methods="INVITE, BYE,....)

Then, when a request comes, it is automatically assigend an implicit
method preference, e.g. (methods="INVITE").

But, what if the request also contains a list of values.

Assume the user registers the following feature-tag, with a list of
values:

myTag=a,b

Which will generate (| (myTag=a) (myTag=b))

Now, I can receive the following in the Contact:

1.	myTag=a,b			I assume that is a match
2.	myTag=a			Is that a match?
3.	myTag=b			Is that a match?
4.	myTag=b,a			Is that a match?
5.	myTag=a,b,c			Is that a match?

Now, IF it is enough that either a or b in my request is needed for a
match, but I want both a AND b to match, I guess I would have to do the
following:

Accept-Contact:*, myTag=a
Accept-Contact:*, myTag=b

(or, Accept-Contact: *;myTag=a, *;myTag=b

...which would generate:

(& (myTag=a) (myTag=b))

Regards,

Christer

> Sent: 10. tammikuuta 2008 17:04
> To: Christer Holmberg
> Cc: Mahesh Anjanappa; [email-masked]