On 08 May 2014, at 18:33, Eugen Dedu <[email protected]> wrote:
> Hi asterisk devs, > > Since several years we (opal, ekiga VoIP community) noticed that there is a > problem in the NOTIFY messages created by asterisk (entity attribute is set > to the subscriber instead of the subscribed) and I finally decided to contact > you to see whether such a visible bug has been around for so many years or we > simply miss something evident. (See the log of > http://sourceforge.net/p/opalvoip/code/26681 for example for a workaround.) I think that's a bad bug which I'm likely responsible for. Report it in the issue tracker and we'll fix it. I guess that very few use our presence event support in SIP. If more people used it, they would have asked for the text prompts in their own language. That can be a reason why it has gone undetected for so long. I still remember the reason WHY I implemented Event: Presence in Asterisk. I had paid 50 canadian dollars for a softphone and it simply did not work with Asterisk. With such a huge investment, I just had to make it work... ;-) At some points /O > > When umfoxd subscribes to 1002's presence, like this for example: > > SUBSCRIBE sip:[email protected] SIP/2.0 > CSeq: 2 SUBSCRIBE > Via: SIP/2.0/UDP > 157.163.3.246:5060;branch=z9hG4bK52829d51-8f0c-1910-8da9-080027f515ee;rport > User-Agent: Ekiga/4.0.2 > Authorization: Digest username="umfodx", realm="xivo", nonce="1c356c20", > uri="sip:[email protected]", algorithm=MD5, > response="4f62a8e41ee3c464ff1bf6124b7dda76" > From: <sip:[email protected]>;tag=1b7f9d51-8f0c-1910-8da4-080027f515ee > Call-ID: e47b9d51-8f0c-1910-8da2-080027f515ee@Windows7-PC > Supported: eventlist > To: <sip:[email protected]> > Accept: application/pidf+xml > Accept: multipart/related > Accept: application/rlmi+xml > Contact: <sip:[email protected]> > Allow: > INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK > Expires: 300 > Event: presence > Content-Length: 0 > Max-Forwards: 70 > > > umfoxd receives afterwards NOTIFY messages, like this for example: > > NOTIFY sip:[email protected] SIP/2.0 > CSeq: 102 NOTIFY > Via: SIP/2.0/UDP 157.163.1.45:5060;branch=z9hG4bK1ebf2f30;rport > User-Agent: XiVO PBX > From: <sip:[email protected]>;tag=as7426eebf > Call-ID: e47b9d51-8f0c-1910-8da2-080027f515ee@Windows7-PC > To: <sip:[email protected]>;tag=1b7f9d51-8f0c-1910-8da4-080027f515ee > Contact: <sip:[email protected]:5060> > Subscription-State: active > Event: presence > Content-Type: application/pidf+xml > Content-Length: 499 > Max-Forwards: 70 > > <?xml version="1.0" encoding="ISO-8859-1"?> > <presence xmlns="urn:ietf:params:xml:ns:pidf" > xmlns:pp="urn:ietf:params:xml:ns:pidf:person" > xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" > xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person" > entity="sip:[email protected]"> > <pp:person><status> > </status></pp:person> > <note>Ready</note> > <tuple id="1002"> > <contact priority="1">sip:[email protected]</contact> > <status><basic>open</basic></status> > </tuple> > </presence> > > The problem is that in the above message the entity attribute is umfoxd (the > subscriber) instead of 1002 (the publisher). > > From RFC 3863: > The <presence> element MUST have an 'entity' attribute. The value of the > 'entity' attribute is the 'pres' URL of the PRESENTITY publishing this > presence document. > > Regards, > -- > Eugen > http://eugen.dedu.free.fr > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
