[Kamailio-Users] Presence issue - pua dialoginfo

Francisco Javier Lizarán Vilches flv at barik.es
Tue Oct 6 13:30:11 CEST 2009


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:

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



More information about the Users mailing list