HI
I just did simple test-case: add user and delete user on kamailio 3.3
on 101 , I added 103, the watcher tables shows:
select * from watchers;
+----+------------------------+------------------+----------------+----------+--------+--------+---------------+
| id | presentity_uri | watcher_username | watcher_domain |
event | status | reason | inserted_time |
+----+------------------------+------------------+----------------+----------+--------+--------+---------------+
| 1 | sip:103@192.168.122.32 | 101 | 192.168.122.32 |
presence | 2 | | 1339772803 |
+----+------------------------+------------------+----------------+----------+--------+--------+---------------+
then I deleted the 103 from the contact list, the watcher table
still shows the same.
It seems a strange behavior, should this to be deleted from the db?
what's the expected behavior on the watchers table for delete/adding
user?
In my previos email testing case, there is terminated status=3 in
db, when will this item will be deleted?
http://lists.sip-router.org/pipermail/sr-users/2012-June/073621.html
From the http://tools.ietf.org/html/rfc3857#section-4.7.1, there is
nowhere to go if it it is in the terminated status.
subscribe,
policy= +----------+
reject | |<------------------------+
+------------>|terminated|<---------+ |
| | | | |
| | | |noresource |
| +----------+ |rejected |
| ^noresource |deactivated |
| |rejected |probation |
| |deactivated |timeout |noresource
| |probation | |rejected
| |giveup | |giveup
| | | |approved
+-------+ +-------+ +-------+ |
| |subscribe| |approved| | |
| init |-------->|pending|------->|active | |
| |no policy| | | | |
| | | | | | |
+-------+ +-------+ +-------+ |
| | ^ |
| subscribe, | | |
+-----------------------------------+ |
policy = accept | +-------+ |
| | | |
| |waiting|----------+
+----------->| |
timeout | |
+-------+
Figure 1: Subscription State Machine
just FYI, there were some discussions before regarding the deletion, state machine.
http://sip-router.org/tracker/index.php?do=details&task_id=133http://lists.opensips.org/pipermail/devel/2009-August/003868.html
min
Hi,
I use 'rtimer' and 'mqueue' to asynchronously defer certain heavy DB
tasks on which call processing does not depend.
I was hoping to get a clarification on the exact behaviour of 'rtimer'
when tasks don't complete as fast as they should.
Let's say that I set the rtimer route interval to half a second (500
ms), as afforded by new Kamailio 3.3.0 capabilities. What happens if
the tasks I am running inside the rtimer route don't complete in that
interval? Is that rtimer thread forceably terminated, or is it allowed
to run as long as necessary to complete the task? Is there an absolute
timeout? If the latter, I assume that another, parallel rtimer route
will be started in the background after 500 ms. I am given to
understand that there is a thread pool. How big is it? Can I configure
its size anywhere? Is there a practical limit?
Finally, is there 100% assurance that 'mqueue' is safe to consume for
multiple rtimer processes, possibly ones tripping over each other due to
unpredictable delays? Or is it designed only to provide blocking mutex
for data passed from a SIP worker thread to a different kind of thread?
Thanks!
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Hi,
I am testing kamailio replies when an INVITE or another request arrives
with lets say, "VIA" header missing....
The core drops the request. But, there is no reply for the originator (so
it keep on resending the request...)
Why?
Uri
Hello
Seems Siremis 3.2.1 doesn't support configuration of drouting. Any plans
that it will in the future? I hope to use it to make my drouting
configuration easier.
What I want to do is to route prefixed numbers to external number at
external domains, depending on the prefix (numbers+alphabets+dot and
maybe+underscore+hyphen as well). Maybe I should use PDT module instead
as it is supported by Siremis?
Thanks!
Yufei
--
Yufei Tao
Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
Hello,
On 6/14/12 10:28 AM, Gertjan Wolzak wrote:
>
> Hello All,
>
> I have the following challenge.
>
> We are using kamailio 3.2 and have enabled presence. Which works fine.
>
> But we would like to be able to work with aliases, so that the account
> name and "presentation" name can be different.
>
> Any Ideas... Or did I miss the documentation on that?
>
the account name is public or not? If it is some internal id, eventually
is used for authentication, but for presence the contacts should know
the public id.
Or maybe you can give some example to understand how you use aliases in
the context of presence...
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
HI
Since my previous email has attachment , it is still waiting for
the approval.
So here is again the text part ( please see the email below)
According to the trace, here is the call flow for this case:
101(.224) --- proxy (.32) --- 103 (.1)
101/103 are jitsi 1.1 nightly build client, the configure is to use
SIMPLE/xcap on clients.
the call flow for 101 adding 103 as contact
101 proxy 103
| | |
user-add-103 | |
| | |
| xcap put pres/rls | |
|--------------------------> | |
| | |
| SUBSCRIBE (presence/103) | |
|---------------------------> | |
| 202 ok | |
|<----------------------------| |
| NOTIFY( presenc/pending) | |
|<----------------------------| |
| | NOTIFY ( winfo/101 pending) |
| |---------------------------------->|
| 200 ok | |
|--------------------------> | |
| | 200 OK |
| |<----------------------------------|
| | auth window pop
| | user accept
| | SUBSRIBE(presence/101) |
| |<----------------------------------|
| | 202 OK |
| |---------------------------------->|
| NOTIFY (winfo,103 active) | |
|<-------------------------- | |
| 200 ok | |
|--------------------------> | |
| | NOTIFY (presence/101) |
| |---------------------------------> |
| | 200 OK |
| |<----------------------------------|
| NOTIFY (presence/103 open) | |
|<-------------------------- | | ****** ( missing part)
| 200 ok | |
|--------------------------> | |
As on the 103, auth windows pop up, then click ok to accept (thus it will added 101 as contact), in this case it does not do any xcap operation?
Is it the correct call flow?
Thanks
min
On 06/19/2012 04:49 PM, Min Wang wrote:
> Hi
>
> Here is another similar case which does not work. maybe it is related
> the above issue as well.
>
> Jitsi 1.1 client: 101/103 , with xcap as storage
> proxy: kamailio 3.3
> ip network is: 192.168.122.0
>
> the setup is like the following:
>
> 101(.224) --- proxy (.32) --- 103 (.1)
>
> After all presence related db are truncated, kamailio was restart.
> then bring 101,103 online.
>
> On 101 add 103, 103 prompt up authorization window, click ok.
> now on 103, I can see 101 online status
>
> but on 101, I can not see 103 status <----the first trace file: the
> jitsi-101-add-103-confirm-2.pcap
>
> (it is grey, even manually change 103 status from online to away
> etc, on 101, the 103 always showed grey. <--- second trace file:
> jitsi-101-103-change.pcap)
>
> Please see the attached pcap files.
>
>
> the watcher table shows:
>
> id presentity_uri watcher_username watcher_domain
> event status reason inserted_time
> 1 sip:103@192.168.122.32 101 192.168.122.32
> presence 2 1340114579
> 2 sip:101@192.168.122.32 103 192.168.122.32
> presence 1 1340114582
>
> the active wacher table show:
>
> id presentity_uri watcher_username watcher_domain
> to_user to_domain event event_id to_tag from_tag
> callid local_cseq remote_cseq contact record_route
> expires status reason version socket_info
> local_contact from_user from_domain updated updated_winfo
> 1 sip:101@192.168.122.32 101 192.168.122.32
> 101 192.168.122.32 message-summary
> a6a1c5f60faecf035a1ae5b6e96e979a-7e2e 8b6ca8e7
> 9e8288d04d0dab18fda28f5fb24b40d8(a)0.0.0.0 1 2
> sip:101@192.168.122.224:5060;transport=udp;registe...
> 1340117922 1 1 udp:192.168.122.32:5060
> sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1
> 2 sip:101@192.168.122.32 101 192.168.122.32
> 101 192.168.122.32 presence.winfo
> a6a1c5f60faecf035a1ae5b6e96e979a-8a99 9975004d
> 9b8cb0735bc559232639aa28c16a6f4b(a)0.0.0.0 2 2
> sip:101@192.168.122.224:5060;transport=udp;registe...
> 1340117921 1 2 udp:192.168.122.32:5060
> sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1
> 3 sip:103@192.168.122.32 103 192.168.122.32
> 103 192.168.122.32 message-summary
> a6a1c5f60faecf035a1ae5b6e96e979a-0117 9d873afb
> 30fa1ce8cca7a7c50fea11e688ec3d5e@0:0:0:0:0:0:0:0 1 2
> sip:103@192.168.122.1:5060;transport=udp;registeri...
> 1340117959 1 1 udp:192.168.122.32:5060
> sip:192.168.122.32:5060;transport=udp 103 192.168.122.32 -1 -1
> 4 sip:103@192.168.122.32 103 192.168.122.32
> 103 192.168.122.32 presence.winfo
> a6a1c5f60faecf035a1ae5b6e96e979a-9a71 101d721c
> 148be0ec1a4acc087c0083324398cf14@0:0:0:0:0:0:0:0 2 2
> sip:103@192.168.122.1:5060;transport=udp;registeri...
> 1340117959 1 2 udp:192.168.122.32:5060
> sip:192.168.122.32:5060;transport=udp 103 192.168.122.32 -1 -1
> 5 sip:103@192.168.122.32 101 192.168.122.32
> 103 192.168.122.32 presence
> a6a1c5f60faecf035a1ae5b6e96e979a-5ab7 e9099546
> 6ed81a0fa2042996295974b671a8074f(a)0.0.0.0 1 2
> sip:101@192.168.122.224:5060;transport=udp;registe...
> 1340118179 2 1 udp:192.168.122.32:5060
> sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1
> 6 sip:101@192.168.122.32 103 192.168.122.32
> 101 192.168.122.32 presence
> a6a1c5f60faecf035a1ae5b6e96e979a-98a8
>
>
>
>
> thanks
>
> min
>
> On 06/19/2012 01:00 PM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> you have to share the content of the messages sent, providing just
>> the url is not enough to see what happens.
>>
>> watchers table is for the list of contacts and their global status in
>> regard to presentity, active_watchers is for keeping the presence
>> dialogs.
>>
>> Cheers,
>> Daniel
>>
>> On 6/19/12 12:47 PM, Min Wang wrote:
>>> Hi
>>>
>>> (1) I tested more. It is due to the difference between bria 3 and
>>> jitsi while handling the adding/removing contact:
>>>
>>> if contact is added/removed:
>>>
>>> for jitsi, it send out:
>>>
>>> PUT /xcap-root/resource-lists/users/sip:101@192.168.122.32/index
>>> PUT /xcap-root/pres-rules/users/sip:101@192.168.122.32/presrules
>>>
>>>
>>> for bria 3, it only send out
>>>
>>> PUT
>>> /xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
>>> HTTP/1.0.
>>> PUT
>>> /xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
>>>
>>>
>>> it does NOT send out the pres-rules.
>>>
>>> Is it the good behavior ( from RFC point of view) ?
>>> should I call the pres_update_watchers even though its is for
>>> resource-lists?
>>>
>>> (2) BTW, what is the exact purpose of watcher table?
>>>
>>> e.g: on 101, if delete 103, watcher table become:
>>>
>>> id presentity_uri watcher_username
>>> watcher_domain event status reason inserted_time
>>> 1 sip:103@192.168.122.32 101 192.168.122.32
>>> presence 1 1340096051
>>> 2 sip:101@192.168.122.32 103 192.168.122.32
>>> presence 3 terminated 1340096181
>>>
>>> it is item 2 become terminated instead of item 1. If watcher
>>> table is for subscription, then seems item 1 should be terminated?
>>> Look at the code, it seems somehow serve as mixed role of
>>> subscription/auth/xcap purpose, not for subscription state?
>>>
>>> and is the active_watcher mainly for the state machine of
>>> http://tools.ietf.org/html/rfc3857#section-4.7.1?
>>>
>>> thanks.
>>>
>>>
>>> min
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 06/19/2012 10:41 AM, Daniel-Constantin Mierla wrote:
>>>> Hello,
>>>>
>>>> On 6/18/12 2:11 PM, Andreas Granig wrote:
>>>>> Hi,
>>>>>
>>>>> On 06/15/2012 05:25 PM, Min Wang wrote:
>>>>>> | 1 | sip:103@192.168.122.32 | 101 | 192.168.122.32 |
>>>>>> presence | 2 | | 1339772803 |
>>>>>>
>>>>>> then I deleted the 103 from the contact list, the watcher
>>>>>> table still
>>>>>> shows the same.
>>>>> For local storage, I'd expect an unsubscribe (subscribe with
>>>>> Expires=0)
>>>>> from 101 to 103. The obvious work-flow would be to set it to
>>>>> "terminated" in watchers table, and in case of a subsequent
>>>>> re-subscribe
>>>>> it should be changed back to "pending" state, although the
>>>>> state-machine
>>>>> doesn't indicate a transition from "terminated" back to "pending".
>>>>> Isn't
>>>>> this the case?
>>>>>
>>>>> For xcap storage, there are other ways to block/remove a contact
>>>>> on/from
>>>>> the list. As Iñaki pointed out in
>>>>> http://lists.opensips.org/pipermail/devel/2009-August/003868.html,
>>>>> the
>>>>> xcap server needs to notify the sip server about the change, which in
>>>>> turn will notify the other party (103) that it's no longer allowed to
>>>>> see 101's state. If the xcap_server module of kamailio is used,
>>>>> there is
>>>>> the following code snippet in some examples floating around on the
>>>>> internet:
>>>>>
>>>>>
>>>>> switch($rm) {
>>>>> case "PUT":
>>>>> xcaps_put("$var(uri)", "$hu", "$rb");
>>>>> if($xcapuri(u=>auid)=~"pres-rules") {
>>>>> pres_update_watchers("$var(uri)", "presence");
>>>>> pres_refresh_watchers("$var(uri)", "presence", 1);
>>>>> }
>>>>>
>>>>> So, shouldn't this update the watchers accordingly? Anyways, also in
>>>>> this case the watcher state should change to "terminated", and in
>>>>> case
>>>>> of a re-subscribe it should go back to pending if xcap rules are
>>>>> allowing this.
>>>>>
>>>>> Maybe someone with good xcap_server/presence insights could
>>>>> elaborate on
>>>>> that?
>>>> to summarize, you say that when the contact is removed from the
>>>> buddy list, the watcher table is not updated to state terminated by
>>>> pres_update_watchers(...)?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
I know that you can set the TOS for packets sent from Kamailio in the config section.
I got the question if you can read the TOS in the IP packet of an incoming response or reply in the config scripts?
And can you set it per message/transaction?
/O
hello,
i ran into a problem installing kamailio when i got to #7 "create
mysql database":
< openser.cfg.5 > /usr/local/share/man//man5/
openser.cfg.5
chmod 644 /usr/local/share/man//man5/openser.cfg.5
sed -e "s#/etc/openser/openser\.cfg#/usr/local/etc/openser/openser.cfg#g" \
-e "s#/usr/sbin/#/usr/local/sbin/#g" \
-e "s#/usr/lib/openser/modules/#/
usr/local/lib64/openser/modules/#g" \
-e "s#/usr/share/doc/openser/#/
usr/local/share/doc/openser/#g" \
< scripts/openserctl.8 > /usr/local/share/man//man8/
openserctl.8
chmod 644 /usr/local/share/man//man8/openserctl.8
sed -e "s#/etc/openser/openser\.cfg#/usr/local/etc/openser/openser.cfg#g" \
-e "s#/usr/sbin/#/usr/local/sbin/#g" \
-e "s#/usr/lib/openser/modules/#/
usr/local/lib64/openser/modules/#g" \
-e "s#/usr/share/doc/openser/#/
usr/local/share/doc/openser/#g" \
< utils/openserunix/openserunix.8 > \
/usr/local/share/man//man8/openserunix.8
chmod 644 /usr/local/share/man//man8/openserunix.8
root@copycall:/usr/local/src/openser-1.3.0/sip-server# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@copycall:/usr/local/src/openser-1.3.0/sip-server# cd
root@copycall:~# /usr/local/etc/kamailio/kamctlrc
bash: /usr/local/etc/kamailio/kamctlrc: No such file or directory
root@copycall:~# /usr/local/sbin/kamdbctl create
bash: /usr/local/sbin/kamdbctl: No such file or directory
any solution will be greatly appreciated, please include all the code
as kamailio is new to me.
thank you in advance,
dave
Hello,
quick note about packaging the 3.3.0 today, therefore if anyone has
commits to push to GIT branch 3.3 after 12:00GMT, please write first to
sr-dev mailing list. Once the announcement about the release is sent
out, the commits can be pushed again directly.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
