[Kamailio-Users] Presence issue - pua dialoginfo

[Francisco Javier Lizarán Vilches]

Hi Klaus,

We have given it a try and we have modified the code in order to implement this functionality. We are not familiar with the kamailio code and are not sure if the modification is correct. 
Where is the appropriate place to post the patch so it can be reviewed?

Regards:
Francisco
-----Mensaje original-----
De: Klaus Darilion [mailto:klaus.mailinglists at pernau.at] 
Enviado el: martes, 06 de octubre de 2009 14:43
Para: Francisco Javier Lizarán Vilches
CC: Daniel-Constantin Mierla; users at lists.kamailio.org
Asunto: Re: [Kamailio-Users] Presence issue - pua dialoginfo



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