9 Oct
2009
9 Oct
'09
6:49 a.m.
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(a)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(a)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:
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 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?