Hello Paul, The to tags are not different, they are identical. The 404 Not Here reply has nothing to do with a tag mismatch but with an error in the configuration file. The Subscribe inside a dialog goes on a wrong branch in the configuration file. Search where the 404 reply is sent from the script.
regards, Anca Pablo Guijarro Enríquez wrote: > I forgot to post the response to the original subscribe, where the to-tag is > set. Now you can see that it is different from the one that appears in the > subscribe that is sent when the presence status change. > > > SIP/2.0 202 OK > Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKe5a9.a616d022.0 > To: sip:[EMAIL PROTECTED];tag=10.20757.1209988007.20 > From: > sip:[EMAIL PROTECTED];tag=533cb9e91f4b999cf76861cbb9ed54ed-be94 > CSeq: 10 SUBSCRIBE > Call-ID: [EMAIL PROTECTED] > Expires: 473 > Contact: <sip:10.95.43.31> > Server: OpenSER (1.3.1-notls (i386/linux)) > Content-Length: 0 > > > Thanks again, > Pablo > > > -----Mensaje original----- > De: Pablo Guijarro Enríquez [mailto:[EMAIL PROTECTED] > Enviado el: lunes, 05 de mayo de 2008 14:11 > Para: 'Anca Vamanu' > CC: 'users@lists.openser.org' > Asunto: RE: [OpenSER-Users] Problems with SIMPLE-XMPP presence > > Well, I have made some tests and I think I have found what could be a wrong > behaviour of the pua_xmpp module, leading to the situation described in the > previous post. I will try to explain it better here. > > Every time a XMPP client changes its presence status, pua_xmpp sends what > seems to be re-subscribes for each of its contacts belonging to the SIP > domain. The problem is that they are not linked with the original suscribes > because they don't have the same To-Tag (neither have they the same branch > in Via header, but I don't think that's important). For example: > > > - PREVIOUS SUBSCRIBE: > > SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 > Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKe5a9.a616d022.0 > To: sip:[EMAIL PROTECTED] > From: > sip:[EMAIL PROTECTED];tag=533cb9e91f4b999cf76861cbb9ed54ed-be94 > CSeq: 10 SUBSCRIBE > Call-ID: [EMAIL PROTECTED] > Content-Length: 0 > User-Agent: OpenSER (1.3.1-notls (i386/linux)) > Max-Forwards: 70 > Event: presence > Contact: <sip:[EMAIL PROTECTED]> > Expires: 473 > > > - NEW SUBSCRIBE AFTER STATUS CHANGE: > > SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 > Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKf5a9.e1802f23.0 > To: sip:[EMAIL PROTECTED];tag=10.20757.1209988007.20 > From: > sip:[EMAIL PROTECTED];tag=533cb9e91f4b999cf76861cbb9ed54ed-be94 > CSeq: 11 SUBSCRIBE > Call-ID: [EMAIL PROTECTED] > Content-Length: 0 > User-Agent: OpenSER (1.3.1-notls (i386/linux)) > Max-Forwards: 70 > Event: presence > Contact: <sip:[EMAIL PROTECTED]> > Expires: 3610 > > > As a result, the later subscribe request is rejected with a 404 Not Here > response. The pua_xmpp, upon receiving the response, sends a brand new > subscribe request, that has nothing to do with the others and is accepted by > openser. > > When this is done for every contact the XMPP client has, I can see in > database how presentity table has one more row that it had before (showing > the last status change) and how active_watchers table has grown as many rows > as contacts have been involved (one for each new suscribe). And they keep > growing every time there is a change in the presence status of the XMPP > client. > > So, please, let me know whether I am right and this is something to be > fixed. > > Thank you, > Pablo > > > -----Mensaje original----- > De: Pablo Guijarro Enríquez [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 17 de abril de 2008 17:56 > Para: 'Anca Vamanu' > Asunto: RE: [OpenSER-Users] Problems with SIMPLE-XMPP presence > > Thanks, Anca, that was it :) > > Now presence information is shown in both the SIP and the XMPP client, but > there are still some estrange behaviours in openser. > > First, when I start the SIP client with the XMPP client already online, some > kind of loop occurs, as you can see in the log attached. The following > NOTIFY message is sent again and again for a while, changing just the > from-tag, branch and call-id: > > NOTIFY sip:[EMAIL PROTECTED] SIP/2.0 > Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bK1d12.1b727435.0 > To: sip:[EMAIL PROTECTED];tag=533cb9e91f4b999cf76861cbb9ed54ed-38b3 > From: sip:[EMAIL PROTECTED];tag=10.1700.1208442687.20 > CSeq: 2 NOTIFY > Call-ID: [EMAIL PROTECTED] > Content-Length: 471 > User-Agent: OpenSER (1.3.1-notls (i386/linux)) > Max-Forwards: 70 > Event: presence > Contact: <sip:10.95.43.31> > Subscription-State: active;expires=2631 > Content-Type: application/pidf+xml > <...> > > > The first couple of them get the following response, but not all the others, > that get no answer: > > SIP/2.0 200 OK > Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bK1d12.1b727435.0 > To: sip:[EMAIL PROTECTED];tag=533cb9e91f4b999cf76861cbb9ed54ed-38b3 > From: sip:[EMAIL PROTECTED];tag=10.1700.1208442687.20 > CSeq: 2 NOTIFY > Call-ID: [EMAIL PROTECTED] > Server: OpenSER (1.3.1-notls (i386/linux)) > Content-Length: 0 > > > It seems that the responses are not taken into account, or maybe it is > related with the other thing I find weird, the fact that pua and presentity > tables in Mysql database grows continuously with registries that are much > like already existing ones. Sample of the pua table: > > | 18432 | sip:[EMAIL PROTECTED] | | 1 | 1208449465 | > 0 | 8 | a.1208441749.1702.41.0 | | | > | | | 0 | > | | 0 | | > > | 18428 | sip:[EMAIL PROTECTED] | | 1 | 1208449357 | > 0 | 8 | a.1208441749.1701.25.0 | 0xbf9787bc | | > | | | 0 | > NULL | | 0 | | > > | 18429 | sip:[EMAIL PROTECTED] | | 1 | 1208449356 | > 0 | 16 | | | > sip:[EMAIL PROTECTED] | [EMAIL PROTECTED] | > 10.1700.1208445755.35 | 533cb9e91f4b999cf76861cbb9ed54ed-9c6c | 10 | NULL > | | 0 | | > > | 18420 | sip:[EMAIL PROTECTED] | | 1 | 1208446132 | > 0 | 8 | a.1208441749.1700.12.0 | 0xbf9787bc | | > | | | 0 | > | | 0 | | > > | 18427 | sip:[EMAIL PROTECTED] | | 1 | 1208449357 | > 1208449345 | 16 | | | > sip:[EMAIL PROTECTED] | [EMAIL PROTECTED] | > 10.1703.1208445756.21 | 533cb9e91f4b999cf76861cbb9ed54ed-463c | 10 | > | | 0 | | > > | 18426 | sip:[EMAIL PROTECTED] | | 1 | 1208449357 | > 1208449355 | 16 | | | > sip:[EMAIL PROTECTED] | 6ce7eb9f | > 10.1700.1208445756.36 | 533cb9e91f4b999cf76861cbb9ed54ed-6582 | 10 | > | sip:[EMAIL PROTECTED] | 0 | | > > | 18423 | sip:[EMAIL PROTECTED] | | 1 | 1208446287 | > 0 | 8 | a.1208441749.1701.17.0 | | | > | | | 0 | > | | 0 | | > > | 18425 | sip:[EMAIL PROTECTED] | | 1 | 1208449228 | > 0 | 16 | | | > sip:[EMAIL PROTECTED] | 6ce7eb98 | > 10.1700.1208445628.32 | 533cb9e91f4b999cf76861cbb9ed54ed-da39 | 10 | > | sip:[EMAIL PROTECTED] | 0 | | > > | 18438 | sip:[EMAIL PROTECTED] | | 1 | 1208449387 | > 0 | 16 | | | > sip:[EMAIL PROTECTED] | [EMAIL PROTECTED] | > 10.1703.1208445918.32 | 533cb9e91f4b999cf76861cbb9ed54ed-7095 | 10 | NULL > | | 0 | > > > Every time the XMPP client changes its presence state, one registry is added > to the presentity table. Sample: > > | 783 | pge354*xmpp.domain | xmpp-gw | presence | > a.1208441749.1701.36.1 | 1208449478 | 1208445878 | <?xml version="1.0"?> > <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="pres:[EMAIL PROTECTED]"> > <tuple id="0xbf9787bc"> > <status> > <basic>open</basic> > </status> > </tuple> > </presence> > > | > | 785 | pge354*xmpp.domain | xmpp-gw | presence | > a.1208441749.1702.45.0 | 1208449517 | 1208445917 | <?xml version="1.0"?> > <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="pres:[EMAIL PROTECTED]"> > <tuple id="0xbf9787bc"> > <status> > <basic>open</basic> > </status> > </tuple> > </presence> > > | > | 786 | pge354*xmpp.domain | xmpp-gw | presence | > a.1208441749.1702.52.1 | 1208450140 | 1208446540 | <?xml version="1.0"?> > <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="pres:[EMAIL PROTECTED]"> > <tuple id="0xbf9787bc"> > <status> > <basic>open</basic> > </status> > </tuple> > <note>away</note> > <person id="0xbf9787bc"> > <activities/> > <note>away</note> > </person> > </presence> > > > How can I solve all this issues? > > Regards, > Pablo > > > -----Mensaje original----- > De: Anca Vamanu [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 17 de abril de 2008 11:13 > Para: Pablo Guijarro Enríquez > CC: users@lists.openser.org > Asunto: Re: [OpenSER-Users] Problems with SIMPLE-XMPP presence > > Hello, > > There is something missing in your configuration file. See econfig > example from version 1.3 (etc/openser.cfg, line 214). You should add > something like this on the else branch for in dialog requests: > if (is_method("SUBSCRIBE|NOTIFY") && ($rd == "your.server.ip.address"| > $rd=="xmpp-gw")) > { > # in-dialog subscribe requests > route(2); > exit; > } > > The way you have it now, all in dialog requests are not allowed, that is > all Notifies and the in dialog Subscribes. > > regards, > Anca Vamanu > > > Pablo Guijarro Enríquez wrote: > >> Hi again, >> >> Sorry about the delay and thanks for your support. I did so, but it still >> does not work. The fact is that the subscription to the XMPP user is sent >> from the SIP user and reaches openser, which sends back a notify request >> with no presence information at all. In between there is not exchange of >> information with the XMPP either. >> >> Then openser sends itself the couple of subscribe requests mentioned in my >> later post (now both with sip:10.95.43.31 as contact header), the first of >> which is rejected (due to the to-tag, I suppose), while the second one is >> accepted. As a result of that request, a notify is sent towards itself, >> > but > >> it is rejected with a 404 Not Here response. This one do carry some >> > presence > >> information, but nothing interesting: >> >> Content-Type: application/watcherinfo+xml >> >> <?xml version="1.0"?> >> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" >> state="full"> >> <watcher-list resource="sip:[EMAIL PROTECTED]" >> package="presence"/> >> </watcherinfo> >> >> Let me know whether that behaviour is the expected one or not, and what >> > the > >> reason could be for it not to work (see log attached). >> >> Regards, >> Pablo >> >> >> -----Mensaje original----- >> De: Anca Vamanu [mailto:[EMAIL PROTECTED] >> Enviado el: viernes, 11 de abril de 2008 15:51 >> Para: Pablo Guijarro Enríquez >> CC: users@lists.openser.org >> Asunto: Re: [OpenSER-Users] Problems with SIMPLE-XMPP presence >> >> Hi, >> >> You need to add a host alias for 'xmpp-gw' on the machine running >> openser. OpenSER does dns lookup to figure out if the destination is it, >> and the R-URI has a special meaning in presence so it should be kept >> with that key. >> As for the contact, please change the parameter to 'sip:10.95.43.31 ' >> >> regards, >> Anca >> >> Pablo Guijarro Enríquez wrote: >> >> >>> Yes, you were right. Now errors have disappeared, but still there is not >>> exchange of information between servers. >>> >>> In the log there are a couple of things that I find strange. The first >>> > one > >>> is that at some point openser tries to resolve xmpp-gw, which is only the >>> key to mark users from the xmpp domain. >>> >>> The second is that, upon receiving the subscription from the client, >>> >>> >> openser >> >> >>> first sends itself a subscription request, with the IP address >>> > established > >>> in the pua_xmpp server_address parameter as Contact header value, which >>> > is > >>> answered with a 404 response, and then it sends the same request but >>> changing the Contact header to the URI sip:openser.domain:5060, which is >>> accepted with a 200 response (see both below). Is that OK? Or should I >>> change that parameter to the URI, despite the instructions given in the >>> module documentation? >>> >>> >>> SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 >>> Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKbca.c6e4c5f1.0 >>> To: sip:[EMAIL PROTECTED];tag=10.12575.1207664296.3 >>> From: >>> >>> >> sip:[EMAIL PROTECTED];tag=533cb9e91f4b999cf76861cbb9ed54ed-2ab3 >> >> >>> CSeq: 11 SUBSCRIBE >>> Call-ID: [EMAIL PROTECTED] >>> Content-Length: 0 >>> User-Agent: OpenSER (1.3.1-notls (i386/linux)) >>> Max-Forwards: 70 >>> Event: presence.winfo >>> Contact: <10.95.43.31> >>> Expires: 3610 >>> >>> >>> SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 >>> Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKafa2.9020b137.0 >>> To: sip:[EMAIL PROTECTED] >>> From: sip: >>> >>> >> [EMAIL PROTECTED];tag=533cb9e91f4b999cf76861cbb9ed54ed-5c38 >> >> >>> CSeq: 10 SUBSCRIBE >>> Call-ID: [EMAIL PROTECTED] >>> Content-Length: 0 >>> User-Agent: OpenSER (1.3.1-notls (i386/linux)) >>> Max-Forwards: 70 >>> Event: presence.winfo >>> Contact: <sip:openser.domain:5060> >>> Expires: 3610 >>> >>> >>> Thanks again, >>> Paul >>> >>> >>> -----Mensaje original----- >>> De: Anca Vamanu [mailto:[EMAIL PROTECTED] >>> Enviado el: martes, 08 de abril de 2008 16:07 >>> Para: Pablo Guijarro Enríquez >>> CC: users@lists.openser.org >>> Asunto: Re: [OpenSER-Users] Problems with SIMPLE-XMPP presence >>> >>> Try compiling the pua_xmpp module; it has some references in pua module >>> that I guess have been broken. >>> >>> Anca >>> >>> Pablo Guijarro Enríquez wrote: >>> >>> >>> >>>> Thanks Anca, >>>> >>>> I tried what you told me. The message about not sending subscribe is no >>>> >>>> >>>> >>> more >>> >>> >>> >>>> shown, but some new errors appear and presence does not work yet. >>>> >>>> Regards, >>>> Paul >>>> >>>> -----Mensaje original----- >>>> De: Anca Vamanu [mailto:[EMAIL PROTECTED] >>>> Enviado el: martes, 08 de abril de 2008 14:30 >>>> Para: Pablo Guijarro Enríquez >>>> CC: users@lists.openser.org >>>> Asunto: Re: [OpenSER-Users] Problems with SIMPLE-XMPP presence >>>> >>>> Hi Pablo, >>>> >>>> There was an optimization in pua version included in 1.3.1 release that >>>> sometimes prevented the presence sip-xmpp gateway from working ( related >>>> > > >>>> to the message "Found previous request for unlimited subscribe- do not >>>> send subscribe") from the log. >>>> This was removed in the svn version of the branch. I advise you to take >>>> the pua module from svn 1.3 branch. >>>> >>>> regards, >>>> Anca Vamanu >>>> >>>> >>>> Pablo Guijarro Enríquez wrote: >>>> >>>> >>>> >>>> >>>>> Hi everybody, >>>>> >>>>> I have some problems to get presence information exchanged between SIP >>>>> users and xmpp ones. SIP clients (X-Lite) depend on an openser server >>>>> v1.3.1, with all necessary modules working within it, and xmpp clients >>>>> (Psi) rely on an xmpp server (ejabberd) which is in the same machine. >>>>> >>>>> The link between both sip and xmpp servers is established when openser >>>>> starts, and the exchange of instant messages between sip and xmpp >>>>> users works fine. So does presence too, as long as there are only sip >>>>> users or only xmpp users involved, but it does not work between the >>>>> two “worlds” in any direction. Moreover, I do not see any packet being >>>>> exchanged between the sip and the xmpp servers when a user from one >>>>> domain subscribe to one from the other, or when they change their >>>>> >>>>> >> status. >> >> >>>>> I don’t know what the problem can be. No errors appear in the log and >>>>> I thought adding xmpp presence to openser would be straightforward >>>>> once the IM was already working. >>>>> >>>>> Openser config file and part of the log file (the subscription to an >>>>> xmpp user) are attached. Hope someone can give me some clue. >>>>> >>>>> Thanks in advance! >>>>> >>>>> Paul >>>>> >>>>> >>>>> > ------------------------------------------------------------------------ > >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users@lists.openser.org >>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > > _______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
