[asterisk-bugs] [JIRA] (ASTERISK-23731) wrong entity attribute in first NOTIFY on presence subscription - should be publisher instead of subscriber

Rusty Newton (JIRA) noreply at issues.asterisk.org
Wed May 21 16:17:43 CDT 2014


    [ https://issues.asterisk.org/jira/browse/ASTERISK-23731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218361#comment-218361 ] 

Rusty Newton commented on ASTERISK-23731:
-----------------------------------------

Ignore my previous comments on reproduction. I had mistakenly been working with presence notifications for [Presence State|https://wiki.asterisk.org/wiki/display/AST/Presence+State] instead of Device/Extension state, as well as making some other mistakes in my data collection. I think, based on the PIDF content it is clear that your example NOTIFY is generated based on Device/Extensions state changes.

I can, in fact, reproduce the issue as you describe with a single hint mapped to a SIP device.
{noformat}
exten => 6002,hint,SIP/6002
{noformat}
It appears that the Entity in all NOTIFY messages to a subscriber will contain the subscriber and not the publisher.

> wrong entity attribute in first NOTIFY on presence subscription - should be publisher instead of subscriber
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23731
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23731
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Channels/chan_sip/Subscriptions
>    Affects Versions: SVN, 1.8.27.0, 11.9.0, 12.2.0
>            Reporter: Eugen Dedu
>            Assignee: Eugen Dedu
>
> Quoting Olle Johansson:
> "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... "
> === Original report:
> 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.)
> When umfoxd subscribes to 1002's presence, like this for example:
> {noformat}
> SUBSCRIBE sip:1002 at xivo.xyz.fr 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:1002 at xivo.xyz.fr", algorithm=MD5, response="4f62a8e41ee3c464ff1bf6124b7dda76"
> From: <sip:umfodx at xivo.xyz.fr>;tag=1b7f9d51-8f0c-1910-8da4-080027f515ee
> Call-ID: e47b9d51-8f0c-1910-8da2-080027f515ee at Windows7-PC
> Supported: eventlist
> To: <sip:1002 at xivo.xyz.fr>
> Accept: application/pidf+xml
> Accept: multipart/related
> Accept: application/rlmi+xml
> Contact: <sip:umfodx at 157.163.3.246>
> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK
> Expires: 300
> Event: presence
> Content-Length: 0
> Max-Forwards: 70
> {noformat}
> umfoxd receives afterwards NOTIFY messages, like this for example:
> {noformat}
> NOTIFY sip:umfodx at 157.163.3.246 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:1002 at xivo.xyz.fr>;tag=as7426eebf
> Call-ID: e47b9d51-8f0c-1910-8da2-080027f515ee at Windows7-PC
> To: <sip:umfodx at xivo.xyz.fr>;tag=1b7f9d51-8f0c-1910-8da4-080027f515ee
> Contact: <sip:1002 at 157.163.1.45: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:umfodx at xivo.xyz.fr">
> <pp:person><status>
> </status></pp:person>
> <note>Ready</note>
> <tuple id="1002">
> <contact priority="1">sip:1002 at xivo.xyz.fr</contact>
> <status><basic>open</basic></status>
> </tuple>
> </presence>
> {noformat}
> The problem is that in the above message the entity attribute is umfoxd (the subscriber) instead of 1002 (the publisher).
> From RFC 3863:
> {quote}
> 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.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list