[Kamailio-Users] Presence issue - pua dialoginfo

[Klaus Darilion]

Francisco Javier Lizarán Vilches schrieb:
> Hi Klaus: Do you think it would be so difficult to extend the dialog
> module to store request-URI in the dialog-info structure in order to
> give the option to pua_dialoginfo to use RURI instead of To-URI? 
> Regards:

I think it would be easy, if someone with core knowledge does it - 
Daniel? ;-)

regards
klaus

> 
> Francisco Javier Lizarán Vilches 
> ---------------------------------------------- BARIK (Grupo
> Ormazabal) Departamento Técnico Tel.: +34 917 479 900 www.barik.es 
> ---------------------------------------------- -----Mensaje
> original----- De: Klaus Darilion
> [mailto:klaus.mailinglists at pernau.at] Enviado el: lunes, 21 de
> septiembre de 2009 15:41 Para: Daniel-Constantin Mierla CC: Francisco
> Javier Lizarán Vilches; users at lists.kamailio.org Asunto: Re:
> [Kamailio-Users] Presence issue - pua dialoginfo
> 
> 
> 
> Daniel-Constantin Mierla schrieb:
>> Hello,
>> 
>> On 10.09.2009 16:00 Uhr, Francisco Javier Lizarán Vilches wrote:
>>> Hi all:
>>> 
>>> I have a problem using Kamailio 1.5.2 as proxy&presence server.
>>> User A is subscribed to B's event dialog, and Kamailio handles
>>> this subscription. When a call arrives to pstn number C, the
>>> proxy resolves it via ENUM and sends the INVITE to B. The issue
>>> is that the PUBLISH request uri is C, because pua_dialoginfo
>>> module looks into To uri instead of Request uri, so A is not
>>> informed about B state. Has anybody any idea to work around this?
>>> 
>>> 
>> pua_dialoginfo reuses dialog module structure which saves only the
>>  from_uri and to_uri (they might be needed latter to construct
>> BYE).
>> 
>> I think the solution is to save R-URI in dialog structure and use
>> it instead. Klaus, what do you think, is something required in this
>> respect from the dialog info RFC?
> 
> I had the same ideo some time ago. RURI should be stored in dialog 
> structure too, and should be used instead of To-URI (better: make it
> a module parameter which one to choose)
> 
> IIRC the problem is not the SIP signaling (PUBLISH/SUBSCRIBE/NOTIFY)
> - this can be overcome by using the same URI-rewriting for all
> requests. I guess the problem is in the generation of the XML-body of
> the PUBLISH request.
> 
> Maybe some clients accept the NOTIFY only if the entity parameter 
> matches the subscribed URI. From RFC 4235:
> 
> o  entity: This attribute contains a URI that identifies the user 
> whose dialog information is reported in the remainder of the 
> document.  This user is referred to as the "observed user".
> 
> 
> For example: A calls B. B is an alias for C. There are 2 watchers, W1
>  subscribed dialoginfo of B and W2 subscribed dialoginfo of C.
> 
> Now, if C starts ringing, a PUBLISH is produced, which causes NOTIFYs
> to be sent to W1 and W2. Probably W1 processes the XML body only if
> the entity parameter matches the subscribed URI (B), whereas W2
> processes it only if the entity parameter contains C.
> 
> Thus, hard to solve.
> 
> 
> 
> regards klaus