[OpenSIPS-Users] [OpenSIPS-Devel] Problem with presence, if event header has id.

[Schumann Sebastian]

I might add what was wrong for us: We had the bug receiving "Event: presence.winfo;id=value".

I also checked 3265 and came to this conclusion:

For sure, RFC "Event: presence.winfo" and "Event: presence.winfo;id=value" have to be threated differently.

Additionally, the matching logic must assure that: "Event: presence.winfo;id=value" should only publish watchers that publish with "Event: presence;id=value". If id parameter is missing, the watchers should not be returned to requests with id parameter. These watchers, in turn, should only receive NOTIFY messages for published event with id if they subscribe for "Event: presence;id=value".

Sebastian

> -----Original Message-----
> From: users-bounces at lists.opensips.org 
> [mailto:users-bounces at lists.opensips.org] On Behalf Of Andrew 
> Pogrebennyk
> Sent: Wednesday, 15. October 2008 10:59
> To: anca at voice-sistem.ro
> Cc: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] [OpenSIPS-Devel] Problem with 
> presence,if event header has id.
> 
> Anca,
> I spotted this bug before. Note that there are some 
> peculiarities that are easy to get wrong.
> 
> E.g. the package name in the "Event" header of NOTIFY must 
> match the "Event" header in the corresponding SUBSCRIBE 
> message, including "id". 
> If an "id" parameter was present in the SUBSCRIBE message, that "id" 
> parameter must also be present in the corresponding NOTIFY messages.
> 
> Next, each subscription request by UA should be processed 
> with separate SIP request, even if it is requested from the 
> same agent and for the same Event but with different Event 
> ID. There probably should be some kind of check in presence 
> that if the same UA generates a SUBSCRIBE request with a new 
> Event ID, but mistakenly does not generate a new From tag 
> etc, presence does not change the state of the matching 
> subscription which differs by the Event ID.
> 
> anca at voice-sistem.ro wrote:
> > Hi,
> > 
> > You are right. I have now looked through the RFC's and it 
> seems that 
> > even presence event might contain an id parameter.
> > The mistake came from bad interpretation of RFC3856 which says:
> > 
> > The SIP event framework allows event packages to define additional
> >    parameters carried in the Event header field.  This package,
> >    presence, does not define any additional parameters.
> > 
> > However, RFC3265 says:
> >    Subscribers MUST include exactly one "Event" header in SUBSCRIBE
> >    requests, indicating to which event or class of events they are
> >    subscribing.  The "Event" header will contain a token 
> which indicates
> >    the type of state for which a subscription is being 
> requested.  This
> >    token will be registered with the IANA and will correspond to an
> >    event package which further describes the semantics of 
> the event or
> >    event class.  The "Event" header MAY also contain an 
> "id" parameter.
> >    This "id" parameter, if present, contains an opaque token which
> >    identifies the specific subscription within a dialog.  An "id"
> >    parameter is only valid within the scope of a single dialog.
> > 
> > I will fix this.
> > 
> > Thanks,
> > Anca
> 
> --
> Sincerely,
> Andrew Pogrebennyk
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>