[Kamailio-Users] Presence issue - pua dialoginfo

[Klaus Darilion]

Francisco Javier Lizarán Vilches schrieb:
> 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?

Actually, development happens under the sip-router name, thus I suggest 
to put the patch on the sip-router tracker:
http://sip-router.org/tracker/

thanks
klaus


> 
> 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