sr-users December 2008

sr-users@lists.kamailio.org

73 participants
107 discussions

[Kamailio-Users] AudioCodes + Kamailio : Problem in SIP Message Headers

by Samuel Muller

Hello all, I recently add a classical Audiocodes Mediant 2000 with 2x 8E1, the purpose is to have several interconnections with PSTN. I configured it like this : Audiocodes registers as a gateway to the Kamailio, using a dedicated port (5062). Registration seems to be OK, and the pstn gw uses OPTIONS method to ping the proxy. I can attack the Audiocodes with a SIP phone behind Kamailio, no pbm. But the audiocodes returns some errors about SIP headers sent by Kamailio : ( sip_stack)(44732 ) AcSIPParser: Problem in SIP Message Headers [Time: 12:30:26] ( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected symbol '0' in scheme. ALPHA expected Here you have the example of an INVITE from a SIP phone to the PSTN : ** audiocodes debug ** 4d:12h:30m:26s ( lgr_flow)(44730 ) ---- Incoming SIP Message from 77.246.81.132:5060 ---- INVITE sip:0323719001@77.246.81.136:5062;transport=udp SIP/2.0 Record-Route: <sip:77.246.81.132;lr=on;ftag=71078b346a20fb3eo0;nat=yes> Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bKdace.1ab1d59.0 Via: SIP/2.0/UDP 192.168.0.113:5060;rport=15170;received=77.246.81.162;branch=z9hG4bK-b432f96 From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr>>;tag=71078b346a20fb3eo0 To: <sip:0323719001@sip.720.fr <sip%3A0323719001(a)sip.720.fr>> Call-ID: 944d8aec-27503ee6(a)192.168.0.113 CSeq: 102 INVITE Max-Forwards: 49 Contact: "Sam" <sip:0123451010@77.246.81.162:15170> Expires: 240 User-Agent: Linksys/SPA941-5.1.8 Content-Length: 281 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, replaces Content-Type: application/sdp P-Asserted-Identity: <0123451010> Remote-Party-ID: <0123451010>;party=caller;privacy=none;screen=yes v=0 o=- 26933860 26933860 IN IP4 192.168.0.113 s=- c=IN IP4 77.246.81.133 t=0 0 m=audio 35038 RTP/AVP 18 0 8 101 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv a=nortpproxy:yes ( sip_stack)(44732 ) AcSIPParser: Problem in SIP Message Headers [Time: 12:30:26] ( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected symbol '0' in scheme. ALPHA expected ( sip_stack)(44734 ) !! [ERROR] Message type: INVITE [Time: 12:30:26] ( sip_stack)(44735 ) !! [ERROR] Source header: [Time: 12:30:26] ( sip_stack)(44736 ) !! [ERROR] Line: 17. Column: 23 [Time: 12:30:26] The outgoing INVITE from Kamailio is exactly the same received by the AudioCodes. When I searched over Google, I just found 2 answers about Asterisk / Audiocodes unsolved problem, but no more informations. I supposed that the problem is as indicated : " s=- " where source is empty in place of "NULL" / "0" or something like this ... Someone can confirm or already met the problem ? Many thanks all :) .Sam.

10 years, 6 months

[OpenSER-Users] uaCSTA support in openser

by Hugo Koblmueller

high.all! i'm wondering if there is any support of uaCSTA in openser (planned)? i'm just working on the integration of asterisk (*) environment to OCS 2007 environment, having openSER in the middle (mainly for TCP/UDP translation and smoothing out the protocol deficienes on both sides). in this setup the * having the openSER in front is talking to the OCS (and vice versa) via the OCS mediation server, which is moreorless sending standard SIP messages, which enables normal softphone (integration to *) of the office communicator. this configuration is already working... now i'm planning to go for the CTI integration, where there is no OCS mediation server in between OCS and openSER, doing the translation of SIP/CSTA to SIP. i'm thinking about using openSER for this task, that's why i'm looking for a CSTA module or perl programm, which is capable of this functionality. afaik for the CTI communication there isn't the full complexity of CSTA needed, just a subset mainly for call setup and call clearing. anyone having experience on this topic? thx & cheers -hugo Great Ideas for Small Devices Hugo Koblmueller Senior Staff Engineer Software Development COMNEON electronic technology GmbH & Co. OHG Freistaedter Strasse 400 4040 Linz Austria hugo.koblmueller(a)comneon.com tel: fax: mobile: Skype ID: +43 (5) 1777 - 15730 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%285%2 9+1777+%2D+15730&Email=hugo(a)koblmueller.com> +43 (5) 1777 - 15810 +43 (676) 82051280 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%28676 %29+82051280&Email=hugo(a)koblmueller.com> drhookson Want to always have my latest info? <https://www.plaxo.com/add_me?u=21475050628&src=client_sig_212_1_banner_join &invite=1&lang=en> Want a signature like <http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig&lang=en> this?

12 years, 1 month

[Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?

by Frank Durda IV

I'm running into a problem with rtpproxy on this point, quoting from the README: - - - - - - - - - - - - after the session has been created, the proxy listens on the port it has allocated for that session and waits for receiving at least one UDP packet from each of two parties participating in the call. Once such packet is received, the proxy fills one of two ip:port structures associated with each call with source ip:port of that packet. When both structures are filled in, the proxy starts relaying UDP packets between parties; - - - - - - - - - - - However, a number of clients frequently fail to emit any audio when originating a call until they hear something from the TDM gateway, such as ring-back or the called party answering. So although rtpproxy is receiving a stream of audio, such as a voice mail menu robot, the calling party can't hear any of it unless they happen to make some noise or randomly and blindly press a DTMF key. This seems to be made worse on links with silence suppression, so there is no background noise to trigger two-way audio. This is being encountered between Class 4 carriers, so we don't have the option to get someone to adjust their phone/PBX settings or have them breathe heavier. Is there a setting adjustment to get rtpproxy to just pass the RTP packets from directed calling and called sources even if one party hasn't happened to make noise yet? I personally don't understand why this requirement for seeing audio from both sides before starting the flow in either direction if audio starts coming in even exists. It seems to have no benefit but is bound to cause this deadly embrace problem in many situations that may be beyond the control of the owners of the equipment passing traffic along to the site where rtpproxy is in use. Suggestions? Fix? I have looked at the latest snapshot of rtpproxy and the README is unchanged since 1.1 so apparently this behavior is still the same. Thanks in advance!

14 years

[OpenSER-Users] [OT] How to handle different DID's in incoming calls for a registered client?

by Iñaki Baz Castillo

Hi, maybe this question is a bit off-topic so I'm sorry for that. My question is about SIP providers using OpenSer that associate PSTN numbers to their local clients (SIP accounts): Usually the client must register to OpenSer in order to receive calls. Then it will appear in location table with "Contact=sip:clientX@IP". Suppose clientX has two PSTN numbers associated in a ENUM entry: +34999000111 +34999000222 When anyone in PSTN world calls to +34999000222 the call will arrive to the OpenSer from a gateway in an INVITE like: INVITE sip:+34999000222@gateway SIP/2.0 To: <sip:+34999000222@gateway> The OpenSer will do the lookup in location table and finally send this INVITE to the clientX: INVITE sip:clientX@IP_clientX SIP/2.0 To: <sip:+34999000222@gateway> The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there? Thanks for any comment. Regards. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

14 years, 1 month

[Kamailio-Users] Looking for a highly available / load balanced setup

by John D

I currently have three Asterisk servers in my environment. None of them speak to each other just yet. The idea is to install Kamailio and be able to load balance/distribute SIP calls to any of the three asterisk boxes. If an entire box plug gets pulled, the operation continues. If a Kamailio box gets the plug pulled (and due to limited resources, I plan at first to run kamailio on all three of the asterisk boxes), the operation will continue. Does anyone have good documentation or insight in order to facilitate this sort of setup? Thanks.

14 years, 1 month

[Kamailio-Users] Carrierroute and AVP

by rod

Hi, I'd like to know if there is a way to retrieve the information from the carrierroute module in AVPs. Example: - a prefix has matched, and I'd like to get the field "description" associated with this route and add it in the SIP header - a prefix has matched, and I'd like to get the field "rewrite_host" associated with this route and use it with xlog Thanks, rod.

14 years, 2 months

[Kamailio-Users] Help!! Getting get_hdr_field: out of memory

by Krunal Patel

Hi, I am using openser 1.2.3. I have increased PKG_MEM_POOL_SIZE to 4MB. Openser worked properly for 4 days since last restart. I found get_hdr_field: out of memory for all messages. I did openser restart & the issue is fixed now. Is anybody there who have faced the same issue? Thanks in advance!! -- Krunal patel

14 years, 2 months

[Kamailio-Users] Accounting: How to avoid a fraudulent BYE with lower CSeq?

by Iñaki Baz Castillo

Hi, first of all I'm sorry for this cross-posting, but I think it could be interesting for any SIP proxy with accounting capabilities. I'm thinking in the following flow in which the caller/attacker would get an unlimited call (but a limited CDR duration): -------------------------------------------------------------------------- attacker Kamailio (Acc) gateway INVITE (CSeq 12) ------> <-------- 407 Proxy Auth INVITE (CSeq 13) ------> INVITE (CSeq 13) ------> <------------------- 200 Ok <------------------- 200 Ok << Acc START >> ACK (CSeq 13) -----------> ACK (CSeq 13) -----------> <******************* RTP ************************> # Fraudulent BYE !!! BYE (CSeq 10) -----------> << Acc STOP >> BYE (CSeq 10) -----------> <-- 500 Req Out of Order <-- 500 Req Out of Order -------------------------------------------------------------------------- The call hasn't finished, but Kamailio has ended the accounting for this call since it received a BYE. And this BYE will generate a correct ACC Stop action (since it matches From_tag, To_tag and Call-ID). I think this is *VERY* dangerous and I hope I'm wrong. Would help the dialog module here? does the dialog module check the CSeq of the BYE in some way and could it prevent Kamailio from generating the ACC STOP action? (I don't think so). I've also asked in SIP-implementors and an idea could be generating the ACC STOP action when receiving the 200 OK for the BYE (and not when receiving the BYE itself). Of course this will be valid when the gateway is the recipient of the BYE (and we know the gateway is not an "attacker"), but this is not valid when the recipient of the BYE is an user since it could send no reply for the BYE. The only solution I see is: - Using the dialog module, Kamailio should check the CSeq value in the BYE. 1) Kamailio should forward the BYE just in case the CSeq is higher than the actual CSeq for this dialog direction. 2) Kamailio should generate the ACC STOP action just in case the CSeq is higher than the actual CSeq for this dialog direction. Both 1) and 2) are needed since a gateway could accept a BYE with wrong CSeq. In this case the call is ended but the accounting STOP action doesn't exist (infinite call). But I think this is too complex, isn't it? -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 2 months

[Kamailio-Users] prepaid system

by igor

I need implement a prepaid system in my kamilio ! anybody help me !? any information ! Atenciosamente, Igor Marques celular: 55 21 7858 7499 nextel: 87*24074 e-mail: igor(a)carneiro.cc web: www.carneiro.cc -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

14 years, 2 months

[Kamailio-Users] trying to use call park for similar a music on hold

by Ricky Gutierrez

Hi list, I am trying to make work to the parking of calls with openser and asterisk, which I want to do is when two UAC are in the middle of a call one of them can transfer a call with *700 and this is sent to asterisk to the extension by default... the problem here is that when I make the transfer to the extension 700 the asterisk it doesn't return it to the extension that I originate the transfer, the call it returns to the extension in delay .. I can see when I make the transfer in the SDP that the openser puts me c=IN IP4 0.0.0.0 , but asterisk doesn't return the call to the extension that I originate the transfer U +2.857758 192.168.10.40:5060 -> 192.168.10.1:5060 INVITE sip:*700@192.168.10.1:5070 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Contact: <sip:112@192.168.10.40:5060;transport=udp> Supported: replaces, timer, path Referred-By: <sip:120@192.168.10.38:5060> Proxy-Authorization: Digest username="112", realm="192.168.10.1", algorithm=MD5, uri="sip:*700@192.168.10.1:5070", nonce="495ac4ad695509e755aba895780497e8116e6353", response="40021b3138cbfefcd079505a55c6043f" Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Content-Length: 352 v=0 o=112 8001 8002 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 5006 RTP/AVP 0 18 3 97 2 9 101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/16000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 # U +0.000646 192.168.10.1:5060 -> 192.168.10.40:5060 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE Server: OpenSER (1.3.4-notls (i386/linux)) Content-Length: 0 # U +0.000078 192.168.10.1:5060 -> 192.168.10.1:5070 INVITE sip:*700@192.168.10.1:5070 SIP/2.0 Record-Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Contact: <sip:112@192.168.10.40:5060;transport=udp> Supported: replaces, timer, path Referred-By: <sip:120@192.168.10.38:5060> Proxy-Authorization: Digest username="112", realm="192.168.10.1", algorithm=MD5, uri="sip:*700@192.168.10.1:5070", nonce="495ac4ad695509e755aba895780497e8116e6353", response="40021b3138cbfefcd079505a55c6043f" Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Content-Length: 352 v=0 o=112 8001 8002 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 5006 RTP/AVP 0 18 3 97 2 9 101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/16000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 # U +0.000263 192.168.10.1:5070 -> 192.168.10.1:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0;received=192.168.10.1 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:*700@192.168.10.1:5070> Content-Length: 0 # U +0.000104 192.168.10.1:5070 -> 192.168.10.1:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0;received=192.168.10.1 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:*700@192.168.10.1:5070> Content-Type: application/sdp Content-Length: 285 v=0 o=root 9758 9759 IN IP4 192.168.10.1 s=session c=IN IP4 192.168.10.1 t=0 0 m=audio 15948 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=recvonly # U +0.000104 192.168.10.1:5060 -> 192.168.10.40:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:*700@192.168.10.1:5070> Content-Type: application/sdp Content-Length: 285 v=0 o=root 9758 9759 IN IP4 192.168.10.1 s=session c=IN IP4 192.168.10.1 t=0 0 m=audio 15948 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=recvonly # U +0.054311 192.168.10.40:5060 -> 192.168.10.1:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK745a.fb2f15e.0 Via: SIP/2.0/UDP 192.168.10.1:5070;branch=z9hG4bK61abb915;rport=5070 Record-Route: <sip:192.168.10.1;lr=on;ftag=as6fb8efad> From: "Ventas" <sip:112@192.168.10.1>;tag=as6fb8efad To: <sip:112@192.168.10.1>;tag=368cbb40ae863e2a Call-ID: 3492c4a24c10596e6e3063c361c67eb9(a)192.168.10.1 CSeq: 102 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Contact: <sip:112@192.168.10.40:5060;transport=udp> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Supported: replaces, timer Content-Length: 234 v=0 o=112 8000 8000 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 192.168.10.40 t=0 0 m=audio 5004 RTP/AVP 0 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 0 RTP/AVP 99 # U +0.000097 192.168.10.1:5060 -> 192.168.10.1:5070 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1:5070;branch=z9hG4bK61abb915;rport=5070 Record-Route: <sip:192.168.10.1;lr=on;ftag=as6fb8efad> From: "Ventas" <sip:112@192.168.10.1>;tag=as6fb8efad To: <sip:112@192.168.10.1>;tag=368cbb40ae863e2a Call-ID: 3492c4a24c10596e6e3063c361c67eb9(a)192.168.10.1 CSeq: 102 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Contact: <sip:112@192.168.10.40:5060;transport=udp> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Supported: replaces, timer Content-Length: 234 I have openser and asterisk with realtime any ideas ? regards list rickygm

14 years, 3 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users December 2008