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@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@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@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@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@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@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
Am 15.12.2010 13:00, schrieb Klaus Darilion:
Hi!
- 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&revisi...
klaus
Klaus Darilion writes:
guess we should port some bugfixes http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revisi...
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
2010/12/15 Juha Heinanen jh@tutpro.com:
no-one else in sr community was interested in presence
Some of us are interested in SIP presence, but not in SIMPLE :)
Am 15.12.2010 14:31, schrieb Juha Heinanen:
Klaus Darilion writes:
guess we should port some bugfixes http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revisi...
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
That might be a valuable solution. On the other hand Kamailio as an embedded XCAP server which I like.
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
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
Am 15.12.2010 16:26, 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.
embedded xcap server indeed is an appealing solution.
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.
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
2010/12/21 Juha Heinanen jh@tutpro.com:
i could try that too once some more pressing issues have been solved.
Has been the whole SIMPLE spec solved? XD
Am 21.12.2010 15:29, schrieb Iñaki Baz Castillo:
2010/12/21 Juha Heinanenjh@tutpro.com:
i could try that too once some more pressing issues have been solved.
Has been the whole SIMPLE spec solved? XD
No. But there are SIMPLE installations out there and we have to live with it ...
Am 21.12.2010 14:57, schrieb Juha Heinanen:
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.
Ok. That would describes several my-crashes I had ;-)
On 12/15/10 3:55 PM, Klaus Darilion wrote:
Am 15.12.2010 14:31, schrieb Juha Heinanen:
Klaus Darilion writes:
guess we should port some bugfixes http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revisi...
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
That might be a valuable solution. On the other hand Kamailio as an embedded XCAP server which I like.
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.
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
Am 15.12.2010 18:11, schrieb Daniel-Constantin Mierla:
On 12/15/10 3:55 PM, Klaus Darilion wrote:
Am 15.12.2010 14:31, schrieb Juha Heinanen:
Klaus Darilion writes:
guess we should port some bugfixes http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revisi...
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
That might be a valuable solution. On the other hand Kamailio as an embedded XCAP server which I like.
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.
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.
Just wait a bit, I already have some patches
klaus
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 -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen -
Klaus Darilion