Ticket #12 (closed Defect: Invalid)

Opened 14 months ago

Last modified 13 months ago

Reactive authorization problem

Reported by: taiffu Owned by: admin
Priority: Critical Milestone:
Component: XCAP protocol Version:
Severity: Critical Keywords: Reactive authorization
Cc:

Description

Hi, I have problem to get reactive authorization to work. Here is case: Client A subscribe client B status. Client B is already subscribed watcher-list and server send "pending" notification to client B. ( Some time server wont send that watcher-list maybe network problem?) Client B accept client A subscribtion and add client A in to own pres-rules document. After this accept ( or block ) server should be send status Notify to client A, but this not happen?

Is this error in XCAP or OpenSer configuration?

Change History

Changed 14 months ago by admin

  • owner changed from Mircea Amarascu to admin
  • status changed from new to accepted

The SUBSCRIBE/NOTIFY mechanisms are handled by the presence sever. What presence server are you using ? Is it OpenSER's? If it is, you must activate the XMLRPC managed interface control on OpenSER, and then in OpenXCAP's configuration you should choose the OpenSER backend, and set the URL where the XMLRPC server is waiting for requests. On presence rules changes, OpenXCAP will send a RefreshWatchers command, which should force the sending of NOTIFYs.

Changed 14 months ago by taiffu

XCAP server what I using is http://node04.dns-hosting.info/xcap-root/ and Sip server is sip2sip.info. Also I have my own enviroment too but there is same problem.

Changed 14 months ago by mikasaari

Continuing from taiffus earlier comments, this is more server side. Using OpenXCAP 0.9.3 with latest OpenSER SVN version. The netstat -lptn informs that 8080 is listening after OpenSER is executed. If using command "telnet localhost 8080" & GET / HTTP/1.0 I get response from ABYSS/0.3 server. Checked that OpenXCAP 0.9.3 is having configuration "xmlrpc_url = http://localhost:8080" in config.ini. Also the openser.cfg is having rows [modparam("mi_xmlrpc", "log_file", "/var/log/openser-xmlrpc.log")] and [modparam("mi_xmlrpc", "port", 8080)].

Now when trying to change the presence state (online state) there seems not happening anything in the /var/log/openser_xmlrpc.log. Neither no IP traffic is happening in localhost:8080 (tcpdump -i any) when online state is changed. And clients do not see the status change.

thanks,

-Mika

Changed 14 months ago by taiffu

  • summary changed from Reactive authorization problem ( Digest auth server ) to Reactive authorization problem

I have made a lot of testing for this reactive authorization. Normal status seems to be work fine but still seems to be a problem with reactive authorization. Here's the case I've been testing with two EyeBeam client. Client A subscribe client B SUBSCRIBE sip:xxx@sip2sip.info SIP/2.0 Server answer to client A SIP/2.0 202 OK And now what I think should happens but it NOT happens, server MUST send watcher list to client B witch include something like this: <?xml version="1.0"?>

<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"

version="0" state="full"> <watcher-list resource="sip:xxx@sip2sip.info"

package="presence"> <watcher id="77ajsyy76" event="subscribe"

status="pending">sip:A@example.com</watcher>

</watcher-list>

</watcherinfo>

What server actually does, it sends client B presence document to client A without authorization. NOTIFY sip:A@82.128.227.55:3725;transport=TCP SIP/2.0 . . <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" xmlns:c="urn:ietf:params:xml:ns:pidf:cipid" entity="sip:B@sip2sip.info">

<tuple id="tfd688812">

<status>

<basic>open</basic>

</status>

</tuple> . . .

Any ideas what's wrong here? I think the problem might be with Openser XMLRPC? All xml files seems to be going right to OpenXCAP server.

Changed 13 months ago by ruud

  • status changed from accepted to closed
  • resolution changed from To be investigated to Invalid

This seems to be a SIP signalling problem. I suggest you contact the OpenSER developers about this problem.

Note: See TracTickets for help on using tickets.