Hi Andreas, You're right QuteCom's vresion of phapi does not handle this correctly.
We have a another phapi based sip stack: Verona (http://www.mbdsys.com/vopensource/verona) where correct behaviour is implemented so if somebody could rig a patch proting this to QuteCome we'd be happy to accept it. Thanks Vadim [EMAIL PROTECTED] wrote: > Hi, > > When testing presence with qutecom 2.2, I encountered a problem with > PUBLISH handling (in fact, this issue exists in OpenWengo also): > > RFC 3903 defines in 4.1 the following scenario: > > #+ > When updating previously published event state, PUBLISH requests MUST > contain a single SIP-If-Match header field identifying the specific > event state that the request is refreshing, modifying or removing. > This header field MUST contain a single entity-tag that was returned > by the ESC in the SIP-ETag header field of the response to a previous > publication. > #- > > So what happens is that qutecom sends a PUBLISH without SIP-If-Match and > the presence server sends back 200-OK with a SIP-ETag, which is ok for > initial publishing. But for subsequent PUBLISH from qutecom, also no > SIP-If-Match is sent, so the presence server is not able to update the > state correctly, but will reply with a new SIP-ETag. Could somebody please > investigate and/or confirm this? > > OpenSER 1.3.x is used as presence server, btw. > > Thanks, > Andreas > > _______________________________________________ > QuteCom-dev mailing list > [email protected] > http://lists.qutecom.org/mailman/listinfo/qutecom-dev > > > _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
