[OpenSIPS-Users] Opensips 1.9.1 accounting
Hello! In attachment you can find ordinary call (not successful) 1.1.1.1- SIP UA 1.1.1.2- Opensips 1.1.1.3- SIP UA In opensips.cfg modparam(acc, early_media, 0) modparam(acc, report_cancels, 1) modparam(acc, detect_direction, 1) modparam(acc, db_flag, 15) modparam(acc, db_missed_flag, 16) modparam(acc, failed_transaction_flag, 17) modparam(acc, db_table_acc, acc) modparam(acc, db_table_missed_calls, acc) modparam(acc, cdr_flag, 22) and before INVITE will be translated to callee SIP UA setflag(15); setflag(16); setflag(17); setflag(22); I see that Opensips tried to insert several entries into acc. The question is, why did Opensips try to insert into acc several entries due to one call? Is this because of db_flag and failed_transaction_flag? Thank you for any help. image001.gifU 2014/03/26 10:49:08.556019 1.1.1.1:53876 - 1.1.1.2:5060 INVITE sip:3364399@1.1.1.2:5060 SIP/2.0. Via: SIP/2.0/UDP 1.1.1.1:5060;x-route-tag=tgrp:TFOP;branch=z9hG4bK448B21124B. From: sip:8123364283@1.1.1.1;tag=32C4640-18B3. To: sip:3364399@1.1.1.2. Date: Wed, 26 Mar 2014 06:49:08 GMT. Call-ID: 90A25AC0-B3E911E3-B077DBBA-3DF918A8@1.1.1.1. Supported: 100rel,timer,resource-priority,replaces,sdp-anat. Min-SE: 1800. Cisco-Guid: 2426479216-3018396131-3064463394-2438468884. User-Agent: Cisco-SIPGateway/IOS-12.x. Accept-Language: ru. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER. CSeq: 101 INVITE. Max-Forwards: 15. Timestamp: 1395816548. Contact: sip:8123364283@1.1.1.1:5060. Expires: 100. Allow-Events: telephone-event. P-Asserted-Identity: sip:8123364283@1.1.1.1. Content-Type: application/sdp. Content-Disposition: session;handling=required. Content-Length: 310. . v=0. o=CiscoSystemsSIP-GW-UserAgent 4030 1274 IN IP4 1.1.1.1. s=SIP Call. c=IN IP4 1.1.1.1. t=0 0. m=audio 18038 RTP/AVP 8 0 18 101. c=IN IP4 1.1.1.1. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. U 2014/03/26 10:49:08.557516 1.1.1.2:5060 - 1.1.1.1:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 1.1.1.1:5060;x-route-tag=tgrp:TFOP;branch=z9hG4bK448B21124B. From: sip:8123364283@1.1.1.1;tag=32C4640-18B3. To: sip:3364399@1.1.1.2. Call-ID: 90A25AC0-B3E911E3-B077DBBA-3DF918A8@1.1.1.1. CSeq: 101 INVITE. Content-Length: 0. . U 2014/03/26 10:49:08.566102 1.1.1.2:5060 - 1.1.1.3:5060 INVITE sip:78123364399@1.1.1.3:5060 SIP/2.0. Record-Route: sip:1.1.1.2;lr;ftag=32C4640-18B3;did=8de.cf20f431. Via: SIP/2.0/UDP 1.1.1.2:5060;branch=z9hG4bKcad3.e39f27b7.0. Via: SIP/2.0/UDP 1.1.1.1:5060;x-route-tag=tgrp:TFOP;branch=z9hG4bK448B21124B. From: sip:8123364283@1.1.1.1;tag=32C4640-18B3. To: sip:3364399@1.1.1.2. Date: Wed, 26 Mar 2014 06:49:08 GMT. Call-ID: 90A25AC0-B3E911E3-B077DBBA-3DF918A8@1.1.1.1. Supported: 100rel,timer,resource-priority,replaces,sdp-anat. Min-SE: 1800. Cisco-Guid: 2426479216-3018396131-3064463394-2438468884. User-Agent: Cisco-SIPGateway/IOS-12.x. Accept-Language: ru. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER. CSeq: 101 INVITE. Max-Forwards: 15. Timestamp: 1395816548. Contact: sip:8123364283@1.1.1.1:5060. Remote-Party-ID:sip:8123364283@1.1.1.1;party=calling;screen=yes;privacy=off. Expires: 100. Allow-Events: telephone-event. P-Asserted-Identity: sip:8123364283@1.1.1.1. Content-Type: application/sdp. Content-Disposition: session;handling=required. Content-Length: 310. . v=0. o=CiscoSystemsSIP-GW-UserAgent 4030 1274 IN IP4 1.1.1.1. s=SIP Call. c=IN IP4 1.1.1.1. t=0 0. m=audio 18038 RTP/AVP 8 0 18 101. c=IN IP4 1.1.1.1. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. U 2014/03/26 10:49:08.573798 1.1.1.3:5060 - 1.1.1.2:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 1.1.1.2:5060;branch=z9hG4bKcad3.e39f27b7.0. Via: SIP/2.0/UDP 1.1.1.1:5060;x-route-tag=tgrp:TFOP;branch=z9hG4bK448B21124B. From: sip:8123364283@1.1.1.1;tag=32C4640-18B3. To: sip:3364399@1.1.1.2. Call-ID: 90A25AC0-B3E911E3-B077DBBA-3DF918A8@1.1.1.1. CSeq: 101 INVITE. Server: Telphin SoftSwitch. Content-Length: 0. . U 2014/03/26 10:49:08.576295 1.1.1.3:5060 - 1.1.1.2:5060 SIP/2.0 603 Declined. Via: SIP/2.0/UDP 1.1.1.2:5060;branch=z9hG4bKcad3.e39f27b7.0. Via: SIP/2.0/UDP 1.1.1.1:5060;x-route-tag=tgrp:TFOP;branch=z9hG4bK448B21124B. From: sip:8123364283@1.1.1.1;tag=32C4640-18B3. To: sip:3364399@1.1.1.2;tag=as26700a4a. Call-ID: 90A25AC0-B3E911E3-B077DBBA-3DF918A8@1.1.1.1. CSeq: 101 INVITE. Server: Telphin MediaServer. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces. Content-Length: 0. . U 2014/03/26 10:49:08.576787 1.1.1.2:5060 - 1.1.1.3:5060 ACK sip:78123364399@1.1.1.3:5060 SIP/2.0. Via: SIP/2.0/UDP 1.1.1.2:5060;branch=z9hG4bKcad3.e39f27b7.0. From: sip:8123364283@1.1.1.1;tag=32C4640-18B3. Call-ID:
Re: [OpenSIPS-Users] Unable to parse SDP when processing 200 OK from pure-audio polycom phone
Hi Razvan, I did an experiment and found that the OpenSIPS server did not send a command to the RTPProxy when the video port in SDP is 0. So this should not be an issue of the RTPProxy. If you have any comment, please let me know. Great thanks for your help. Best wishes, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Unable-to-parse-SDP-when-processing-200-OK-from-pure-audio-polycom-phone-tp7590276p7590384.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] TCP
Our SIP client is sending TCP register request to opensips[use opensips as a loadbalancer ] server but its not forwarding this request to load balancing servers. Why opensips not forwarding tcp request... my opensips configuration core parameters listen=udp:eth0:5060 listen=udp:eth0:7000 listen=tcp:eth0:5060 listen=tcp:eth0:7000 tcp_accept_aliases=yes tcp_connect_timeout=3 tcp_connection_lifetime=120 tcp_max_connections=2048___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Adding Proxy-Authorization header
Hi Bogdan,
I followed your sugestion and found the follwing error:
Mar 26 12:53:15 [12396] DBG:uac:uac_auth: no credential for realm ctelpbx
So, I added the following lines to my configuration script:
modparam(uac,auth_username_avp, $avp(user))
modparam(uac,auth_password_avp, $avp(pass))
modparam(uac,auth_realm_avp, $avp(realm))
route{
$avp(user)=268;
$avp(pass)=123456;
$avp(realm)=ctelpbx;
Opensips is still not sending the invite with the Proxy-Authorizatin
header, and now the log is showing this:
Mar 26 16:14:32 [5178] DBG:uac:uac_auth: picked reply is 0xb6b68b68, code
407
Mar 26 16:14:32 [5178] DBG:core:parse_headers: flags=200
Mar 26 16:14:32 [5178] DBG:core:parse_authenticate_body: algorithm=MD5
state=7
Mar 26 16:14:32 [5178] DBG:core:parse_authenticate_body: realm=ctelpbx
state=2
Mar 26 16:14:32 [5178] DBG:core:parse_authenticate_body: nonce=6f0a2c46
state=3
Mar 26 16:14:32 [5178] DBG:uac_auth:build_authorization_hdr: hdr is
Proxy-Authorization: Digest username=268, realm=ctelpbx,
nonce=6f0a2c46, uri=sip:229@192.168.2.98:5060,
response=fc3cfd31f4a053d5d16b5ae8f463830d, algorithm=MD5
Mar 26 16:14:32 [5178] DBG:core:parse_headers: flags=
Mar 26 16:14:32 [5178] DBG:core:buf_init: initializing...
Any suggestion?
Thanks
Diego
On Fri, Mar 7, 2014 at 8:50 AM, Bogdan-Andrei Iancu bog...@opensips.orgwrote:
Hi Diego,
Set debug = 4 and watch the logs from the uac_auth() function (also the
return code) - I assume the function did not find any credentials (on the
server side) to match the authentication challenge (the matching is done
based on the realm).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
On 05.03.2014 19:38, Diego Barberio wrote:
Hi Stefano, Vlad
Thank you for your response I tried your suggestion but still doesn't
work. This is a snippet from my script:
modparam(uac_auth,credential,268:192.168.2.98:password)
t_on_failure(2);
t_relay();
failure_route[2] {
if(t_check_status(407)){
uac_auth();
xlog(In failure route 2\n);
}
}
According to the log, the uac_auth function is being called but the
following INVITEs doesn't include the Proxy-Authorization header
What am I missing?
Thanks
Diego
On Mon, Feb 24, 2014 at 2:12 PM, Vlad Paiu vladp...@opensips.org wrote:
Hello,
The registrant module is to be used only for generating REGISTER requests
( with auth included ).
For proxied calls, you need to use the uac and uac_auth modules ( [1] )
for adding the auth headers - call uac_auth() ( [2] ) function within
failure route when receiving a challenge.
[1] http://www.opensips.org/html/docs/modules/1.11.x/uac_auth.html
[2] http://www.opensips.org/html/docs/modules/1.11.x/uac.html#id250288
Best Regards
Vlad Paiu
OpenSIPS Developerhttp://www.opensips-solutions.com
On 24.02.2014 17:33, Stefano Pisani wrote:
You can use module UAC_AUTH
Il 24/02/2014 16.18, Diego Barberio ha scritto:
Hi all,
I have opensips registered to an IP-PBX using registrant module and I
want to make an outbound call to that PBX through the proxy.
I'm sending and INVITE from my application to the proxy with a From that
is actually registered by the proxy, however OpenSIPs is not adding the
Proxy-Authorization header so the INVITE is rejected with a 401
Unauthorized and that response is forwarded to my application.
I just want opensips to add the Proxy-Authorization header so the call
is not rejected by the IP-PBX. Is it possible to achieve this?
Thanks
Diego
___
Users mailing
listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing
listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing
listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
