What is the difference between the 2 in the dialog module?

Hello,
i need the kamailio 4.4.2 websocket msrp config. someone help me please ?

Hello,

For some reason, the order of records in the sip_capture table is incorrect (SIP 100 Trying recorded before the INVITE):
340396 2015-08-05 15:26:34 1438788394436624 100 [email protected]
340397 2015-08-05 15:26:34 1438788394436762 INVITE [email protected]

Could you please tell me where to look at?

Kamailio is installed from this repo:
baseurl=http://download.opensuse.org/repositories/home:/kamailio:/v4.3.x-rpms/CentOS_6/

rpm -qa|grep kama

kamailio-4.3.1-1.1.x86_64
kamailio-mysql-4.3.1-1.1.x86_64
kamailio-debuginfo-4.3.1-1.1.x86_64

Addon: I've checked with tcpdump - the packets come in correctly

It would be very helpful if I could log which of the rules actually matched.

I don't know much about LUA or Kamailio but ideas that come to my mind are:
a) Logging from inside the C module, maybe activated using a functio parameter or modparam
b) Returning not "1" but the actual rule id (careful if those can be "0" as this would probably break backwards compatibility for people using "if (!dp_translate(...))".

Hello

After termination call I am not getting OPTIONS cdrs in accounting table....
but getting in log ...

For this which changes I do in my kamailio.cfg

thanks

Hi there,

I have a weird issue with kamailio (latest docker image kamailio-ci:5.5.2-alpine) and http_async_client.

Before posting a lot of logs, let me describe what I want to achieve.

I have a Kamailio and a SIP Phone.

The SIP phone sends a REGISTER to kamailio, then in my routing block, I check if I have an Authorization header.

Since I don't have an Authorization (first message), I use "www_challenge()".
This replies to the SIP phone, and then the SIP phone sends a new REGISTER with the correct Authorization header.

So far so good.

Now, when I get the REGISTER with Authorization header, I want to ask an HTTP endpoint if this user is allowed to connect and check the password using http_async_query().

The problem is that when the transaction resumes, the tmx module is unhappy and throws this error :

30(36) CRITICAL: tmx [t_var.c:546]: pv_get_tm_reply_code(): no picked branch (-1) for a final response in MODE_ONFAILURE
And a 500 error is sent back to the sip phone.
The AUTH_REPLY route is still called and I can use the $http* values.

it seems that my AUTH_REPLY route is called but considered as a "failure_route"

19(27) exec: *** cfgtrace:dbg_cfg_trace(): failure_route=[AUTH_REPLY] c=[/etc/kamailio/kamailio.cfg] l=665 a=16 n=if
Do you see something that I am doing wrong or missing in my logic?
Is pausing/resuming to use the async http client is allowed if I'm handling a REGISTER transaction?

Here's a simplified version of my routing block (not far from reality):

request_route{
route(AUTH);

route[AUTH]{
    if (is_method("REGISTER"){
        if(no_auth_header){
            www_challenge("$td","1");
            exit;
        }
        else{
            t_newtran();
            http_async_query("http://xxx.xxx.xxx.xxx:9000/auth?foo=bar", "AUTH_REPLY");
        }
    }
}

route[AUTH_REPLY]{
    xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
}

}

Best regards!

First, a spec reference: https://tools.ietf.org/html/rfc3261#section-10.2.4

A UA SHOULD use the same Call-ID for all registrations during a single boot cycle.

On the surface is is then reasonable for Kamailio to default to contact lookup by contact and Call-ID. It does, however, default to contact only lookup.

In a repeat registration scenario like this:

~15:32:28

REGISTER sip:ben-test.callix.com.br SIP/2.0
Call-ID: [email protected]
CSeq: 2 REGISTER
From: <sip:[email protected]>;tag=61616278_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:[email protected]>
Max-Forwards: 70
Contact: <sip:[email protected]:5080>
User-Agent: Callix/Click2Call
Expires: 180
Via: SIP/2.0/UDP chandler.localdomain:5080;branch=z9hG4bK13a609f6-c985-463b-b43f-ac43090d221e_7c77d0dd_e6dd0acb-255f-4c1c-afe6-67a360a7f581
Authorization: Digest username="destination_007",realm="ben-test.callix.com.br",nonce="VcItt1XCLIsaLIdqq1Uo9wYmRIbpfQhP",uri="sip:ben-test.callix.com.br",response="0a014dd4613deb4b89fc9457d43d5cee"
Route: <sip:registrar.oneclick.callix.com.br;lr>
Content-Length: 0

SIP/2.0 200 OK
Call-ID: [email protected]
CSeq: 2 REGISTER
From: <sip:[email protected]>;tag=61616278_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:[email protected]>;tag=b27e1a1d33761e85846fc98f5f3a7e58.73ee
Via: SIP/2.0/UDP chandler.localdomain:5080;branch=z9hG4bK13a609f6-c985-463b-b43f-ac43090d221e_7c77d0dd_e6dd0acb-255f-4c1c-afe6-67a360a7f581;received=172.31.31.221
Contact: <sip:[email protected]:5080>;expires=180
Supported: outbound
Server: kamailio (4.1.6 (x86_64/linux))
Content-Length: 0

~15:34:28

REGISTER sip:ben-test.callix.com.br SIP/2.0
Call-ID: [email protected]
CSeq: 2 REGISTER
From: <sip:[email protected]>;tag=10060555_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:[email protected]>
Max-Forwards: 70
Contact: <sip:[email protected]:5080>
User-Agent: Callix/Click2Call
Expires: 180
Via: SIP/2.0/UDP chandler.localdomain:5080;branch=z9hG4bK13a609f6-c985-463b-b43f-ac43090d221e_7c77d0dd_4c667124-f13e-4bae-b637-4f19472bd417
Authorization: Digest username="destination_007",realm="ben-test.callix.com.br",nonce="VcIuMFXCLQQbB0Z4Q92WkVEu4iM2wjU3",uri="sip:ben-test.callix.com.br",response="8161b70052e50a5e3f51a843080c1eac"
Route: <sip:registrar.oneclick.callix.com.br;lr>
Content-Length: 0

SIP/2.0 200 OK
Call-ID: [email protected]
CSeq: 2 REGISTER
From: <sip:[email protected]>;tag=10060555_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:[email protected]>;tag=b27e1a1d33761e85846fc98f5f3a7e58.6229
Via: SIP/2.0/UDP chandler.localdomain:5080;branch=z9hG4bK13a609f6-c985-463b-b43f-ac43090d221e_7c77d0dd_4c667124-f13e-4bae-b637-4f19472bd417;received=172.31.31.221
Contact: <sip:[email protected]:5080>;expires=180
Supported: outbound
Server: kamailio (4.1.6 (x86_64/linux))
Content-Length: 0

I see the following queries in the Kamailio logs:

Aug  5 15:32:28 lexington /usr/sbin/kamailio[12366]: DEBUG: db_postgres [km_dbase.c:230]: db_postgres_submit_query(): sending query ok: 0x7fc5155669a0 (1) - [insert into location (username,contact,expires,q,callid,cseq,flags,cflags,user_agent,received,path,socket,methods,last_modified,ruid,instance,reg_id,domain ) values ('destination_007','sip:[email protected]:5080','2015-08-05 15:35:28',-1.00     ,'[email protected]',2,0,0,'Callix/Click2Call',NULL,NULL,'udp:172.31.26.82:5060',NULL,'2015-08-05 15:32:28','uloc-55c220c7-304e-96',NULL,0,'ben-test.callix.com.br')]

Aug  5 15:34:28 lexington /usr/sbin/kamailio[12364]: DEBUG: db_postgres [km_dbase.c:230]: db_postgres_submit_query(): sending query ok: 0x7fc5155669a0 (2) - [select contact,expires,q,callid,cseq,flags,cflags,user_agent,received,path,socket,methods,last_modified,ruid,instance,reg_id from location where username='destination_007' AND domain='ben-test.callix.com.br' order by q]

Aug  5 15:34:28 lexington /usr/sbin/kamailio[12364]: DEBUG: db_postgres [km_dbase.c:230]: db_postgres_submit_query(): sending query ok: 0x7fc5155669a0 (1) - [update location set expires='2015-08-05 15:37:28',q=-1.00     ,cseq=2,flags=0,cflags=0,user_agent='Callix/Click2Call',received=NULL,path=NULL,socket='udp:172.31.26.82:5060',methods=NULL,last_modified='2015-08-05 15:34:28',ruid='uloc-55c220c7-304e-96',instance=NULL,reg_id=0,contact='sip:[email protected]:5080' where username='destination_007' AND contact='sip:[email protected]:5080' AND callid='[email protected]' AND domain='ben-test.callix.com.br']

Evidently the contact-only nature of usrloc lookup is not being respected when a follow-up registration is attempted. This means that every pre-expiry registration for a static contact from a UA which does not comply with RFC3621's normative SHOULD will silently fail. This is not a big deal; most do comply and I could fix mine to comply.

What is a bigger deal is that if the UA is restarted, it is not to be reasonably expected to maintain the same CallID. It will use a new CallID (precisely the same way as my "faulty" UA does) on its first registration. If this occurs while there is an active registration for the same Contact, this new registration will effectively be ignored.

I think, though I'm likely to be corrected, that we should only be including the CallID in the UPDATE's WHERE clause if we used it in the SELECT and got a result. In my "faulty" UA case, this would at least leave me with duplicate registrations rather than 0 registrations. I could then follow the normative SHOULD and eliminate the duplication.

Caveat that I have only tested with usrloc's dbmode parameter as 3. I am using Postgres.

make -C modules/iptrtpproxy iptdir=/usr/download/

make: Entering directory `/usr/download/kamailio/modules/iptrtpproxy'
CC (gcc) [M iptrtpproxy.so] iptrtpproxy.o
iptrtpproxy.c:66:41: warning: linux/netfilter/xt_RTPPROXY.h: No such file or directory
iptrtpproxy.c:90: error: field ‘rpc_params’ has incomplete type
iptrtpproxy.c:92: error: field ‘handle’ has incomplete type
iptrtpproxy.c:106: error: field ‘switchboard_addr’ has incomplete type
iptrtpproxy.c:150: error: array type has incomplete element type
iptrtpproxy.c:165: error: ‘XT_RTPPROXY_MAX_ALLOC_SESSION’ undeclared here (not in a function)
iptrtpproxy.c:185: error: array type has incomplete element type
iptrtpproxy.c: In function ‘find_switchboard_by_addr’:
iptrtpproxy.c:236: error: dereferencing pointer to incomplete type
iptrtpproxy.c:236: error: dereferencing pointer to incomplete type
iptrtpproxy.c: In function ‘parse_sdp_content’:
iptrtpproxy.c:553: warning: unused variable ‘codecs’
iptrtpproxy.c: In function ‘serialize_ipt_session’:

Hello,
I am configuring kamailio MSRP relay and interconnected with a webRTC client. Which webRTC client is used, for performing the messages, sending the file, video call and screen sharing? Thank you for helping me if you have documents or link