15 Dec
2010
15 Dec
'10
2 p.m.
Hi!
I tested with sipp a simple scenario and detected 2 strange issues:
U 2010/12/15 12:53:28.887255 83.136.32.148:5061 -> 83.136.32.148:5060
SUBSCRIBE sip:klaus3000@a1.net SIP/2.0.
Via: SIP/2.0/UDP 83.136.32.148:5061;branch=z9hG4bK-8140-1-0.
From: <sip:klaus3000@a1.net>;tag=1.
To: <sip:test_ipcom@a1.net>.
Call-ID: 1-8140(a)83.136.32.148.
CSeq: 1 SUBSCRIBE.
Contact: sip:foobar@83.136.32.148:5061.
Content-Length: 0.
Expires: 90.
Event: presence.
Accept: application/pidf+xml, application/xpidf+xml.
Supported: eventlist.
Accept: application/rlmi+xml.
Accept: multipart/related.
.
#
U 2010/12/15 12:53:28.959045 83.136.32.148:5060 -> 83.136.32.148:5061
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 83.136.32.148:5061;branch=z9hG4bK-8140-1-0.
From: <sip:klaus3000@a1.net>;tag=1.
To: <sip:test_ipcom@a1.net>;tag=86f18ea7b9f37b01834bd9036fb6c8f3-8bc8.
Call-ID: 1-8140(a)83.136.32.148.
CSeq: 1 SUBSCRIBE.
Expires: 90.
Contact: <sip:foobar@83.136.32.148:5061>.
Require: eventlist.
Server: kamailio (3.1.1 (i386/linux)).
Content-Length: 0.
.
U 2010/12/15 12:53:28.969138 83.136.32.148:5060 -> 83.136.32.148:5061
NOTIFY sip:foobar@83.136.32.148:5061 SIP/2.0.
Via: SIP/2.0/UDP 83.136.32.148;branch=z9hG4bK7f54.f84fd565.0.
To: sip:klaus3000@a1.net;tag=1.
From: sip:test_ipcom@a1.net;tag=86f18ea7b9f37b01834bd9036fb6c8f3-8bc8.
CSeq: 1 NOTIFY.
Call-ID: 1-8140(a)83.136.32.148.
Content-Length: 418.
User-Agent: kamailio (3.1.1 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Contact: <sip:83.136.32.148:5060;transport=udp>.
Subscription-State: active;expires=90.
Require: eventlist.
Content-Type: "multipart/related;type="application/rlmi+xml";start=
<1292414008.sip:klaus3000@a1.net.1594182384>;boundary=QUaqGeLBLc3NtSZsiWrjFAnu.
.
--QUaqGeLBLc3NtSZsiWrjFAnu.
Content-Transfer-Encoding: binary.
Content-ID: <1292414008.sip:klaus3000@a1.net.1594182384>.
Content-Type: application/rlmi+xml;charset="UTF-8r".
.
<?xml version="1.0"?>
<list uri="sip:klaus3000@a1.net"
xmlns="urn:ietf:params:xml:ns:rlmi"
version="1" fullState="true">
<resource uri="sip:asdfasf@a1.net"/>
<resource uri="sip:test_ipcom@a1.net"/>
</list>
.
--QUaqGeLBLc3NtSZsiWrjFAnu--.
#
U 2010/12/15 12:53:28.969304 83.136.32.148:5061 -> 83.136.32.148:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 83.136.32.148;branch=z9hG4bK7f54.f84fd565.0.
From: sip:test_ipcom@a1.net;tag=86f18ea7b9f37b01834bd9036fb6c8f3-8bc8.
To: sip:klaus3000@a1.net;tag=1;tag=1.
Call-ID: 1-8140(a)83.136.32.148.
CSeq: 1 NOTIFY.
Contact: sip:foobar@83.136.32.148:5061.
Content-Length: 0.
.
##
U 2010/12/15 12:53:33.970997 83.136.32.148:5061 -> 83.136.32.148:5060
SUBSCRIBE sip:klaus3000@a1.net SIP/2.0.
Via: SIP/2.0/UDP 83.136.32.148:5061;branch=z9hG4bK-8140-1-6.
From: <sip:klaus3000@a1.net>;tag=1.
To: <sip:test_ipcom@a1.net>;tag=86f18ea7b9f37b01834bd9036fb6c8f3-8bc8.
Call-ID: 1-8140(a)83.136.32.148.
CSeq: 2 SUBSCRIBE.
Contact: sip:foobar@83.136.32.148:5061.
Content-Length: 0.
Expires: 0.
Event: presence.
Accept: application/pidf+xml, application/xpidf+xml.
Supported: eventlist.
Accept: application/rlmi+xml.
Accept: multipart/related.
.
#
U 2010/12/15 12:53:33.972115 83.136.32.148:5060 -> 83.136.32.148:5061
SIP/2.0 400 Stale Cseq Value.
Via: SIP/2.0/UDP 83.136.32.148:5061;branch=z9hG4bK-8140-1-6.
From: <sip:klaus3000@a1.net>;tag=1.
To: <sip:test_ipcom@a1.net>;tag=86f18ea7b9f37b01834bd9036fb6c8f3-8bc8.
Call-ID: 1-8140(a)83.136.32.148.
CSeq: 2 SUBSCRIBE.
Server: kamailio (3.1.1 (i386/linux)).
Content-Length: 0.
.
1. Why is the Contact header in 200 OK (SUBSCRIBE) wrong? Looks like
Kamailio just copies the received contact header instead putting itself
into contact.
2. Why does Kamailio reply with "400 Stale Cseq Value." on the
reSUBSCRIBE? CSeq is fine.
regards
Klaus
15 Dec
15 Dec
3:21 p.m.
Am 15.12.2010 13:00, schrieb Klaus Darilion:
Hi!
1. Why is the Contact header in 200 OK (SUBSCRIBE) wrong? Looks like
Kamailio just copies the received contact header instead putting itself
into contact.
guess we should port some bugfixes
http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revis…
klaus
3:31 p.m.
Klaus Darilion writes:
guess we should port some bugfixes
http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revis…
klaus,
there are tons of those. in the beginning i tried to keep track, but it
looked like no-one else in sr community was interested in presence, so i
gave up and started to use opensips as my presence server. opensips too
has its shortcomings, such as lack of oma support in xcap authorization,
but looks like it is being active developed on. it would take couple of
sr people full time for at least half a year to catch up.
-- juha
4:55 p.m.
Am 15.12.2010 14:31, schrieb Juha Heinanen:
Klaus Darilion writes:
That might be a valuable solution. On the other hand Kamailio as an
embedded XCAP server which I like.
guess we should port some bugfixes
http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revis…
klaus,
there are tons of those. in the beginning i tried to keep track, but it
looked like no-one else in sr community was interested in presence, so i
gave up and started to use opensips as my presence server. opensips too has its shortcomings, such as lack of oma support in
xcap authorization,
What exactly is missing? What kind of authorization is needed for OMA
support?
but looks like it is being active developed on. it
would take couple of
sr people full time for at least half a year to catch up.
I guess if people like me do it: yes. :-)
If a core developer would do it I think it would be faster.
regards
Klaus
5:26 p.m.
Klaus Darilion writes:
That might be a valuable solution. On the other hand
Kamailio as an
embedded XCAP server which I like.
embedded xcap server indeed is an appealing solution.
What exactly is missing? What kind of authorization is
needed for OMA
support?
what i have seen, in oma xcap documents allow and block lists are kept
in separate resource lists stored in xcap server, which are referenced
in pres-rules document. looks like opensips and sr presence server is
not able to follow those links, but assumes that the lists are kept
inline in pres-rules document.
-- juha
21 Dec
21 Dec
3:57 p.m.
Am 15.12.2010 16:26, schrieb Juha Heinanen:
Klaus Darilion writes:
Juha, I now tried opensips as presence server as well (already detect
some bugs :-) but still use Kamailio's xcap module. I just configured
xcap module to write directly into opensips' database (you have to
change the accepted table-version in xcap module).
regards
Klaus
PS: I wonder how different are the module interfaces of opensips and
kamailio, if it would be possible to copy the whole presence modules to
Kamailio and just fix the module API.
That might be a valuable solution. On the other
hand Kamailio as an
embedded XCAP server which I like.
embedded xcap server indeed is an appealing solution.
3:57 p.m.
Klaus Darilion writes:
Juha, I now tried opensips as presence server as well
(already detect
some bugs :-) but still use Kamailio's xcap module. I just configured
xcap module to write directly into opensips' database (you have to
change the accepted table-version in xcap module).
good to hear. i could try that too once some more pressing issues have
been solved.
PS: I wonder how different are the module interfaces
of opensips and
kamailio, if it would be possible to copy the whole presence modules to
Kamailio and just fix the module API.
module interface may not be a big issue, but db interface is very
different, because opensips uses prepared statements, which in turn
introduced numerous bugs into opensips presence server.
-- juha
5:41 p.m.
Am 21.12.2010 15:29, schrieb Iñaki Baz Castillo:
2010/12/21 Juha Heinanen<jh(a)tutpro.com>om>:
No. But there are SIMPLE installations out there and we have to live
with it ...
i could try that too once some more pressing
issues have
been solved.
Has been the whole SIMPLE spec solved? XD
5:40 p.m.
Am 21.12.2010 14:57, schrieb Juha Heinanen:
Ok. That would describes several my-crashes I had ;-)
PS: I wonder
how different are the module interfaces of opensips and
kamailio, if it would be possible to copy the whole presence modules to
Kamailio and just fix the module API.
module interface may not be a big issue, but db interface is very
different, because opensips uses prepared statements, which in turn
introduced numerous bugs into opensips presence server. 
15 Dec
15 Dec
7:11 p.m.
On 12/15/10 3:55 PM, Klaus Darilion wrote:
Am 15.12.2010 14:31, schrieb Juha Heinanen:
the bug you reported
regarding the contact I remember that was reported
to me and I guess it was fixed. I will double check to see if something
is still wrong there.
Most of the presence modules for kamailio are working fine -- I have
running presence services on couple servers and nobody reported any
issue so far. rls is not easy to test as not many have support for it. I
paid bria license for mac os x and it is full of bugs, I reported an
issue about two months ago and got no answer so far.
Like Inaki said, not sure how many operators will invest much more in
SIMPLE "crazy extensions" (even the ietf group is not much active
lately), but the core presence specification should work fine with
kamailio these days.
About one year ago I did quite some fixes, so looking to see if there
are any ports from forks might not be wise. It is better to directly
report the issue and I can take care. To my knowledge, Alex Hermann
reported some potential race when sending requests via tm on sourceforge
tracker with a patch, but was not providing the proper fix - I should
review that issue as well.
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
Klaus Darilion writes:
That might be a valuable solution. On the other hand Kamailio as an
embedded XCAP server which I like.
guess we should port some bugfixes
http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revis…
klaus,
there are tons of those. in the beginning i tried to keep track, but it
looked like no-one else in sr community was interested in presence, so i
gave up and started to use opensips as my presence server. opensips too has its shortcomings, such as lack of oma support
in xcap authorization,
What exactly is missing? What kind of authorization is needed for OMA
support?
but looks like it is being active developed on.
it would take couple of
sr people full time for at least half a year to catch up.
I guess if people like me do it: yes. :-)
If a core developer would do it I think it would be faster.
7:18 p.m.
Am 15.12.2010 18:11, schrieb Daniel-Constantin Mierla:
On 12/15/10 3:55 PM, Klaus Darilion wrote:
Just wait a bit, I already have some patches
klaus
Am 15.12.2010 14:31, schrieb Juha Heinanen:
the bug you reported
regarding the contact I remember that was reported
to me and I guess it was fixed. I will double check to see if something
is still wrong there. Klaus Darilion writes:
That might be a valuable solution. On the other hand Kamailio as an
embedded XCAP server which I like.
guess we should port some bugfixes
http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revis…
klaus,
there are tons of those. in the beginning i tried to keep track, but it
looked like no-one else in sr community was interested in presence, so i
gave up and started to use opensips as my presence server. opensips too has its shortcomings, such as lack of oma support
in xcap authorization,
What exactly is missing? What kind of authorization is needed for OMA
support?
but looks like it is being active developed on.
it would take couple of
sr people full time for at least half a year to catch up.
I guess if people like me do it: yes. :-)
If a core developer would do it I think it would be faster. 
16 Dec
16 Dec
10:40 a.m.
On Wednesday 15 December 2010 18:11:40 Daniel-Constantin Mierla wrote:
About one year ago I did quite some fixes, so looking
to see if there
are any ports from forks might not be wise. It is better to directly
report the issue and I can take care. To my knowledge, Alex Hermann
reported some potential race when sending requests via tm on sourceforge
tracker with a patch, but was not providing the proper fix - I should
review that issue as well.
The problem with Kamailio's presence is that it has locking issues. Pua as
well as presence itself lock structures while waiting for a reply. If multiple
presence updates arrive for the same presentity while the lock is still held,
Kamailio will get in a loop consuming 100% cpu.
While I was trying to fix this, Anca Vamanu was at the same time fixing the
issue in Opensips. Her solution was a bit cleaner than mine so I ported some
of the pua fixes to Kamailio and improved them, but they still need some care.
Unfortunately I ran out of time.
Bottom line of the solution is to create a queue of updates for each
presentity and feed them one by one to the pua/presence core without locking
while waiting for a reply.
--
Alex Hermann
5085
days inactive
5091
days old
13 comments
5 participants
participants (5)
-
Alex Hermann -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen -
Klaus Darilion