Re: [SR-Users] Repeated 200 OK from Enswitch
Here's the full conversation. Makes me wonder whether the ACK needs to go back to the same host that handled the INVITE or whether it should be returned to the host mentioned in c=IN IP4 PROVIDERMEDIAIP in the 200 OK. 17:28:46.129459 IP 172.21.0.226.5060 PROVIDERIP.5060: SIP, length: 1123 E...,..@..5g.v..k.bINVITE sip:PHONENUMBER@PROVIDERIP SIP/2.0 Record-Route: sip:172.21.0.226;r2=on;lr=on;ftag=as2db615d2;nat=yes Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as2db615d2;nat=yes Via: SIP/2.0/UDP 172.21.0.226;branch=z9hG4bK6ff2.2194a8f3123aacc04a451656d6e2f11a.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK7384433b;rport=5080 Max-Forwards: 69 From: asterisk sip:PROVIDERUSER@PROVIDERIP:5080;tag=as2db615d2 To: sip:PHONENUMBER@PROVIDERIP Contact: sip:PROVIDERUSER@127.0.0.1:5080 Call-ID: 59e0216b4abc3a3d0c40eb2c33707ed7@PROVIDERIP CSeq: 102 INVITE User-Agent: Elastix 3.0 Date: Tue, 12 May 2015 07:28:46 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 301 P-hint: outbound v=0 o=root 2142344521 2142344521 IN IP4 172.21.0.226 s=Asterisk PBX 11.13.0 c=IN IP4 172.21.0.226 t=0 0 m=audio 19840 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv a=nortpproxy:yes 17:28:46.170220 IP PROVIDERIP.5060 172.21.0.226.5060: SIP, length: 566 E..R.0..?..^g.v...3SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 172.21.0.226;branch=z9hG4bK6ff2.2194a8f3123aacc04a451656d6e2f11a.0;rport=5060 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK7384433b;rport=5080 From: asterisk sip:PROVIDERUSER@PROVIDERIP:5080;tag=as2db615d2 To: sip:PHONENUMBER@PROVIDERIP;tag=815f2ea990888c6d5eab0fa409f04ec4.44f3 Call-ID: 59e0216b4abc3a3d0c40eb2c33707ed7@PROVIDERIP CSeq: 102 INVITE Proxy-Authenticate: Digest realm=PROVIDERIP, nonce=VVGs2VVRq620ayXnC7qlie1+Jfz14FtN Server: Enswitch SIP proxy Content-Length: 0 17:28:46.170606 IP 172.21.0.226.5060 PROVIDERIP.5060: SIP, length: 382 E...-..@...g.v...g.ACK sip:PHONENUMBER@PROVIDERIP SIP/2.0 Via: SIP/2.0/UDP 172.21.0.226;branch=z9hG4bK6ff2.2194a8f3123aacc04a451656d6e2f11a.0 Max-Forwards: 69 From: asterisk sip:PROVIDERUSER@PROVIDERIP:5080;tag=as2db615d2 To: sip:PHONENUMBER@PROVIDERIP;tag=815f2ea990888c6d5eab0fa409f04ec4.44f3 Call-ID: 59e0216b4abc3a3d0c40eb2c33707ed7@PROVIDERIP CSeq: 102 ACK Content-Length: 0 17:28:46.176460 IP 172.21.0.226.5060 PROVIDERIP.5060: SIP, length: 1332 E..P...@..bg.v...IINVITE sip:PHONENUMBER@PROVIDERIP SIP/2.0 Record-Route: sip:172.21.0.226;r2=on;lr=on;ftag=as2db615d2;nat=yes Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as2db615d2;nat=yes Via: SIP/2.0/UDP 172.21.0.226;branch=z9hG4bK7ff2.815a4eaaa71a2b504d0e053b565d5085.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK21ff4fac;rport=5080 Max-Forwards: 69 From: asterisk sip:PROVIDERUSER@PROVIDERIP:5080;tag=as2db615d2 To: sip:PHONENUMBER@PROVIDERIP Contact: sip:PROVIDERUSER@127.0.0.1:5080 Call-ID: 59e0216b4abc3a3d0c40eb2c33707ed7@PROVIDERIP CSeq: 103 INVITE User-Agent: Elastix 3.0 Proxy-Authorization: Digest username=PROVIDERUSER, realm=PROVIDERIP, algorithm=MD5, uri=sip:PHONENUMBER@PROVIDERIP, nonce=VVGs2VVRq620ayXnC7qlie1+Jfz14FtN, response=75ea690ebdd7bfa9eabf0e9f2c298bcc Date: Tue, 12 May 2015 07:28:46 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 301 P-hint: outbound v=0 o=root 2142344521 2142344522 IN IP4 172.21.0.226 s=Asterisk PBX 11.13.0 c=IN IP4 172.21.0.226 t=0 0 m=audio 19840 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv a=nortpproxy:yes 17:28:46.219802 IP PROVIDERIP.5060 172.21.0.226.5060: SIP, length: 441 E1..?...g.v.SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 172.21.0.226;branch=z9hG4bK7ff2.815a4eaaa71a2b504d0e053b565d5085.0;rport=5060 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK21ff4fac;rport=5080 From: asterisk sip:PROVIDERUSER@PROVIDERIP:5080;tag=as2db615d2 To: sip:PHONENUMBER@PROVIDERIP Call-ID: 59e0216b4abc3a3d0c40eb2c33707ed7@PROVIDERIP CSeq: 103 INVITE Server: Enswitch SIP proxy Content-Length: 0 17:28:52.359718 IP PROVIDERIP.5060 172.21.0.226.5060: SIP, length: 1070 E..J.2..?. dg.v..6b.SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 172.21.0.226;rport=5060;branch=z9hG4bK7ff2.815a4eaaa71a2b504d0e053b565d5085.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK21ff4fac;rport=5080 Record-Route: sip:PROVIDERIP;lr=on Record-Route: sip:172.21.0.226;r2=on;lr=on;ftag=as2db615d2;nat=yes Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as2db615d2;nat=yes From: asterisk sip:PROVIDERUSER@PROVIDERIP:5080;tag=as2db615d2 To: sip:PHONENUMBER@PROVIDERIP;tag=as59947d90 Call-ID:
Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT
For sake of clarification, the r-uri is not related to the username for
authentication nor to To header uri. They can be completely different.
However, trunk provider might have various requirements in formatting
the r-uri and To uri, they usually say that in the interconnect docs.
Cheers,
Daniel
On 12/05/15 03:11, Darren Campbell (Primar) wrote:
Thanks for this, I suppose this means the initial INVITE from Asterisk
should be adjusted.
Trying a custom trunk so the INVITE r-uri from Asterisk has the
provider username but the To header has the number to dial.
SIP/PROVIDERPEER/providerusername!$OUTNUM$
Until today I didn't understand how Asterisk was able to manage r-uri
and To header separately.
But I stumbled upon zmonkey whilst searching for asterisk r-uri.
https://www.zmonkey.org/blog/content/asterisk-sip-request-uri-vs-header
Regards,
Darren
*From:* Daniel-Constantin Mierla [mico...@gmail.com]
*Sent:* Monday, 11 May 2015 8:47 PM
*To:* Darren Campbell (Primar); Kamailio (SER) - Users Mailing List
*Subject:* Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT
What is happening then, is the provider sending back another 407?
Normally the Proxy-Authorization header should stay unchanged, but if
you change the request uri, it may result in mismatch.
Cheers,
Daniel
On 11/05/15 10:26, Darren Campbell (Primar) wrote:
Thanks, much appreciated.
I'm seeing the Proxy-Authorization from Asterisk in tcpdump. It seems
like I've been working against what's already built into Kamailio.
Probably need to tweak some uri's though.
When dialing out, the r-uri is:
sip:mobilenumberhere@exampleip
But the uri part of the Proxy-Authorization in the new INVITE ends up
with uri=sip:mobilenumberhere@exampleip
However, I think it should be showing
uri=sip:providerusernamehere@exampleip
Regards,
Darren
*From:* sr-users [sr-users-boun...@lists.sip-router.org] on behalf of
Daniel-Constantin Mierla [mico...@gmail.com]
*Sent:* Monday, 11 May 2015 6:07 PM
*To:* Kamailio (SER) - Users Mailing List
*Subject:* Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT
Hello,
On 11/05/15 08:41, Darren Campbell (Primar) wrote:
Hi all
Have Asterisk listening on 127.0.0.1 and aiming to route all
inbound/outbound SIP via Kamailio listening on 127.0.0.1 and
external interface.
Inbound calls from the SIP PROVIDER work just fine. Have NAT,
rtpproxy configured for successful registration and subsequent
INVITEs etc.
Experiencing some challenges with the outgoing INVITES, primarily
authenticating the outbound INVITEs.
The current situation is this:
Asterisk INVITE Kamailio INVITE SIP PROVIDER
SIP PROVIDER 407 Proxy Authenticate Kamailio Transaction
Cancelled.
Asterisk then plays number unavailable message.
The desired situation is more like this:
Asterisk INVITE Kamailio INVITE SIP PROVIDER
SIP PROVIDER 407 Proxy Authenticate Kamailio Asterisk
Asterisk INVITE (with auth digest etc) Kamailio INVITE SIP
PROVIDER
An attempted solution was made by having Kamailio authenticate using
the uac module. However, ideally Kamailio should be mostly
transparent and Asterisk should be handling and responding to the
407 Proxy Authentication.
If there is someone in the Kamailio community that has addressed
this situation before, guidance would be much appreciated.
do you have a failure_route block in kamailio.cfg? Be sure that if
401/407 is received, you just exit the routing block:
failure_route[abc] {
...
if(t_check_status(401|407)) exit;
...
}
Then the 401/407 replies will be sent upstream to asterisk.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Keep-Alive in dialog freeing a free fragment
Hi Daniel, This fixes the problem, thanks very much, Will this fix be included in the next (4.2 and/or 4.3) stable release? Cheers, Dirk Teurlings On 11-05-15 17:25, Daniel-Constantin Mierla wrote: Following quickly up, I pushed another patch that will remove the dialog from keepalive list as soon as 'deleted' state is discovered and also sends keepalive options only if dialog is in state 'confirmed'. Can you test the patch and see how it works? - https://github.com/kamailio/kamailio/commit/0e22abe2b89be8936df4b8230955fbaf43ad40e7 Cheers, Daniel On 11/05/15 16:55, Daniel-Constantin Mierla wrote: Hello, the message freeing a free fragment ... is from Dialog KA Timer and that process doesn't handle any SIP reply or the transmission timeout callback. I will look at the code and see if I can spot where the double free happens. But now I understand that the dialog is actually not ended, right? Cheers, Daniel On 07/05/15 17:05, Dirk Teurlings - SIGNET B.V. wrote: Hi Daniel, Good to see you found an improvement, not sure yet if it'll help us. Here is the non-debug log first. Just now I noticed that the initial dialog doesn't get ended as well now, 5fa4dc3670596fb626269f083b0c9480 in the log. The setup is like this Leg 1 Kamailio - Asterisk Leg 2 (initialized by Asterisk) - Kamailio - Gateway First the output of ps Process:: ID=0 PID=21528 Type=attendant Process:: ID=1 PID=21530 Type=udp receiver child=0 sock=127.0.0.1:5060 Process:: ID=2 PID=21531 Type=udp receiver child=0 sock=192.168.10.246:5060 Process:: ID=3 PID=21532 Type=udp receiver child=0 sock=31.223.168.246:5060 Process:: ID=4 PID=21533 Type=udp receiver child=0 sock=[::1]:5060 Process:: ID=5 PID=21534 Type=udp receiver child=0 sock=[2001:4cb8:34a:10::246]:5060 Process:: ID=6 PID=21535 Type=slow timer Process:: ID=7 PID=21536 Type=timer Process:: ID=8 PID=21537 Type=MI FIFO Process:: ID=9 PID=21538 Type=ctl handler Process:: ID=10 PID=21539 Type=TIMER NH Process:: ID=11 PID=21540 Type=Dialog KA Timer Process:: ID=12 PID=21541 Type=Dialog Clean Timer Process:: ID=13 PID=21542 Type=WLCC TB TIMER Process:: ID=14 PID=21543 Type=LLCC TB TIMER Process:: ID=15 PID=21544 Type=tcp receiver (generic) child=0 Process:: ID=16 PID=21545 Type=tcp main process And the log May 7 18:54:43 vps-host /usr/sbin/kamailio[21532]: INFO: script: 5fa4dc3670596fb626269f083b0c9480@192.168.10.245:5060 - CC, dialog:start May 7 18:54:44 vps-host /usr/sbin/kamailio[21531]: INFO: script: 4d263e35-89ea921c@172.16.0.205 - CC, dialog:start May 7 18:55:57 vps-host /usr/sbin/kamailio[21535]: INFO: script: 123 - CC, dialog:end May 7 18:55:57 vps-host /usr/sbin/kamailio[21535]: INFO: script: 123 - WLCC: ENDCALL May 7 18:55:57 vps-host /usr/sbin/kamailio[21531]: WARNING: dialog [dlg_req_within.c:212]: bye_reply_cb(): inconsitent dlg timer data on dlg 0x7fa76e546600 [869:4705] with clid '5fa4dc3670596fb626269f083b0c9480@192.168.10.245:5060' and tags 'as155a87b8' '95b0a07565f99244i0' May 7 18:55:57 vps-host /usr/sbin/kamailio[21531]: INFO: script: 4d263e35-89ea921c@172.16.0.205 - CC, dialog:end May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a
Re: [SR-Users] Ims_charging lose all charging information when restart
Hi Yasin, The functionality of reviving Ro sessions on reboot is not yet 100% complete. As you correctly noted, the groundwork is there w.r.t data being stored in DB but I still need to rebuild the CDP sessions and restart the structures, state and timing for the Ro sessions. It's something on my todo list. Your next question will probably be ETA... ;) - Ideally I'd like to have this implemented before the end of this month. Cheers Jason On Tue, May 12, 2015 at 10:03 AM, Yasin CANER yasin.ca...@netgsm.com.tr wrote: Hello; as you know , S-CSCSF has IMS_charging module and dialog_ng module for charging. When it is restarted , all dialog_ng hash is vanish. So calls can continue but* charging stops*. if dialog_ng has a db_mode when restart , it can be solved. or is there a way to solve this problem? Thanks. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- *Jason Penton**Senior Manager: Applications and Services**Smile Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:* jason.barry.pentonjason.pen...@smilecoms.com name.surn...@smilecoms.com www.smilecoms.com -- This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ http://www.smilecoms.com/disclaimer ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT
The provider side is sending the BYE. Also it's not that it is a second call affecting anything, the call ends unexpectedly after 30 seconds. To me it looks like provider keeps sending 200 OK and Asterisk keeps sending ACK until provider timeout and sends BYE. This initial issue with the 407 has been dealt with I think so I've posted a new thread with subject Repeated 200 OK from Enswitch. Want to maximise the correctness of configuration this end before reaching out to the provider for assistance. Much appreciated, I was really over-thinking the Kamailio configuration required. There was no easy way that I knew of to see exactly what Asterisk was using for a password via logging etc. It wasn't until I tried to recreate the Digest for myself was I able to detect Asterisk was sending a blank password. From there, I was able to trace back to Elastix MT how it was treating secret, sippasswd and remotesecret fields when dealing with the sip table in the elxpbx table in mysqld. From: Daniel-Constantin Mierla [mico...@gmail.com] Sent: Tuesday, 12 May 2015 5:27 PM To: Darren Campbell (Primar); Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT What do you mean it drops out? What side is sending the BYE? Cheers, Daniel On 12/05/15 05:14, Darren Campbell (Primar) wrote: Had a closer look at the Digest being sent. Attempted to recreate Digest based on the username, realm, password, method uri I was expecting versus the one created in the invite. Looks like Asterisk was using a blank password. Proxy-Authorization: Digest username=provideruser, realm=providerip, algorithm=MD5, uri=sip:provideruser@provideripsip:provideruser@providerip, nonce=nonceexample, response=exampleresponse php -r 'echo md5(md5(provideruser:providerip:password).:nonceexample:.md5(INVITE:sip:provideruser@providerip));' someotherresponse php -r 'echo md5(md5(provideruser:providerip:).:nonceexample:.md5(INVITE:sip:provideruser@providerip));' exampleresponse Here's the two lines in chan_sip.c (http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c) that could have set the secret: secret = auth-secret; secret = p-relatedpeer !ast_strlen_zero(p-relatedpeer-remotesecret) ? p-relatedpeer-remotesecret : p-peersecret; When I checked Elastix MT code, it wasn't setting the secret for Asterisk Realtime because this is handled by Kamailio for extensions. But I noted that remotesecret could be used for peers. Ended up altering Elastix Mt trunk interface to allow entering remotesecret field via /usr/share/elastix/apps/trunks/index.php Now a single outbound call is able to connect, however, it drops out when a second outbound call is made. From: Daniel-Constantin Mierla [mico...@gmail.commailto:mico...@gmail.com] Sent: Monday, 11 May 2015 8:47 PM To: Darren Campbell (Primar); Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT What is happening then, is the provider sending back another 407? Normally the Proxy-Authorization header should stay unchanged, but if you change the request uri, it may result in mismatch. Cheers, Daniel On 11/05/15 10:26, Darren Campbell (Primar) wrote: Thanks, much appreciated. I'm seeing the Proxy-Authorization from Asterisk in tcpdump. It seems like I've been working against what's already built into Kamailio. Probably need to tweak some uri's though. When dialing out, the r-uri is: sip:mobilenumberhere@exampleip But the uri part of the Proxy-Authorization in the new INVITE ends up with uri=sip:mobilenumberhere@exampleipsip:mobilenumberhere@exampleip However, I think it should be showing uri=sip:providerusernamehere@exampleipsip:providerusernamehere@exampleip Regards, Darren From: sr-users [sr-users-boun...@lists.sip-router.orgmailto:sr-users-boun...@lists.sip-router.org] on behalf of Daniel-Constantin Mierla [mico...@gmail.commailto:mico...@gmail.com] Sent: Monday, 11 May 2015 6:07 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT Hello, On 11/05/15 08:41, Darren Campbell (Primar) wrote: Hi all Have Asterisk listening on 127.0.0.1 and aiming to route all inbound/outbound SIP via Kamailio listening on 127.0.0.1 and external interface. Inbound calls from the SIP PROVIDER work just fine. Have NAT, rtpproxy configured for successful registration and subsequent INVITEs etc. Experiencing some challenges with the outgoing INVITES, primarily authenticating the outbound INVITEs. The current situation is this: Asterisk INVITE Kamailio INVITE SIP PROVIDER SIP PROVIDER 407 Proxy Authenticate Kamailio Transaction Cancelled. Asterisk then plays number unavailable message. The desired situation is more like this: Asterisk INVITE Kamailio INVITE SIP
[SR-Users] Ims_charging lose all charging information when restart
Hello; as you know , S-CSCSF has IMS_charging module and dialog_ng module for charging. When it is restarted , all dialog_ng hash is vanish. So calls can continue but charging stops. if dialog_ng has a db_mode when restart , it can be solved. or is there a way to solve this problem? Thanks. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT
What do you mean it drops out? What side is sending the BYE?
Cheers,
Daniel
On 12/05/15 05:14, Darren Campbell (Primar) wrote:
Had a closer look at the Digest being sent.
Attempted to recreate Digest based on the username, realm, password,
method uri I was expecting versus the one created in the invite.
Looks like Asterisk was using a blank password.
Proxy-Authorization: Digest username=provideruser,
realm=providerip, algorithm=MD5, uri=sip:provideruser@providerip,
nonce=nonceexample, response=exampleresponse
php -r 'echo
md5(md5(provideruser:providerip:password).:nonceexample:.md5(INVITE:sip:provideruser@providerip));'
someotherresponse
php -r 'echo
md5(md5(provideruser:providerip:).:nonceexample:.md5(INVITE:sip:provideruser@providerip));'
exampleresponse
Here's the two lines in chan_sip.c
(http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c)
that could have set the secret:
secret = auth-secret;
secret = p-relatedpeer
!ast_strlen_zero(p-relatedpeer-remotesecret)
? p-relatedpeer-remotesecret : p-peersecret;
When I checked Elastix MT code, it wasn't setting the secret for
Asterisk Realtime because this is handled by Kamailio for extensions.
But I noted that remotesecret could be used for peers.
Ended up altering Elastix Mt trunk interface to allow entering
remotesecret field via /usr/share/elastix/apps/trunks/index.php
Now a single outbound call is able to connect, however, it drops out
when a second outbound call is made.
*From:* Daniel-Constantin Mierla [mico...@gmail.com]
*Sent:* Monday, 11 May 2015 8:47 PM
*To:* Darren Campbell (Primar); Kamailio (SER) - Users Mailing List
*Subject:* Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT
What is happening then, is the provider sending back another 407?
Normally the Proxy-Authorization header should stay unchanged, but if
you change the request uri, it may result in mismatch.
Cheers,
Daniel
On 11/05/15 10:26, Darren Campbell (Primar) wrote:
Thanks, much appreciated.
I'm seeing the Proxy-Authorization from Asterisk in tcpdump. It seems
like I've been working against what's already built into Kamailio.
Probably need to tweak some uri's though.
When dialing out, the r-uri is:
sip:mobilenumberhere@exampleip
But the uri part of the Proxy-Authorization in the new INVITE ends up
with uri=sip:mobilenumberhere@exampleip
However, I think it should be showing
uri=sip:providerusernamehere@exampleip
Regards,
Darren
*From:* sr-users [sr-users-boun...@lists.sip-router.org] on behalf of
Daniel-Constantin Mierla [mico...@gmail.com]
*Sent:* Monday, 11 May 2015 6:07 PM
*To:* Kamailio (SER) - Users Mailing List
*Subject:* Re: [SR-Users] Handling 407 Proxy Authentication, Elastix MT
Hello,
On 11/05/15 08:41, Darren Campbell (Primar) wrote:
Hi all
Have Asterisk listening on 127.0.0.1 and aiming to route all
inbound/outbound SIP via Kamailio listening on 127.0.0.1 and
external interface.
Inbound calls from the SIP PROVIDER work just fine. Have NAT,
rtpproxy configured for successful registration and subsequent
INVITEs etc.
Experiencing some challenges with the outgoing INVITES, primarily
authenticating the outbound INVITEs.
The current situation is this:
Asterisk INVITE Kamailio INVITE SIP PROVIDER
SIP PROVIDER 407 Proxy Authenticate Kamailio Transaction
Cancelled.
Asterisk then plays number unavailable message.
The desired situation is more like this:
Asterisk INVITE Kamailio INVITE SIP PROVIDER
SIP PROVIDER 407 Proxy Authenticate Kamailio Asterisk
Asterisk INVITE (with auth digest etc) Kamailio INVITE SIP
PROVIDER
An attempted solution was made by having Kamailio authenticate using
the uac module. However, ideally Kamailio should be mostly
transparent and Asterisk should be handling and responding to the
407 Proxy Authentication.
If there is someone in the Kamailio community that has addressed
this situation before, guidance would be much appreciated.
do you have a failure_route block in kamailio.cfg? Be sure that if
401/407 is received, you just exit the routing block:
failure_route[abc] {
...
if(t_check_status(401|407)) exit;
...
}
Then the 401/407 replies will be sent upstream to asterisk.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Re: [SR-Users] Repeated 200 OK from Enswitch
Hello, can you show both received 200ok + ACK as well as those sent out? It is important to see how Record-/Route, Contact and r-uri change on the way to spot where the issue is. Cheers, Daniel On 12/05/15 05:56, Darren Campbell (Primar) wrote: Hi all Experiencing a commonly reported issue where calls drop out after 30 seconds or so. Mainly because the provider hangs up after not recognising/receiving ACK in response to 200 OK. Unfortunately (or maybe fortunately), I haven't had much experience with Enswitch so was hoping someone in the community might help guide me as to which rules Enswitch might be using to match ACKs to calls in progress. Maybe there is another avenue I should be investigating. Here's a sample of the 200 OK and ACK that repeats. 13:44:04.155646 IP PROVIDERIP.5060 172.21.0.226.5060: SIP, length: 1058 E...M..?..Ug.v..*J.SIP/2.0 200 OK^M Via: SIP/2.0/UDP 172.21.0.226;rport=5060;branch=z9hG4bKfe94.efbf7fbcaf8bd15243a61fdc9d6d1e78.0^M Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK65f00a0c;rport=5080^M Record-Route: sip:PROVIDERIP;lr=on^M Record-Route: sip:172.21.0.226;r2=on;lr=on;ftag=as65919d92;nat=yes^M Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as65919d92;nat=yes^M From: asterisk sip:PROVIDERUSER@PROVIDERIP:5080;tag=as65919d92^M To: sip:PHONENUMBER@PROVIDERIP;tag=as260fefaa^M Call-ID: 271ac7a174d613cd0b94504353733a2c@PROVIDERIP^M CSeq: 103 INVITE^M Server: Enswitch^M Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH^M Supported: replaces^M Contact: sip:PHONENUMBER@PROVIDERMEDIAIP:5060^M Content-Type: application/sdp^M Content-Length: 286^M ^M v=0^M o=root 2110894460 2110894461 IN IP4 PROVIDERMEDIAIP^M s=Asterisk PBX 11.3.0^M c=IN IP4 PROVIDERMEDIAIP^M t=0 0^M m=audio 15594 RTP/AVP 0 8 3 101^M a=rtpmap:0 PCMU/8000^M a=rtpmap:8 PCMA/8000^M a=rtpmap:3 GSM/8000^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-16^M a=ptime:20^M a=sendrecv^M 13:44:04.164519 IP 172.21.0.226.5060 PROVIDERIP.5060: SIP, length: 525 E..)!a...@..vg.v...t.ack sip:PHONENUMBER@PROVIDERIP:5060 SIP/2.0^M Via: SIP/2.0/UDP 172.21.0.226;branch=z9hG4bKfe94.472e9fc0479de79b4f176cc9585d8880.0^M Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK752b5264;rport=5080^M Route: sip:PROVIDERIP;lr=on^M Max-Forwards: 69^M From: asterisk sip:PROVIDERUSER@PROVIDERIP:5080;tag=as65919d92^M To: sip:PHONENUMBER@PROVIDERIP;tag=as260fefaa^M Contact: sip:PROVIDERUSER@127.0.0.1:5080^M Call-ID: 271ac7a174d613cd0b94504353733a2c@PROVIDERIP^M CSeq: 103 ACK^M User-Agent: Elastix 3.0^M Content-Length: 0^M ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio crash periodically in timer handler
Hi Daniel, if the patch works fine, i can push it to the main repository. But in current state, until it is not stable, i would not do it. So that you asked: the interesting thing that this patch works fine on Debian squeeze properly as expected, but on Ubuntu trusty, the NOTIFYs cannot reach the clients. The code runs, it can be seen in the logs, but the NOTIFYs cannot be delivered. And maybe, it is only a suspicion, it can be the cause of the memory crash after some time. In debian, there are no crashes, but in Ubuntu there are many. It seems the solution does not belong to the async patch, i tested it with kamailio 4.2.4 now, the results are the same. How can I continue the debugging to solve the problem? What information do you also need? Peter From: Daniel-Constantin Mierla [mailto:mico...@gmail.com] Sent: Tuesday, May 12, 2015 2:45 PM To: Péter Barabás; Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] kamailio crash periodically in timer handler Hi Peter, good you mentioned the the patch, overlooked it -- is it something that you want to be pushed on main repository or some customization good for your needs? Somehow I didn't understand properly if you think that is the cause of the issue or is the solution. If you want to be pushed to the master repository, can you make a pull request on github project: - https://github.com/kamailio/kamailio It makes it easier to review, comment if needed, and merge when all is ok. On the other hand, if you were using t_suspend()/t_continue(), I pushed a patch that should avoid some race when removing suspended transaction from timer. Now, for the new issue, do I understand correctly that is when running on ubuntu? And it is not visible on Debian, where everything works as expected? What are the versions for ubuntu and debian you are using? Cheers, Daniel On 12/05/15 13:05, Péter Barabás wrote: Dear Daniel, community, A few days ago I have already uploaded the diff that probably causes a rare crash with kamailio, but as I mentioned, we have another issue as well. Our clients are registered via TLS to kamailio, and we want to change their presence ( to offline) when the TLS connection is disconnected. TLS disconnection is detected properly, location record is removed – but presence is not updated properly on Ubuntu…. It works perfectly with Kamailio 4.2.4 on debian, but does not work on 4.2.4 on Ubuntu trusty. The configuration is the same, network environment is the same. Kamailio is built from source, with a few modifications in ul_publish.c (diff was sent a few weeks ago). We want is that if a tcp socket has broken, the contact’s of the user gets a NOTIFY with closed state. It seems it is generated but the clients do not receive this. Here are some log parts about the NOTIFY: (ERROR logs are DEBUG logs, only for easier separation) - May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:341]: ul_publish(): #012EXPIRE type May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:350]: ul_publish(): Building pidf... May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:163]: build_pidf(): PUBLISH: found expired #012 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:166]: build_pidf(): Setting open to 0 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:110]: pua_set_publish(): Device: device May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:112]: pua_set_publish(): State: closed May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:114]: pua_set_publish(): Content: lt;statusgt;lt;stategt;offlinelt;/stategt;lt;messagegt;normallt;/messagegt;lt;/statusgt; May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:285]: build_pidf(): new_body:#012?xml version=1.0?#012presence xmlns=urn:ietf:params:xml:ns:pidf xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid xmlns:c=urn:ietf:params:xml:ns:pidf:cipid entity=sip:1821043...@xxx.comsip:1821043...@xxx.com#012 tuple id=closed#012status#012 basicclose/basic#012/status#012 notelt;statusgt;lt;stategt;offlinelt;/stategt;lt;messagegt;normallt;/messagegt;lt;/statusgt;/note#012 /tuple#012/presence#012 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:380]: ul_publish(): uri= sip:1821043...@xxx.com May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:136]: print_publ(): publ: May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:137]: print_publ(): uri= sip:1821043...@xxx.com May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:138]: print_publ(): id=
Re: [SR-Users] Multi-homed Kamailio Modifies ACK
Yeah sure, attached here is the trace from the CISCO logs. Not in pcap format. Also this is the flow of the call. +---+ +--+ +--+ |Provider |+ +Kamailio +--+CISCO IAD | +---+ +--+ +-+ | ^ v | +---+ |Asterisk | +---+ Thanks and best Regards, -- On Tue, May 12, 2015 at 11:50 AM, Alex Balashov abalas...@evaristesys.com wrote: Is the UAC in this case a 2543 endpoint by chance? Can you send a complete SIP trace of the entire setup? -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry. *From: *SamyGo *Sent: *Tuesday, May 12, 2015 11:46 *To: *SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List *Reply To: *Kamailio (SER) - Users Mailing List *Subject: *[SR-Users] Multi-homed Kamailio Modifies ACK Hi all, I'm having a scenario where I'm sending call to CISCO IAD2431. The call establishes with 200OK from CISCO and Kamailio sends back modified ACK. Cisco at this points gives out an error and sends 200OK again, Kamailio replies with ACK, and this cycle goes on until the call drops. Here is the error from CISCO: Failed FROM/TO Request check old_from: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc old_to: sip:+1812...@sip.iamip.com:5041;tag=9FEC572E-100F new_from: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc new_to: sip:+1812211@192.168.1.244:5041;tag=9FE I've #auto_aliases=no and, listen=udp:44.33.22.11:5041 listen=udp:192.168.1.244:5041 Kamailio sends INVITE through the Public IP to the CISCO gw, but decides to change the ACK header. Any advise please. Best Regards, Sammy. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.05.11 15:38:15 =~=~=~=~=~=~=~=~=~=~=~= CISCO-GW# CISCO-GW# CISCO-GW#t show log 006271: *May 12 04:26:06.939: Received: INVITE sip:+1812211@99.110.111.112:5060 SIP/2.0 Record-Route: sip:44.33.22.11:5041;r2=on;lr=on;ftag=as370915fc;did=e28.f8c1;nat=yes Record-Route: sip:192.168.1.244:5041;r2=on;lr=on;ftag=as370915fc;did=e28.f8c1;nat=yes Via: SIP/2.0/UDP 44.33.22.11:5041;branch=z9hG4bKff67.ddb600ce64f62e3d27a4570903cfd827.0 Via: SIP/2.0/UDP 192.168.1.106:5060;branch=z9hG4bK2d047b8c;rport=5060 Max-Forwards: 69 From: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc To: sip:+1812...@sip.iamip.com:5041 Contact: sip:+14432232221@192.168.1.106:5060 Call-ID: 29d42683248faec624fb0ce94e04ebf9@192.168.1.106:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.13.1 Date: Mon, 11 May 2015 19:39:18 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer P-TRUNKPORT: 5060 P-TRUNKIP: 99.110.111.112 P-UDOMAIN: sip.iamip.com Content-Type: application/sdp Content-Length: 301 v=0 o=root 1791803783 1791803783 IN IP4 44.33.22.12 s=Asterisk PBX 11.13.1 c=IN IP4 44.33.22.12 t=0 0 m=audio 51590 RTP/AVP 8 3 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv a=nortpproxy:yes 006329: *May 12 04:26:06.995: Sent: SIP/2.0 100 Trying Via: SIP/2.0/UDP 44.33.22.11:5041;branch=z9hG4bKff67.ddb600ce64f62e3d27a4570903cfd827.0,SIP/2.0/UDP 192.168.1.106:5060;branch=z9hG4bK2d047b8c;rport=5060 From: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc To: sip:+1812...@sip.iamip.com:5041;tag=9FEC572E-100F Date: Sat, 28 Aug 1993 04:26:06 GMT Call-ID: 29d42683248faec624fb0ce94e04ebf9@192.168.1.106:5060 Server: Cisco-SIPGateway/IOS-12.x CSeq: 102 INVITE Allow-Events: telephone-event Content-Length: 0 006380: *May 12 04:26:07.027: Sent: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 44.33.22.11:5041;branch=z9hG4bKff67.ddb600ce64f62e3d27a4570903cfd827.0,SIP/2.0/UDP 192.168.1.106:5060;branch=z9hG4bK2d047b8c;rport=5060 From: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc To: sip:+1812...@sip.iamip.com:5041;tag=9FEC572E-100F Date: Sat, 28 Aug 1993 04:26:06 GMT Call-ID: 29d42683248faec624fb0ce94e04ebf9@192.168.1.106:5060 Server: Cisco-SIPGateway/IOS-12.x CSeq: 102 INVITE Allow-Events: telephone-event Contact: sip:+1812211@99.110.111.112:5060 Record-Route: sip:44.33.22.11:5041;r2=on;lr=on;ftag=as370915fc;did=e28.f8c1;nat=yes,sip:192.168.1.244:5041;r2=on;lr=on;ftag=as370915fc;did=e28.f8c1;nat=yes Content-Disposition: session;handling=required Content-Type: application/sdp Content-Length: 250 v=0
Re: [SR-Users] how to delete key from htable?
Hello, On 12/05/15 16:32, Juha Heinanen wrote: there exists rpc command htable.delete that can be used to delete a key from htable. is there a way to delete a key in the config file like assigning $null to it or do i need to use sht_rm_name_re function that feels like an overkill? assigning $null to $sht(...) will remove the item from hash table. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio slow/no response for requests on particular ports
Daniel, A question regarding when I should run your suggested gdb commands. Do I run them at anytime after we see the issue on a particular port or would you like me to run them at a particular instance/event after the issue occurs (for example, make a test call and immediately run the command; or maybe run the command after the test call completes; or at some other time/event.) Karthik On Mon, May 11, 2015 at 2:43 PM, Karthik Srinivasan ksriniva2...@gmail.com wrote: Our operating system is RHEL 5.9 and selinux is disabled. We had already added an xlog message at the top of the request; and the result showed that the message was being received by kamailio during the problematic-port issue. I will run your suggested commands when the problem recurs. Much appreciated regarding your help. Thanks, Karthik On Mon, May 11, 2015 at 1:47 PM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, what is your operating system? Do you have selinux enabled? Can you add an xlog() message at the top of request_route block and see if the message is printed in syslog when you see the packet coming on the network? This ensures that kamailio is receiving it. If you are familiar with gdb, when one port is not responding, do: kamctl ps See the pid of the processes listening on that port. Select one and do: gdb /path/to/kamailio PID bt full That will show what that process is doing at that moment. Send the output here. Cheers, Daniel On 11/05/15 20:34, Karthik Srinivasan wrote: Hi Daniel, Thanks for the response. We are not using the pike module. The requests to a port are not dismissed; rather, in most cases, there is a delay in response from kamailio. Also, the delay is not restricted to any particular message request. it happens for any type of request. (register; subscribe; etc...). But those same requests, if pointed to different port, have no issues. Also, to note, I am not restarting kamailio when the issue occurs on a particular port. kamailio is kept running and pointing traffic to a non-problematic port seems fine. Karthik On Mon, May 11, 2015 at 12:41 PM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, do you have pike module loaded and enabled? Are all requests to a port dismissed or just some of them? Cheers, Daniel On 11/05/15 19:20, Karthik Srinivasan wrote: Hi, I have encountered an issue with kamailio and am hoping someone on this email distro can help: Here's my setup and description of the issue: I am running kamailio version 3.1.4. I have the kamailio process bound to ports 5060, 5070, and 5090. all UDP. I have several client devices registering to the kamailio registrar. The issue I have encountered is this: SIP registrations to port 5070 are fine for a period of time; by fine I mean clients send SIP registration requests to kamailio; and kamailio responds promptly to the request. by period of time I mean (this could be somewhat random) that for10 hours; 12 hours; 1 hour; that kamailo has no issue processing requests. after this random time period has elapsed, kamailo isn't able to respond to sip registrations and other messages in timely manner; to the point where the clients timeout and have to resend their registration requests. at times, kamailio does respond to the requests (with a significant delay) and at other times no response is received by the client. the user experience is intermittent registration delays/failures. The same behavior is seen on port 5090. I have not encountered the issue yet on port 5060. During times when kamailio isn't able to respond timely to requests on a particular port, requests to other ports are responded to timely. for ex: if port 5070 encounters the issue; port 5060 and 5090 seem fine. meaning, I can point my client devices to 5060 or 5090 and kamailio processes the requests timely. I have studied a tcp dump on the server end (kamailio side) and noticed that the network layer shows the messages from the client to be received timely while kamailio is encountering this issue. which indicates to me that it probably isn't a network lag related issue. Something at the application layer is probably causing kamailio to not respond timely. Furthermore the issue resolves itself after a period of time; that is, kamailio begins to respond to messages timely on the problematic port. I haven't had a chance yet to determine exactly how long it takes to recover. it certainly takes some time though. at least 30 minutes; maybe more. I can also state that the load on the kamailio system is minimal. far below than what the performance metrics state it can handle. Has anyone encountered this issue where kamalio isn't responding to registration and other requests timely on a particular port but does so fine for other ports? Any help on this would be appreciated. Thanks,
Re: [SR-Users] how to delete key from htable?
Daniel-Constantin Mierla writes: there exists rpc command htable.delete that can be used to delete a key from htable. is there a way to delete a key in the config file like assigning $null to it or do i need to use sht_rm_name_re function that feels like an overkill? assigning $null to $sht(...) will remove the item from hash table. Ok thanks. I tried to find about that in pv wiki. I'll check again and if is is not mentioned, I'll add it. -- Juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Keep-Alive in dialog freeing a free fragment
Hello, master is still the code to be 4.3, we will make a dedicated branch sometime soon. The patch will be backported to 4.2 as well. Thanks for helping to troubleshoot and testing. Cheers, Daniel On 12/05/15 10:03, Dirk Teurlings - SIGNET B.V. wrote: Hi Daniel, This fixes the problem, thanks very much, Will this fix be included in the next (4.2 and/or 4.3) stable release? Cheers, Dirk Teurlings On 11-05-15 17:25, Daniel-Constantin Mierla wrote: Following quickly up, I pushed another patch that will remove the dialog from keepalive list as soon as 'deleted' state is discovered and also sends keepalive options only if dialog is in state 'confirmed'. Can you test the patch and see how it works? - https://github.com/kamailio/kamailio/commit/0e22abe2b89be8936df4b8230955fbaf43ad40e7 Cheers, Daniel On 11/05/15 16:55, Daniel-Constantin Mierla wrote: Hello, the message freeing a free fragment ... is from Dialog KA Timer and that process doesn't handle any SIP reply or the transmission timeout callback. I will look at the code and see if I can spot where the double free happens. But now I understand that the dialog is actually not ended, right? Cheers, Daniel On 07/05/15 17:05, Dirk Teurlings - SIGNET B.V. wrote: Hi Daniel, Good to see you found an improvement, not sure yet if it'll help us. Here is the non-debug log first. Just now I noticed that the initial dialog doesn't get ended as well now, 5fa4dc3670596fb626269f083b0c9480 in the log. The setup is like this Leg 1 Kamailio - Asterisk Leg 2 (initialized by Asterisk) - Kamailio - Gateway First the output of ps Process:: ID=0 PID=21528 Type=attendant Process:: ID=1 PID=21530 Type=udp receiver child=0 sock=127.0.0.1:5060 Process:: ID=2 PID=21531 Type=udp receiver child=0 sock=192.168.10.246:5060 Process:: ID=3 PID=21532 Type=udp receiver child=0 sock=31.223.168.246:5060 Process:: ID=4 PID=21533 Type=udp receiver child=0 sock=[::1]:5060 Process:: ID=5 PID=21534 Type=udp receiver child=0 sock=[2001:4cb8:34a:10::246]:5060 Process:: ID=6 PID=21535 Type=slow timer Process:: ID=7 PID=21536 Type=timer Process:: ID=8 PID=21537 Type=MI FIFO Process:: ID=9 PID=21538 Type=ctl handler Process:: ID=10 PID=21539 Type=TIMER NH Process:: ID=11 PID=21540 Type=Dialog KA Timer Process:: ID=12 PID=21541 Type=Dialog Clean Timer Process:: ID=13 PID=21542 Type=WLCC TB TIMER Process:: ID=14 PID=21543 Type=LLCC TB TIMER Process:: ID=15 PID=21544 Type=tcp receiver (generic) child=0 Process:: ID=16 PID=21545 Type=tcp main process And the log May 7 18:54:43 vps-host /usr/sbin/kamailio[21532]: INFO: script: 5fa4dc3670596fb626269f083b0c9480@192.168.10.245:5060 - CC, dialog:start May 7 18:54:44 vps-host /usr/sbin/kamailio[21531]: INFO: script: 4d263e35-89ea921c@172.16.0.205 - CC, dialog:start May 7 18:55:57 vps-host /usr/sbin/kamailio[21535]: INFO: script: 123 - CC, dialog:end May 7 18:55:57 vps-host /usr/sbin/kamailio[21535]: INFO: script: 123 - WLCC: ENDCALL May 7 18:55:57 vps-host /usr/sbin/kamailio[21531]: WARNING: dialog [dlg_req_within.c:212]: bye_reply_cb(): inconsitent dlg timer data on dlg 0x7fa76e546600 [869:4705] with clid '5fa4dc3670596fb626269f083b0c9480@192.168.10.245:5060' and tags 'as155a87b8' '95b0a07565f99244i0' May 7 18:55:57 vps-host /usr/sbin/kamailio[21531]: INFO: script: 4d263e35-89ea921c@172.16.0.205 - CC, dialog:end May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54aeb8/0x7fa76e54aef0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7fa76e54a4a8/0x7fa76e54a4e0) - ignore May 7 18:56:17 vps-host /usr/sbin/kamailio[21540]: INFO: core
Re: [SR-Users] kamailio crash periodically in timer handler
Dear Daniel, community, A few days ago I have already uploaded the diff that probably causes a rare crash with kamailio, but as I mentioned, we have another issue as well. Our clients are registered via TLS to kamailio, and we want to change their presence ( to offline) when the TLS connection is disconnected. TLS disconnection is detected properly, location record is removed – but presence is not updated properly on Ubuntu…. It works perfectly with Kamailio 4.2.4 on debian, but does not work on 4.2.4 on Ubuntu trusty. The configuration is the same, network environment is the same. Kamailio is built from source, with a few modifications in ul_publish.c (diff was sent a few weeks ago). We want is that if a tcp socket has broken, the contact’s of the user gets a NOTIFY with closed state. It seems it is generated but the clients do not receive this. Here are some log parts about the NOTIFY: (ERROR logs are DEBUG logs, only for easier separation) - May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:341]: ul_publish(): #012EXPIRE type May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:350]: ul_publish(): Building pidf... May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:163]: build_pidf(): PUBLISH: found expired #012 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:166]: build_pidf(): Setting open to 0 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:110]: pua_set_publish(): Device: device May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:112]: pua_set_publish(): State: closed May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:114]: pua_set_publish(): Content: lt;statusgt;lt;stategt;offlinelt;/stategt;lt;messagegt;normallt;/messagegt;lt;/statusgt; May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:285]: build_pidf(): new_body:#012?xml version=1.0?#012presence xmlns=urn:ietf:params:xml:ns:pidf xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid xmlns:c=urn:ietf:params:xml:ns:pidf:cipid entity=sip:1821043...@xxx.com#012 tuple id=closed#012status#012 basicclose/basic#012/status#012 notelt;statusgt;lt;stategt;offlinelt;/stategt;lt;messagegt;normallt;/messagegt;lt;/statusgt;/note#012 /tuple#012/presence#012 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:380]: ul_publish(): uri= sip:1821043...@xxx.com May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:136]: print_publ(): publ: May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:137]: print_publ(): uri= sip:1821043...@xxx.com May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:138]: print_publ(): id= UL_PUBLISH.lsnTjwVj_QSobXpbRkCExA.. May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:139]: print_publ(): expires= 0 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:444]: ul_publish(): Sending PUBLISH... May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23213]: INFO: presence [notify.c:1614]: send_notify_request(): NOTIFY sip:1792450...@xxx.com via sip:xcapl...@xxx.com on behalf of sip:1821043...@xxx.com for event presence May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23213]: INFO: presence [notify.c:1614]: send_notify_request(): NOTIFY sip:1792450...@xxx.com via sip:xcapl...@xxx.com on behalf of sip:1821043...@xxx.com for event presence May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23213]: INFO: presence [notify.c:1614]: send_notify_request(): NOTIFY sip:1792450...@xxx.com via sip:xcapl...@xxx.com on behalf of sip:1821043...@xxx.com for event presence May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23213]: INFO: presence [notify.c:1614]: send_notify_request(): NOTIFY sip:1792450...@xxx.com via sip:xcapl...@xxx.com on behalf of sip:1821043...@xxx.com for event presence May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23213]: INFO: presence [notify.c:1614]: send_notify_request(): NOTIFY sip:1549424...@xxx.com via sip:xcapl...@xxx.com on behalf of sip:1821043...@xxx.com for event presence May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23218]: INFO: rls [resource_notify.c:123]: get_dialog_from_did(): record not found in hash_table [rlsubs_did]= 2z1FcPpUy4xbqBTKZGdQ4g..;91f8f651;2b499685060cb5fb6380a8dd7f172ad6-f9b9 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23218]: INFO: rls [resource_notify.c:255]: send_notifies(): Dialog is NULL May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23218]: INFO: rls [resource_notify.c:123]: get_dialog_from_did(): record not found in hash_table [rlsubs_did]=
Re: [SR-Users] Repeated 200 OK from Enswitch
On 12/05/15 10:06, Darren Campbell (Primar) wrote: Here's the full conversation. Makes me wonder whether the ACK needs to go back to the same host that handled the INVITE or whether it should be returned to the host mentioned in c=IN IP4 PROVIDERMEDIAIP in the 200 OK. You still gave the conversation in one side, towards the provider. You need to get the traffic from caller side as well, which is listening on 127.0.0.1, but it is important to see what that side sends and receives. You have to grab the traffic on lo interface as well. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: DMQ htable replication issue.
Hello,
On 12/05/15 10:50, José Seabra wrote:
Hello Daniel,
This issue was my mistake, I have a htable called fscache that
connects the call-ids of each call with freeswitch ip, and now I'm
re-using the same htable to save other information that i need and
replicate it to others kamailios through DMQ.
The random values in cname field that i saw are the call-ids of calls
that are saved in this htable. this was my confusion.
Really sorry for my mistake, maybe i need vacations :)
no problem, just wanted to be sure there is no hidden issue that popped
up with your use case. But vacation is always good, of course!
Cheers,
Daniel
BR
José Seabra
2015-05-11 18:49 GMT+01:00 José Seabra joseseab...@gmail.com
mailto:joseseab...@gmail.com:
Hi Daniel,
Tomorrow i will do more tests in order to have sure about that,
because maybe i did something wrong. but tomorrow i will report
back to you.
Thank you
BR
José Seabra
2015-05-11 15:53 GMT+01:00 Daniel-Constantin Mierla
mico...@gmail.com mailto:mico...@gmail.com:
Hello,
to be sure is no problem there -- is it like if you use item
name queue:2 you get issues? It should not matter if inside
item name is : or :: -- that is part of static string.
Or it was no relation with the : inside the item name --
somehow I couldn't understand exactly where you had the problem.
Cheers,
Daniel
On 11/05/15 13:55, José Seabra wrote:
Hello
I found the root cause of this issue, I'm concatenate the
field cname queue:2, and the correct is queue::2, with
this last concatenation i don't have any issue,
Sorry for my mistake.
Regards
José Seabra
2015-05-11 12:29 GMT+01:00 José Seabra joseseab...@gmail.com
mailto:joseseab...@gmail.com:
DMQ sip message received from another kamailio:
sip:htable@10.0.20.100:5060
http://sip:htable@10.0.20.100:5060#015#012From:
sip:htable@10.0.20.101:5060
http://sip:htable@10.0.20.101:5060;tag=16d781b5e523d368d90ec40507eac972-5d82#015#012CSeq:
10 KDMQ#015#012Call-ID:
4c4a0dd935347969-24970@10.0.20.101#015#012Content-Length
http://4c4a0dd935347969-24970@10.0.20.101#015%23012Content-Length:
119#015#012User-Agent: Voicis VSIP Proxy
1.X#015#012Max-Forwards: 1#015#012Content-Type:
application/json#015#012#015#012{action:1,htname:fscache,cname:8ee2d948-71b7-1233-efac-fa163ea4443f,type:2,strval:10.0.20.106,mode:1}
M=KDMQ R=sip:htable@10.0.20.100:5060
http://sip:htable@10.0.20.100:5060
F=sip:htable@10.0.20.101:5060
http://sip:htable@10.0.20.101:5060
T=sip:htable@10.0.20.100:5060
http://sip:htable@10.0.20.100:5060
IP=udp:10.0.20.101:5060 http://10.0.20.101:5060
ID=4c4a0dd935347969-24970@10.0.20.101
mailto:4c4a0dd935347969-24970@10.0.20.101
Everytime that kamailio sends a DMQ to htable it
generates a new cname.
Regards
2015-05-11 12:21 GMT+01:00 José Seabra
joseseab...@gmail.com mailto:joseseab...@gmail.com:
Hello there,
I'm using DMQ module to replicate an htable between
several kamailio servers, what i'm noticing is that
DMQ is sending the information from one server to
another, but the htable name is not the same, for
example:
The original htable name is $sht(fscache=queue:2),
this htable is replicated to another server and the
name (queue:2) will be replaced to some random value
like this:
$sht(fscache=3c34e55ae6f9-rsf8qhhwntvw)
What happens is that the other server cannot get the
data replicated, because in script kamailio is
looking for $sht(fscache=queue:2) that is the
original name.
My kamailio version is 4.2.2, i have tested also with
version 4.2.4 but I got the same behavior.
This is an expected behavior or a bug? In case of
expected behavior how I can configure it in order to
get the value replicated from one server to another?
Thank you for your help
--
Cumprimentos
José Seabra
--
Cumprimentos
José Seabra
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org
[SR-Users] t_lookup_request()
Hello, From the documentation for t_lookup_request()[1], it is not clear whether it creates a new transaction if one does not exist: Checks if a transaction exists. Returns a positive value if so, negative otherwise. Most likely you will not want to use it, as a typical application of a look-up is to introduce a new transaction if none was found. However this is safely (atomically) done using t_newtran. This language is quite unclear in the following respects: 1) Why would I not want to use it? 2) Does the typical application mean that t_lookup_request() _will_ create a new transaction if one does not exist? 3) Do I have some means of choosing whether to invoke t_lookup_request() in a typical or atypical application? 4) This statement this is safely (atomically) done using t_newtran implies that creating a new transaction using t_lookup_request() (which also implies that yes, it does create a new transaction) is unsafe and non-atomic. Why is this? 5) Does this mean that the effect here would be to create two transactions? if(!t_lookup_request()) t_newtran(); -- Alex [1] http://kamailio.org/docs/modules/4.2.x/modules/tm.html#tm.f.t_lookup_request -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Ims_charging lose all charging information when restart
Hi Jason;
i configured cfg like below. Charging working but there is no information
about it is call forwarding and all the avps are about first session. When i
check dialog_ng hash , it can be updated. is there any flag to set call
forwarding or something.
or my problem is just logic. I am trying to use S-CSCF at the same time a
Application Server
route [X]{
if(!cr_route($avp(s:carrier),$avp(s:domian),$rU,$rU,call_id,$avp(s:route_desc)))
{
xlog(L_ALERT,[$ci] [NoRoute]);
send_reply(603, Route bulunamadi);
exit;
}
$avp(s:host)= $rd+:+$rp;
$avp(maliyet_id)=$avp(s:route_desc);
setflag(FLT_DIALOG);
set_dlg_profile(orig);
$avp(DLG_TIMEOUT_AVP) =3600;
t_newtran();
t_on_failure(1);
$var(cc_ret) = Ro_CCR(CHARGING_CCR_REPLY, orig, SCUR, , ,
location);
if ($var(cc_ret) 0) {
xlog(L_ERR,CCR Request failure\n);
sl_send_reply(402,Payment required-1);
exit;
}
return;
}
failure_route[1]{
revert_uri();
if(!cr_next_domain($avp(s:carrier),$avp(s:domian),$rU,$avp(s:host),$T_reply_code,$avp(s:domain))){
xlog(L_ALERT,callid:$ci:route:bulunamadi);
exit;
}
if(!cr_route($avp(s:carrier),$avp(s:domian),$rU,$rU,call_id,$avp(s:route_desc))){
xlog(L_ALERT,callid:$ci:route:yapilamadi);
exit;
}
$avp(maliyet_id)=$avp(s:route_desc);
$avp(s:host)= $rd+:+$rp;
$rU=05435477707;
t_on_failure(1);
if(!t_relay()) {
send_reply(408, Servis Disi);
exit;
}else{
exit;
}
return;
}
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/Ims-charging-lose-all-charging-information-when-restart-tp137742p137771.html
Sent from the Users mailing list archive at Nabble.com.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Ims_charging lose all charging information when restart
Thanks for reply. i need to learn one thing? how to handle call forwarding charging in IMS_charging. i mean that A CSCF B C |-INV- |-INV- | | | |-BUSY- | | | |-INV- - - -| it is really complex. Thanks -- View this message in context: http://sip-router.1086192.n5.nabble.com/Ims-charging-lose-all-charging-information-when-restart-tp137742p137768.html Sent from the Users mailing list archive at Nabble.com. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio crash periodically in timer handler
Hi Peter, good you mentioned the the patch, overlooked it -- is it something that you want to be pushed on main repository or some customization good for your needs? Somehow I didn't understand properly if you think that is the cause of the issue or is the solution. If you want to be pushed to the master repository, can you make a pull request on github project: - https://github.com/kamailio/kamailio It makes it easier to review, comment if needed, and merge when all is ok. On the other hand, if you were using t_suspend()/t_continue(), I pushed a patch that should avoid some race when removing suspended transaction from timer. Now, for the new issue, do I understand correctly that is when running on ubuntu? And it is not visible on Debian, where everything works as expected? What are the versions for ubuntu and debian you are using? Cheers, Daniel On 12/05/15 13:05, Péter Barabás wrote: Dear Daniel, community, A few days ago I have already uploaded the diff that probably causes a rare crash with kamailio, but as I mentioned, we have another issue as well. Our clients are registered via TLS to kamailio, and we want to change their presence ( to offline) when the TLS connection is disconnected. TLS disconnection is detected properly, location record is removed – but presence is not updated properly on Ubuntu…. It works perfectly with Kamailio 4.2.4 on debian, but does not work on 4.2.4 on Ubuntu trusty. The configuration is the same, network environment is the same. Kamailio is built from source, with a few modifications in ul_publish.c (diff was sent a few weeks ago). We want is that if a tcp socket has broken, the contact’s of the user gets a NOTIFY with closed state. It seems it is generated but the clients do not receive this. Here are some log parts about the NOTIFY: (ERROR logs are DEBUG logs, only for easier separation) - May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:341]: ul_publish(): #012EXPIRE type May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:350]: ul_publish(): Building pidf... May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:163]: build_pidf(): PUBLISH: found expired #012 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:166]: build_pidf(): Setting open to 0 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:110]: pua_set_publish(): Device: device May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:112]: pua_set_publish(): State: closed May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:114]: pua_set_publish(): Content: lt;statusgt;lt;stategt;offlinelt;/stategt;lt;messagegt;normallt;/messagegt;lt;/statusgt; May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:285]: build_pidf(): new_body:#012?xml version=1.0?#012presence xmlns=urn:ietf:params:xml:ns:pidf xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid xmlns:c=urn:ietf:params:xml:ns:pidf:cipid entity=sip:1821043...@xxx.com#012 tuple id=closed#012 status#012 basicclose/basic#012/status#012 notelt;statusgt;lt;stategt;offlinelt;/stategt;lt;messagegt;normallt;/messagegt;lt;/statusgt;/note#012 /tuple#012/presence#012 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:380]: ul_publish(): uri= sip:1821043...@xxx.com May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:136]: print_publ(): publ: May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:137]: print_publ(): uri= sip:1821043...@xxx.com May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:138]: print_publ(): id= UL_PUBLISH.lsnTjwVj_QSobXpbRkCExA.. May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:139]: print_publ(): expires= 0 May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23221]: ERROR: pua_usrloc [ul_publish.c:444]: ul_publish(): Sending PUBLISH... May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23213]: INFO: presence [notify.c:1614]: send_notify_request(): NOTIFY sip:1792450...@xxx.com via sip:xcapl...@xxx.com on behalf of sip:1821043...@xxx.com for event presence May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23213]: INFO: presence [notify.c:1614]: send_notify_request(): NOTIFY sip:1792450...@xxx.com via sip:xcapl...@xxx.com on behalf of sip:1821043...@xxx.com for event presence May 12 10:44:41 ctdsip3 /usr/local/sbin/kamailio[23213]: INFO: presence [notify.c:1614]: send_notify_request(): NOTIFY sip:1792450...@xxx.com via sip:xcapl...@xxx.com on behalf of sip:1821043...@xxx.com for event presence May 12
Re: [SR-Users] Ims_charging lose all charging information when restart
Hi Yasin, I'd imagine this 'should' work already. The dialog will be torn down on the BUSY, thereby sending a CCR(terminate). Theoretically you could re-arm the RURI/dst and then call Ro_CCR again before t_relaying Like I said, I have not tested this so if it doesn't work let us know and we can try and look at implementing something. Kind regards Jason On Tue, May 12, 2015 at 2:01 PM, ycaner yasin.ca...@netgsm.com.tr wrote: Thanks for reply. i need to learn one thing? how to handle call forwarding charging in IMS_charging. i mean that A CSCF B C |-INV- |-INV- | | | |-BUSY- | | | |-INV- - - -| it is really complex. Thanks -- View this message in context: http://sip-router.1086192.n5.nabble.com/Ims-charging-lose-all-charging-information-when-restart-tp137742p137768.html Sent from the Users mailing list archive at Nabble.com. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- *Jason Penton**Senior Manager: Applications and Services**Smile Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:* jason.barry.pentonjason.pen...@smilecoms.com name.surn...@smilecoms.com www.smilecoms.com -- This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ http://www.smilecoms.com/disclaimer ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Multi-homed Kamailio Modifies ACK
Update, manually modifying the To-Domain in ACK has fixed this, I saved the key value pair Call-ID/To-Domain of 200OK from CISCO and for corresponding ACK with same Call-ID modified the $td same problem appeared in BYE for the call, again same fix by modifying the To-Domain for the same Call-iD in subsequent BYE. QUESTION: Was this supposed to happen with mhomed Kamailio ? I have not observed this scenario with any provider/gateway other than this CISCO gw! BR, Sammy. On Tue, May 12, 2015 at 12:24 PM, SamyGo govoi...@gmail.com wrote: Yeah sure, attached here is the trace from the CISCO logs. Not in pcap format. Also this is the flow of the call. +---+ +--+ +--+ |Provider |+ +Kamailio +--+CISCO IAD | +---+ +--+ +-+ | ^ v | +---+ |Asterisk | +---+ Thanks and best Regards, -- On Tue, May 12, 2015 at 11:50 AM, Alex Balashov abalas...@evaristesys.com wrote: Is the UAC in this case a 2543 endpoint by chance? Can you send a complete SIP trace of the entire setup? -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry. *From: *SamyGo *Sent: *Tuesday, May 12, 2015 11:46 *To: *SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List *Reply To: *Kamailio (SER) - Users Mailing List *Subject: *[SR-Users] Multi-homed Kamailio Modifies ACK Hi all, I'm having a scenario where I'm sending call to CISCO IAD2431. The call establishes with 200OK from CISCO and Kamailio sends back modified ACK. Cisco at this points gives out an error and sends 200OK again, Kamailio replies with ACK, and this cycle goes on until the call drops. Here is the error from CISCO: Failed FROM/TO Request check old_from: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc old_to: sip:+1812...@sip.iamip.com:5041;tag=9FEC572E-100F new_from: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc new_to: sip:+1812211@192.168.1.244:5041;tag=9FE I've #auto_aliases=no and, listen=udp:44.33.22.11:5041 listen=udp:192.168.1.244:5041 Kamailio sends INVITE through the Public IP to the CISCO gw, but decides to change the ACK header. Any advise please. Best Regards, Sammy. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] how to delete key from htable?
there exists rpc command htable.delete that can be used to delete a key from htable. is there a way to delete a key in the config file like assigning $null to it or do i need to use sht_rm_name_re function that feels like an overkill? -- juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: DMQ htable replication issue.
Hello Daniel,
This issue was my mistake, I have a htable called fscache that connects the
call-ids of each call with freeswitch ip, and now I'm re-using the same
htable to save other information that i need and replicate it to others
kamailios through DMQ.
The random values in cname field that i saw are the call-ids of calls that
are saved in this htable. this was my confusion.
Really sorry for my mistake, maybe i need vacations :)
BR
José Seabra
2015-05-11 18:49 GMT+01:00 José Seabra joseseab...@gmail.com:
Hi Daniel,
Tomorrow i will do more tests in order to have sure about that, because
maybe i did something wrong. but tomorrow i will report back to you.
Thank you
BR
José Seabra
2015-05-11 15:53 GMT+01:00 Daniel-Constantin Mierla mico...@gmail.com:
Hello,
to be sure is no problem there -- is it like if you use item name
queue:2 you get issues? It should not matter if inside item name is :
or :: -- that is part of static string.
Or it was no relation with the : inside the item name -- somehow I
couldn't understand exactly where you had the problem.
Cheers,
Daniel
On 11/05/15 13:55, José Seabra wrote:
Hello
I found the root cause of this issue, I'm concatenate the field cname
queue:2, and the correct is queue::2, with this last concatenation i
don't have any issue,
Sorry for my mistake.
Regards
José Seabra
2015-05-11 12:29 GMT+01:00 José Seabra joseseab...@gmail.com:
DMQ sip message received from another kamailio:
sip:htable@10.0.20.100:5060#015#012From:
sip:htable@10.0.20.101:5060;tag=16d781b5e523d368d90ec40507eac972-5d82#015#012CSeq:
10 KDMQ#015#012Call-ID:
4c4a0dd935347969-24970@10.0.20.101#015#012Content-Length
http://4c4a0dd935347969-24970@10.0.20.101#015%23012Content-Length:
119#015#012User-Agent: Voicis VSIP Proxy 1.X#015#012Max-Forwards:
1#015#012Content-Type:
application/json#015#012#015#012{action:1,htname:fscache,cname:8ee2d948-71b7-1233-efac-fa163ea4443f,type:2,strval:10.0.20.106,mode:1}
M=KDMQ R=sip:htable@10.0.20.100:5060 F=sip:htable@10.0.20.101:5060 T=
sip:htable@10.0.20.100:5060 IP=udp:10.0.20.101:5060 ID=
4c4a0dd935347969-24970@10.0.20.101
Everytime that kamailio sends a DMQ to htable it generates a new
cname.
Regards
2015-05-11 12:21 GMT+01:00 José Seabra joseseab...@gmail.com:
Hello there,
I'm using DMQ module to replicate an htable between several kamailio
servers, what i'm noticing is that DMQ is sending the information from one
server to another, but the htable name is not the same, for example:
The original htable name is $sht(fscache=queue:2), this htable is
replicated to another server and the name (queue:2) will be replaced to
some random value like this:
$sht(fscache=3c34e55ae6f9-rsf8qhhwntvw)
What happens is that the other server cannot get the data replicated,
because in script kamailio is looking for $sht(fscache=queue:2) that is
the original name.
My kamailio version is 4.2.2, i have tested also with version 4.2.4
but I got the same behavior.
This is an expected behavior or a bug? In case of expected behavior
how I can configure it in order to get the value replicated from one
server to another?
Thank you for your help
--
Cumprimentos
José Seabra
--
Cumprimentos
José Seabra
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Cumprimentos
José Seabra
--
Cumprimentos
José Seabra
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Planning to release Kamailio v4.2.5
Hello, I am considering to release a new maintenance version from latest stable branch - to be v4.2.5 - next week, most likely on Tuesday (May 19) or Wednesday (May 20). If there is anything important to get in and not discussed yet, bring the topic on development mailing list. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to delete key from htable?
Juha Heinanen writes: assigning $null to $sht(...) will remove the item from hash table. Ok thanks. I tried to find about that in pv wiki. I'll check again and if is is not mentioned, I'll add it. I added note about $null assignment. While doing it, I noticed that there is nothing on the wiki page about accessing array keys entries. -- Juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Multi-homed Kamailio Modifies ACK
Hi all, I'm having a scenario where I'm sending call to CISCO IAD2431. The call establishes with 200OK from CISCO and Kamailio sends back modified ACK. Cisco at this points gives out an error and sends 200OK again, Kamailio replies with ACK, and this cycle goes on until the call drops. Here is the error from CISCO: Failed FROM/TO Request check old_from: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc old_to: sip:+1812...@sip.iamip.com:5041;tag=9FEC572E-100F new_from: Test Phone sip:+14432232221@192.168.1.106;tag=as370915fc new_to: sip:+1812211@192.168.1.244:5041;tag=9FE I've #auto_aliases=no and, listen=udp:44.33.22.11:5041 listen=udp:192.168.1.244:5041 Kamailio sends INVITE through the Public IP to the CISCO gw, but decides to change the ACK header. Any advise please. Best Regards, Sammy. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Multi-homed Kamailio Modifies ACK
Is the UAC in this case a 2543 endpoint by chance? Can you send a complete SIP trace of the entire setup?--AlexBalashov|Principal|EvaristeSystemsLLC303PerimeterCenterNorth,Suite300Atlanta,GA30346UnitedStatesTel:+1-800-250-5920(toll-free)/+1-678-954-0671(direct)Web:http://www.evaristesys.com/,http://www.csrpswitch.com/SentfrommyBlackBerry.From: SamyGoSent: Tuesday, May 12, 2015 11:46To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing ListReply To: Kamailio (SER) - Users Mailing ListSubject: [SR-Users] Multi-homed Kamailio Modifies ACKHi all,I'm having a scenario where I'm sending call to CISCO IAD2431. The call establishes with 200OK from CISCO and Kamailio sends back modified ACK. Cisco at this points gives out an error and sends 200OK again, Kamailio replies with ACK, and this cycle goes on until the call drops.Here is the error from CISCO:Failed FROM/TO Request check old_from: "Test Phone" sip:+14432232221@192.168.1.106;tag=as370915fc old_to: sip:+1812211@sip.iamip.com:5041;tag=9FEC572E-100F new_from: "Test Phone" sip:+14432232221@192.168.1.106;tag=as370915fc new_to: sip:+1812211@192.168.1.244:5041;tag=9FEI've#auto_aliases=noand,listen=udp:44.33.22.11:5041listen=udp:192.168.1.244:5041Kamailio sends INVITE through the Public IP to the CISCO gw, but decides to change the ACK header.Any advise please.Best Regards,Sammy. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
