is it possible that RTPENGINE failes because 2 rtpengine_offer (2 invites during autharization) and the 183 Reply as I see in the log - is seen as an ANSWER
Both INVITES are with SDP
RTPENGINE_MANAGEThis call is not answered
Received command 'offer' from 127.0.0.1:54490
Creating new call] offer time = 0.000134 sec Replying to 'offer' from 127.0.0.1:54490 Received command 'offer' from 127.0.0.1:53879 offer time = 0.000060 secReplying to 'offer' from 127.0.0.1:53879 Received command 'answer' from 127.0.0.1:40099 answer time = 0.000169 sec Replying to 'anser' from 127.0.0.1:40099 ICE negotiated: local interface 10.34.101.104Confirmed peer address as 10.34.101.104:7458Confirmed peer address as 10.34.101.103:62608
Hi Team,
The SIP packets are fine ,we are able to establish SIP session ,
As long the RTP Proxy not get involved and we are not able to hear
audio,So How to do the proper configuration RTP Proxy,what to do in
RTP Proxy to get the voice for the connected sip session
Regards
Arnab
Hello,
Kamailio 4.3:
I am testing Presence module with more complex scenario. I have 2 SIP
clients (presentity) with equal identities (3918) and one watcher (2025).
All my clients are Monster 0.9.25. My Kamailio Presence module is
configured with "retrieve_order=1" (presentity records are retrieve by
priority order). I have situation when wrong status is send to the watcher
(2025).
1. First all three clients registers and publish its own status. Below
is print from my MySQL database (presentity table)
mysql> select id,username,priority,expires,received_time,body from
presentity ORDER BY received_time DESC;
| id | username | priority | expires | received_time | body
| 84481 | 3918 | 40 | 1464340695 | 1464337095 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr
iding-willingness></dm:person></presence> |
| 84480 | 3918 | 40 | 1464340687 | 1464337087 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr
iding-willingness></dm:person></presence> |
| 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr
iding-willingness></dm:person></presence> |
2. Then first 3918 client publishes his mood >11111<. The status in
>Presentity< table is refreshed under the id=84480. NOTIFY is sent to 2025
with status with mood >11111<.
mysql> select id,username,priority,expires,received_time,body from
presentity ORDER BY received_time DESC;
| id | username | priority | expires | received_time | body
| 84480 | 3918 | 40 | 1464340703 | 1464337103 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>11111</dm:note><op:overriding-willingness><opd:basic>op
en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84481 | 3918 | 40 | 1464340695 | 1464337095 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr
iding-willingness></dm:person></presence> |
| 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr
iding-willingness></dm:person></presence> |
3. After that the second 3918 client publishes his mood >22222<. The
status in >Presentity< table is refreshed under the right id=84481. NOTIFY
is sent to 2025 with status with mood >22222<.
mysql> select id,username,priority,expires,received_time,body from
presentity ORDER BY received_time DESC;
| id | username | priority | expires | received_time | body
| 84481 | 3918 | 40 | 1464340716 | 1464337116 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>22222</dm:note><op:overriding-willingness><opd:basic>op
en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84480 | 3918 | 40 | 1464340703 | 1464337103 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>11111</dm:note><op:overriding-willingness><opd:basic>op
en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr
iding-willingness></dm:person></presence> |
4. Then finally, the first 3918 changes his mood to "33333". The
status in >Presentity< table is refreshed under the right id=84480. BUT, to
2025 is sent NOTIFY with mood "22222". "received_time" timestamp of status
with mood "33333" is higher than timestamp of status with mood "22222". BUT
the "id" attribute of "presentity" table of status with mood "33333" is
smaller. I think that statuses with equal "priority" are retrieved by "id"
and not by "received_time"!?
mysql> select id,username,priority,expires,received_time,body from
presentity ORDER BY received_time DESC;
| id | username | priority | expires | received_time | body
| 84480 | 3918 | 40 | 1464340729 | 1464337129 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>33333</dm:note><op:overriding-willingness><opd:basic>op
en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84481 | 3918 | 40 | 1464340716 | 1464337116 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>22222</dm:note><op:overriding-willingness><opd:basic>op
en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml
version='1.0' encoding='utf-8' ?><presence
entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:op="urn:oma:xml:prs:pidf:oma-pres"
xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple
id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr
iding-willingness></dm:person></presence> |
The Wireshark trace is attached.
Can anyone help. Please? We have a big installation in the Gazprom's (Rusia)
network, where Kamailio is used as a Presence server only.
Thanks
Ales
Has anyone been successful in getting Yealink BLF's to work with
Kamailio presence
It appears that the xml format being sent is not compatible with
Yealink, butr I can't find how to change the format of the body.
Bill
Hi Team,
The SIP packets are fine ,we are able to establish SIP session ,
As long the RTP Proxy not get involved and we are not able to hear
audio,So How to do the proper configuration RTP Proxy,what to do in
RTP Proxy to get the voice for the connected sip session
Regards
Arnab
Hi Folks,
I have the strangest problem just after installing latest stable
version. I had tried both ways using the repo
(http://deb.kamailio.org/kamailio44) and downloading code with local
compile (https://www.kamailio.org/w/2016/05/kamailio-v4-4-1-released/)
The initial scenario is to get M2M with commercial IP and subsequently
use the Rx interface to do the same. We are blocked because we cannot
even achieve clean register for the UEs.
UE1(galaxy s4 zoiper) -------- Kamailio IMS aio
|
UE2(galaxy s4 zoiper) -------- |
What happens is that the first register message triggers some
quasi-endless loop in the PCSCF. Hence it cannot be forwarded to SCSCF,
ICSCF and HSS. But this doesn't always happen and between all the parse
problems there are some register messages which get passed to the scscf
icscf and hss. Somehow the parser feeds itself from the previous parse
run and thus loops quite intensively. The message I get is SIP/2.0 400
CSeq method does not match request method.
I must say that reiterating the registration process sometimes i get the
register and sometimes i don't.
Has anyone encounter similar issue for similar use case and can share
some thoughs about a fix?
I attached relevant log file, pcaps and configuration files. Let me know
if more config files are needed.
Hi all,
I just try integrate Kamailio with external software and We
want taht kamailio doesn't authenticate users. I want that the
autehtication process would be done by external software. I want To
receive a REGISTER for a user. Then I send a 407 and then when I
receive all paramters for autehtincation(nonce, response, digestURI,
etc, etc etc) send that data to external software and receive if data
is correct, then sent 200 OK and save location in external software.
Bu t I can see any pseudovariable or enything else to obtain that dato
to provide to external software. Anyone could think that this process
could be done?
Regards,
Sergio
Hi,
Upon trying to compile latest Kamailio from sources I got an:
"
nsq.h:9:24: fatal error: evbuffsock.h: No such file or directory
#include <evbuffsock.h>
^
"
Looking on the new NSQ module documentation I see the libevbuffsock
dependency. Is there other recommended way, to install the library
besides compiling from sources at [1]?
Thx,
Stefan
[1] https://github.com/mreiferson/libevbuffsock
I have a new carrier that wants sip traces of certain scenarios. They
also require IPSEC tunnelling for all SIP messages. So when I use
tcpdump or any other similar tool I can see the incoming SIP messages
but outgoing SIP messages are ESP encoded.
I've played with the siptace module but can't seem to get it to log replies.
Does anyone have any solutions?
Hi,
We have several exits from our network and all of them natted.
Could we set adv ip for rtpproxy/rtpengine from db in realtime or we must define them on daemon run time only?
--
Wbr, Serge via mobile
--
Serge via mobile
