[OpenSER-Users] Problems with SIMPLE-XMPP presence

Anca Vamanu anca at voice-system.ro
Tue May 6 15:15:25 CEST 2008


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:354 at openser.domain;tag=10.20757.1209988007.20
> From:
> sip:pge354*xmpp.domain at xmpp-gw;tag=533cb9e91f4b999cf76861cbb9ed54ed-be94
> CSeq: 10 SUBSCRIBE
> Call-ID: 7d71efef-20757 at 10.95.43.31
> 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:pge at moviquity.com] 
> Enviado el: lunes, 05 de mayo de 2008 14:11
> Para: 'Anca Vamanu'
> CC: 'users at 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:354 at openser.domain SIP/2.0
> Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKe5a9.a616d022.0
> To: sip:354 at openser.domain
> From:
> sip:pge354*xmpp.domain at xmpp-gw;tag=533cb9e91f4b999cf76861cbb9ed54ed-be94
> CSeq: 10 SUBSCRIBE
> Call-ID: 7d71efef-20757 at 10.95.43.31
> Content-Length: 0
> User-Agent: OpenSER (1.3.1-notls (i386/linux))
> Max-Forwards: 70
> Event: presence
> Contact: <sip:pge354*xmpp.domain at xmpp-gw>
> Expires: 473
>
>
> - NEW SUBSCRIBE AFTER STATUS CHANGE:
>
> SUBSCRIBE sip:354 at openser.domain SIP/2.0
> Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKf5a9.e1802f23.0
> To: sip:354 at openser.domain;tag=10.20757.1209988007.20
> From:
> sip:pge354*xmpp.domain at xmpp-gw;tag=533cb9e91f4b999cf76861cbb9ed54ed-be94
> CSeq: 11 SUBSCRIBE
> Call-ID: 7d71efef-20757 at 10.95.43.31
> Content-Length: 0
> User-Agent: OpenSER (1.3.1-notls (i386/linux))
> Max-Forwards: 70
> Event: presence
> Contact: <sip:pge354*xmpp.domain at xmpp-gw>
> 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:pge at moviquity.com] 
> 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:pge354*xmpp.domain at xmpp-gw SIP/2.0
> Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bK1d12.1b727435.0
> To: sip:pge354*xmpp.domain at xmpp-gw;tag=533cb9e91f4b999cf76861cbb9ed54ed-38b3
> From: sip:354354 at openser.domain;tag=10.1700.1208442687.20
> CSeq: 2 NOTIFY
> Call-ID: 6ce7eb86-1701 at 10.95.43.31
> 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:pge354*xmpp.domain at xmpp-gw;tag=533cb9e91f4b999cf76861cbb9ed54ed-38b3
> From: sip:354354 at openser.domain;tag=10.1700.1208442687.20
> CSeq: 2 NOTIFY
> Call-ID: 6ce7eb86-1701 at 10.95.43.31
> 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:pge354*xmpp.domain at xmpp-gw    |         |     1 | 1208449465 |
> 0 |    8 | a.1208441749.1702.41.0 |            |                      |
> |                       |                                       |    0 |
> |                      |       0 |               |
>
> | 18428 | sip:pge354*xmpp.domain at xmpp-gw    |         |     1 | 1208449357 |
> 0 |    8 | a.1208441749.1701.25.0 | 0xbf9787bc |                      |
> |                       |                                       |    0 |
> NULL         |                      |       0 |               |
>
> | 18429 | sip:354354 at openser.domain |         |     1 | 1208449356 |
> 0 |   16 |                        |            |
> sip:pge354*xmpp.domain at xmpp-gw | 6ce7eb87-1700 at 10.95.43.31 |
> 10.1700.1208445755.35 | 533cb9e91f4b999cf76861cbb9ed54ed-9c6c |   10 | NULL
> |                      |       0 |               |
>
> | 18420 | sip:pge354*xmpp.domain at xmpp-gw    |         |     1 | 1208446132 |
> 0 |    8 | a.1208441749.1700.12.0 | 0xbf9787bc |                      |
> |                       |                                       |    0 |
> |                      |       0 |               |
>
> | 18427 | sip:800094 at openser.domain |         |     1 | 1208449357 |
> 1208449345 |   16 |                        |            |
> sip:pge354*xmpp.domain at xmpp-gw | 6ce7eb87-1701 at 10.95.43.31 |
> 10.1703.1208445756.21 | 533cb9e91f4b999cf76861cbb9ed54ed-463c |   10 |
> |                      |       0 |               |
>
> | 18426 | sip:800094 at openser.domain |         |     1 | 1208449357 |
> 1208449355 |   16 |                        |            |
> sip:pge354*xmpp.domain at xmpp-gw | 6ce7eb9f                  |
> 10.1700.1208445756.36 | 533cb9e91f4b999cf76861cbb9ed54ed-6582 |   10 |
> | sip:pge354*xmpp.domain at xmpp-gw |       0 |               |
>
> | 18423 | sip:pge354*xmpp.domain at xmpp-gw    |         |     1 | 1208446287 |
> 0 |    8 | a.1208441749.1701.17.0 |            |                      |
> |                       |                                       |    0 |
> |                      |       0 |               |
>
> | 18425 | sip:354354 at openser.domain |         |     1 | 1208449228 |
> 0 |   16 |                        |            |
> sip:pge354*xmpp.domain at xmpp-gw | 6ce7eb98                  |
> 10.1700.1208445628.32 | 533cb9e91f4b999cf76861cbb9ed54ed-da39 |   10 |
> | sip:pge354*xmpp.domain at xmpp-gw |       0 |               |
>
> | 18438 | sip:354354 at openser.domain |         |     1 | 1208449387 |
> 0 |   16 |                        |            |
> sip:pge354*xmpp.domain at xmpp-gw | 6ce7eb91-1703 at 10.95.43.31 |
> 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:pge354*xmpp.domain at xmpp-gw">
>   <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:pge354*xmpp.domain at xmpp-gw">
>   <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:pge354*xmpp.domain at xmpp-gw">
>   <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:anca at voice-system.ro] 
> Enviado el: jueves, 17 de abril de 2008 11:13
> Para: Pablo Guijarro Enríquez
> CC: users at 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:pge354*xmpp-domain at xmpp-gw"
>> 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:anca at voice-system.ro] 
>> Enviado el: viernes, 11 de abril de 2008 15:51
>> Para: Pablo Guijarro Enríquez
>> CC: users at 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:pge*xmpp.domain at xmpp-gw SIP/2.0
>>> Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKbca.c6e4c5f1.0
>>> To: sip:pge*xmpp.domain at xmpp-gw;tag=10.12575.1207664296.3
>>> From:
>>>     
>>>       
>> sip:pge*xmpp.domain at xmpp-gw;tag=533cb9e91f4b999cf76861cbb9ed54ed-2ab3
>>   
>>     
>>> CSeq: 11 SUBSCRIBE
>>> Call-ID: 77e00002-12580 at 10.95.43.31
>>> 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:pge*xmpp.domain at xmpp-gw SIP/2.0
>>> Via: SIP/2.0/UDP 10.95.43.31;branch=z9hG4bKafa2.9020b137.0
>>> To: sip:pge*xmpp.domain at xmpp-gw
>>> From: sip:
>>>     
>>>       
>> pge*xmpp.domain at xmpp-gw;tag=533cb9e91f4b999cf76861cbb9ed54ed-5c38
>>   
>>     
>>> CSeq: 10 SUBSCRIBE
>>> Call-ID: 77e00001-12581 at 10.95.43.31
>>> 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:anca at voice-system.ro] 
>>> Enviado el: martes, 08 de abril de 2008 16:07
>>> Para: Pablo Guijarro Enríquez
>>> CC: users at 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:anca at voice-system.ro] 
>>>> Enviado el: martes, 08 de abril de 2008 14:30
>>>> Para: Pablo Guijarro Enríquez
>>>> CC: users at 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 at lists.openser.org
>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>   
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>>   
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>>   
>>     
>
>
>   





More information about the Users mailing list