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@pernau.at] Enviado el: martes, 06 de octubre de 2009 14:43 Para: Francisco Javier Lizarán Vilches CC: Daniel-Constantin Mierla; users@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@pernau.at] Enviado el: lunes, 21 de septiembre de 2009 15:41 Para: Daniel-Constantin Mierla CC: Francisco Javier Lizarán Vilches; users@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