Vadim, So is it actually a problem of libosip (which currently is the underlying phapi, if I understand it correctly)?
Andreas > 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
