[Kamailio-Users] presence_dialoginfo context
David
kamailio.org at spam.lublink.net
Thu Aug 13 19:02:24 CEST 2009
Hey,
I tried doing a subst or replace_body_all to change the entity="" value,
if (is_method("PUBLISH") )
{
subst_body('/group1[.]//');
handle_publish();
t_release();
}
It did not work, the $rb variable still shows the old body and the
NOTIFY received on the phone is the old body as well.
I thought about doing a string replace on the outbound NOTIFY but it
never hits my routing script, so I can't.
I read textops and it does not list any limitations relating to me.
Any ideas?
David
Klaus Darilion wrote:
> I think the problem lies within the dialog module. Dialog module
> stores from/to URI. Both, from and to URI are derived from the
> headers. We could extend the dialog module to store request-URI in the
> dialog-info structure too, and add an option to pua_dialoginfo to use
> RURI instead of To-URI.
>
> regards
> klaus
>
> David schrieb:
>> Hey,
>>
>> I think I am doing something wrong, because here is the NOTIFY that
>> comes to the phone :
>>
>> NOTIFY sip:group1.101 at my.home.ip:57234 SIP/2.0
>> Via: SIP/2.0/UDP my.kamailio.ip;branch=z9hG4bK3cab.78e494a4.0
>> To: sip:group1.101 at my.kamailio.domain.name;tag=b2514519391e8b4d
>> From:
>> sip:102 at my.kamailio.domain.name;tag=6d6077e15fecee48b2721a5e94bf8883-f712
>>
>> CSeq: 12 NOTIFY^M Call-ID: 24db3209-611c031d at 192.168.1.104
>> Content-Length: 298
>> User-Agent: MyServer 1.0
>> Max-Forwards: 70
>> Event: dialog
>> Contact: <sip:my.kamailio.domain.name:5060>
>> Subscription-State: active;expires=1570
>> Content-Type: application/dialog-info+xml
>>
>> <?xml version="1.0"?> <dialog-info
>> xmlns="urn:ietf:params:xml:ns:dialog-info" version="11"
>> state="full" entity="group1.102 at my.kamailio.domain.name"> <dialog
>> id="7aaa32e84362a246716009175ad670be at domain.tld"
>> direction="recipient"> <state>early</state> </dialog>
>> </dialog-info>
>>
>> The phone ( I tested with a GXP2000, GXP2020 and SPA962 + SPA932)
>> does not flash lights or anything. Since you suggested that a solid
>> kamailio would work out of the box, I suspect that either I
>> miscommunicated my setup or did something really wrong. The notify
>> definitely gets to the phone and the phone replies 200/OK when it
>> receives the NOTIFY. But I think that the telephone is not
>> understanding the request because it subscribed to '102' but received
>> a notification for 'group1.102'. The funny thing is, the From header
>> matches the subscribe To header, it's just the XML has the full name
>> instead of the shortened name.
>>
>> To:
>> <sip:102 at my.kamailio.domain.name>;tag=6d6077e15fecee48b2721a5e94bf8883-f712
>>
>>
>> I see this in my ( on kamailio ) /var/log/messages :
>>
>> Aug 13 09:55:24 kamailio-dev /usr/sbin/kamailio[25449]:
>> INFO:presence:send_notify_request: NOTIFY
>> sip:group1.101 at my.kamailio.domain.name via
>> sip:development1.101 at my.home.ip.where.phone.is:57234 on behalf of
>> sip:102 at my.kamailio.domain.name for event dialog
>>
>> I should also mention that the NOTIFY sent out by presence bypasses
>> my routing scripts. So I have the PUBLISH come through ( which I
>> leave alone ) and the NOTIFY is sent according to the location table
>> without ever consulting my routing script.
>>
>> So everything amazingly worked out well, except that the lights are
>> not changing status which I think is related to the XML document
>> dialog-info entity attribute containing the group name, sent from my
>> server.
>>
>> Any ideas or suggestions ?
>>
>> Thanks,
>>
>> David
>>
>> Other information :
>>
>> if ( is_method("SUBSCRIBE") )
>> {
>> avp_db_query("select groupname from sometable ",
>> "$avp(s:groupname)");
>> avp_printf("$ru",
>> "sip:$avp(s:zone).$tU at my.kamailio.domain.name");
>> xlog("L_INFO", "Subscribe rewritten from $tU to $ru -
>> M=$rm \n");
>> xlog("L_INFO", "Handling SUBSCRIBE - $fU - $avp(s:zone)
>> - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
>> handle_subscribe();
>> t_release();
>> exit;
>> }
>>
>> Kamailio compiled from sources :
>>
>> Path: /usr/src/kamailio
>> URL: https://openser.svn.sourceforge.net/svnroot/openser/branches/1.5
>> Repository Root: https://openser.svn.sourceforge.net/svnroot/openser
>> Repository UUID: 689a6050-402a-0410-94f2-e92a70836424
>> Revision: 5910
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: henningw
>> Last Changed Rev: 5910
>> Last Changed Date: 2009-08-06 13:08:30 -0400 (Thu, 06 Aug 2009)
>>
>>
>> Klaus Darilion wrote:
>>> notifies are generated by the presence module, based on the
>>> subscription. So, there is nothing you have to do with NOTIFY. Also
>>> PUBLISHs are created internally. Depending on your concrete setup
>>> (e.g. format of the SIP user names) it should work out of the box.
>>>
>>> klaus
>>>
>>> dlublink schrieb:
>>>> What about the notifies?
>>>>
>>>> Klaus Darilion wrote:
>>>>> dlublink wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have three different groups of extensions on my kamailio I want
>>>>>> to be able to separate them, so I prefixed a name to the
>>>>>> extensions, so I have :
>>>>>>
>>>>>> 1. group1.101
>>>>>> 2. group1.102
>>>>>> 3. group2.101
>>>>>> 4. group2.102
>>>>>> 5. group3.102
>>>>>> 6. group3.103.
>>>>>>
>>>>>> The phones from different groups can not call each other, I found
>>>>>> a pseudo variable that I use to rewrite the destination url, so
>>>>>> if user group1.101 dials 102 I rewrite it to group1.102.
>>>>>>
>>>>>> I want to do the same thing for presence_dialog info, how can I
>>>>>> rewrite the subscribe, presence and and notify messages to append
>>>>>> the appropriate prefix ?
>>>>>
>>>>> Just apply the same rewrite you have already done for the INVITE
>>>>> also for the SUBSCRIBE
>>>>>
>>>>> regards
>>>>> klaus
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> _______________________________________________
>>>>>> Kamailio (OpenSER) - Users mailing list
>>>>>> Users at lists.kamailio.org
>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>>
>>
More information about the sr-users
mailing list