[Sip] Question on RFC3840/3841 - matching of list values

["Christer Holmberg" <[e-mail]>]

 
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








> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: 10. tammikuuta 2008 17:04
> To: Christer Holmberg
> Cc: Mahesh Anjanappa; [e-mail]
> Subject: Re: [Sip] Question on RFC3840/3841
> 
> 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
> 
> 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:[e-mail]]
> >> Sent: 10. tammikuuta 2008 16:21
> >> To: Mahesh Anjanappa
> >> Cc: Christer Holmberg; [e-mail]
> >> 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 "[e-mail]"
> >> 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 [e-mail] 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" 
> >>> <[e-mail]>
> >>> To: "Mahesh Anjanappa" <[e-mail]>; "Paul Kyzivat" 
> >>> <[e-mail]>
> >>> Cc: <[e-mail]>
> >>> Sent: Thursday, January 10, 2008 11:30 AM
> >>> Subject: RE: [Sip] Question on RFC3840/3841
> >>>
> >>>
> >>>
> >>> Shouldn't each Contact also contain "[e-mail]"?
> >>>
> >>> Also, why do you have ";" at the end of each Contact?
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Mahesh Anjanappa [mailto:[e-mail]]
> >>>> Sent: 10. tammikuuta 2008 6:16
> >>>> To: Paul Kyzivat
> >>>> Cc: [e-mail]; 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:[e-mail];
> >>>> Contact:audio;duplex=full;
> >>>> Contact:video;duplex=recieve-only;
> >>>>
> >>>> Thanks
> >>>> Mahesh
> >>>> ----- Original Message -----
> >>>> From: "Mahesh Anjanappa" <[e-mail]>
> >>>> To: "Paul Kyzivat" <[e-mail]>
> >>>> Cc: <[e-mail]>; "Christer Holmberg"
> >>>> <[e-mail]>
> >>>> 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:[e-mail];
> >>>>>    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" 
> >>>> <[e-mail]>
> >>>>> To: "Mahesh Anjanappa" <[e-mail]>
> >>>>> Cc: "Christer Holmberg" <[e-mail]>;
> >>>> <[e-mail]>
> >>>>> 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:[e-mail];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 
> >>>>> [e-mail] for questions on 
> current sip Use 
> >>>>> [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip