sr-users

sr-users@lists.kamailio.org

21 participants
37573 discussions

[Kamailio-Users] Merry Christmas and a Happy New Year!
by Elena-Ramona Modroiu 25 Dec '09

25 Dec '09

Hi everybody, before you leave the computers and go on holidays, I want to thank you all for the good work and support of the Kamailio and SIP Router projects. I wish you a Merry Christmas and a Happy New Year! As the project name is a Hawaiian word - the "Kamailian" greeting is: "Mele Kalikimaka me ka Hau'oli Makahiki Hou!" How would it be in your language? May the new year bring you joy, peace, good health and prosperity! Enjoy the winter holidays! Ramona

9 9

[Kamailio-Users] Transparent bridge mode
by Vikram Ragukumar 24 Dec '09

24 Dec '09

Hello All, I am trying to setup a test scenario, where i have Kamailio and rtpproxy running on one CentOS box (Server1) and i have Asterisk running on another CentOS box (Server2). Server1 has 2 NIC's eth0 and eth1 that are both assigned Public IP's. There is a transparent bridge br0 connecting eth0 and eth1 which also has its own Public IP. Finally eth0 on Server2 also has a Public IP. Server2 must be assigned a Public IP. My goal is to modify rtpproxy so that i can intercept packets traveling to Server2, process them and let them resume along their original path. I would like to know if there is another way of setting this up so that i dont use as many Public IP's ? Do any of you see a problem with this setup, things that may not work eventually, or any other concerns ? Thanks, Vikram.

5 12

[Kamailio-Users] Server Internal Error with sample config file : Kamailio 3.0 rc3
by Ricardo Martinez 24 Dec '09

24 Dec '09

Hello list. I'm using the sample configuration that comes with Kamailio RC3. (version: kamailio 3.0.0-rc3 (i386/linux)). I have two IP phones registered in the proxy. If I call from one to another and the call is cancelled a "500 Server Internal Error" message is send back to the caller (please see the debug attached) by the proxy. This is not happening with Kamailio 1.4 or Opensips 1.6 (using the sample configurations). Could be some problem? 10.0.0.220 - Caller 10.0.0.211 - Proxy 10.0.0.152 - Callee U 10.0.0.220:5060 -> 10.0.0.211:5060 INVITE sip:5501122334@10.0.0.211:5060 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. Max-Forwards: 70. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>. Call-ID: c8e55b952ba85701. CSeq: 13486 INVITE. Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO. Allow-Events: talk, hold, conference, LocalModeStatus. Contact: "5501234567" <sip:5501234567@10.0.0.220:5060;transport=udp>;+sip.instance="<urn:uuid: 00000000-0000-1000-8000-00085D1B6C7A>". Supported: gruu, path, timer, 100rel, replaces. User-Agent: Aastra 57i/2.5.2.1010. Content-Type: application/sdp. Content-Length: 285. . v=0. o=MxSIP 0 0 IN IP4 10.0.0.220. s=SIP Call. c=IN IP4 10.0.0.220. t=0 0. m=audio 3000 RTP/AVP 18 0 8 101. a=rtpmap:18 G729/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=silenceSupp:off - - - -. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 10.0.0.211:5060 -> 10.0.0.220:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>. Call-ID: c8e55b952ba85701. CSeq: 13486 INVITE. Server: kamailio (3.0.0-rc3 (i386/linux)). Content-Length: 0. Warning: 392 10.0.0.211:5060 "Noisy feedback tells: pid=9830 req_src_ip=10.0.0.220 req_src_port=5060 in_uri=sip:5501122334@10.0.0.211:5060 out_uri=sip:5501122334@10.0.0.152:5062 via_cnt==1". . U 10.0.0.211:5060 -> 10.0.0.152:5062 INVITE sip:5501122334@10.0.0.152:5062 SIP/2.0. Record-Route: <sip:10.0.0.211;lr=on>. Via: SIP/2.0/UDP 10.0.0.211;branch=z9hG4bKfee8.a17fc93.0. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. Max-Forwards: 69. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>. Call-ID: c8e55b952ba85701. CSeq: 13486 INVITE. Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO. Allow-Events: talk, hold, conference, LocalModeStatus. Contact: "5501234567" <sip:5501234567@10.0.0.220:5060;transport=udp>;+sip.instance="<urn:uuid: 00000000-0000-1000-8000-00085D1B6C7A>". Supported: gruu, path, timer, 100rel, replaces. User-Agent: Aastra 57i/2.5.2.1010. Content-Type: application/sdp. Content-Length: 285. . v=0. o=MxSIP 0 0 IN IP4 10.0.0.220. s=SIP Call. c=IN IP4 10.0.0.220. t=0 0. m=audio 3000 RTP/AVP 18 0 8 101. a=rtpmap:18 G729/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=silenceSupp:off - - - -. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 10.0.0.152:5062 -> 10.0.0.211:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 10.0.0.211;branch=z9hG4bKfee8.a17fc93.0. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>. Call-ID: c8e55b952ba85701. CSeq: 13486 INVITE. User-Agent: T20 9.41.0.70. Content-Length: 0. . U 10.0.0.152:5062 -> 10.0.0.211:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 10.0.0.211;branch=z9hG4bKfee8.a17fc93.0. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. Record-Route: <sip:10.0.0.211;lr=on>. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>;tag=1211757599. Call-ID: c8e55b952ba85701. CSeq: 13486 INVITE. Contact: <sip:5501122334@10.0.0.152:5062>. User-Agent: T20 9.41.0.70. Allow-Events: talk,hold,conference,refer,check-sync. Content-Length: 0. . U 10.0.0.211:5060 -> 10.0.0.220:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. Record-Route: <sip:10.0.0.211;lr=on>. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>;tag=1211757599. Call-ID: c8e55b952ba85701. CSeq: 13486 INVITE. Contact: <sip:5501122334@10.0.0.152:5062>. User-Agent: T20 9.41.0.70. Allow-Events: talk,hold,conference,refer,check-sync. Content-Length: 0. . U 10.0.0.220:5060 -> 10.0.0.211:5060 CANCEL sip:5501122334@10.0.0.211:5060 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. Max-Forwards: 70. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>. Call-ID: c8e55b952ba85701. CSeq: 13486 CANCEL. Supported: gruu, path. User-Agent: Aastra 57i/2.5.2.1010. Content-Length: 0. . U 10.0.0.211:5060 -> 10.0.0.152:5062 CANCEL sip:5501122334@10.0.0.152:5062 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.211;branch=z9hG4bKfee8.a17fc93.0. Max-Forwards: 69. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>. Call-ID: c8e55b952ba85701. CSeq: 13486 CANCEL. Content-Length: 0. . U 10.0.0.211:5060 -> 10.0.0.220:5060 SIP/2.0 200 canceling. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-cd 47. Call-ID: c8e55b952ba85701. CSeq: 13486 CANCEL. Server: kamailio (3.0.0-rc3 (i386/linux)). Content-Length: 0. Warning: 392 10.0.0.211:5060 "Noisy feedback tells: pid=9831 req_src_ip=10.0.0.220 req_src_port=5060 in_uri=sip:5501122334@10.0.0.211:5060 out_uri=sip:5501122334@10.0.0.211:5060 via_cnt==1". . U 10.0.0.152:5062 -> 10.0.0.211:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.0.0.211;branch=z9hG4bKfee8.a17fc93.0. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>;tag=1211757599. Call-ID: c8e55b952ba85701. CSeq: 13486 CANCEL. User-Agent: T20 9.41.0.70. Content-Length: 0. . U 10.0.0.152:5062 -> 10.0.0.211:5060 SIP/2.0 487 Request Terminated. Via: SIP/2.0/UDP 10.0.0.211;branch=z9hG4bKfee8.a17fc93.0. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>;tag=1211757599. Call-ID: c8e55b952ba85701. CSeq: 13486 INVITE. User-Agent: T20 9.41.0.70. Content-Length: 0. . U 10.0.0.211:5060 -> 10.0.0.152:5062 ACK sip:5501122334@10.0.0.152:5062 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.211;branch=z9hG4bKfee8.a17fc93.0. Max-Forwards: 69. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>;tag=1211757599. Call-ID: c8e55b952ba85701. CSeq: 13486 ACK. Content-Length: 0. . U 10.0.0.211:5060 -> 10.0.0.220:5060 SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM). Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-cd 47. Call-ID: c8e55b952ba85701. CSeq: 13486 INVITE. Server: kamailio (3.0.0-rc3 (i386/linux)). Content-Length: 0. Warning: 392 10.0.0.211:5060 "Noisy feedback tells: pid=9830 req_src_ip=10.0.0.220 req_src_port=5060 in_uri=sip:5501122334@10.0.0.211:5060 out_uri=sip:5501122334@10.0.0.152:5062 via_cnt==2". . U 10.0.0.220:5060 -> 10.0.0.211:5060 ACK sip:5501122334@10.0.0.211:5060 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.220:5060;branch=z9hG4bKf9043df6290194056.e3af2c48f0fba0802. Max-Forwards: 70. From: "5501234567" <sip:5501234567@10.0.0.211:5060>;tag=dbaa8e4386. To: "5501122334" <sip:5501122334@10.0.0.211:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-cd 47. Call-ID: c8e55b952ba85701. CSeq: 13486 ACK. User-Agent: Aastra 57i/2.5.2.1010. Content-Length: 0. . Ricardo.-

3 9

[Kamailio-Users] kamailio/ sip-router at 26c3
by Henning Westerholt 24 Dec '09

24 Dec '09

Hi, I'll (like in the last years) participate in the annual congress of the CCC in Berlin next week - the 26c3. More informations can be found on their site: http://events.ccc.de/congress/2009/wiki/Welcome So if you are in Berlin as well in this week (not necessarly on this event) and are interested in meeting for some discussions, please drop me a mail. Best regards, Henning

1 0

[Serusers] How to remove npdi & rn parameters from INVITE messages?
by Frank Durda IV 24 Dec '09

24 Dec '09

I have another large carrier that I am trying to send calls to, and they have a requirement that you not send them the npdi and rn=nnnnnnnn parameters for all calls. If you do, the call handling will be botched and the call will fail, even if the LRN information is exactly correct. Apparently this carrier (who once owned the Death Star) is incapable of filtering or ignoring this information on their side, and the sending switch is incapable of not sending this information because they thought RFC 4694 said they MUST ALWAYS send npdi/rn on every SIP call. Of course, the RFC does not say this. Don't get me started on which party is dumber. Anyway, I was hoping that SER could act as diplomat or interpreter and with some rewrite-something() calls, SER could remove the npdi/rn, or alter them to the point that the receiving switch no longer recognized the parameters as rn/npdi and so happily does it's own thing, and the calls don't die. However, based on what documentation exists, none of the various rewrite functions appear to operate on this part of the INVITE message and replace doesn't appear to work on the first line of a message. So there seems to be a spot whose contents can't be reached or manipulated by the existing functions. Am I correct in thinking this? So, is there a way to do something with rn=NNNNNNNNNN and npdi/npdi=yes parameters without having to write a custom function to do it? Thanks in advance!

2 1

[Serusers] How to drop a redundant/broken SIP reply message?
by Frank Durda IV 24 Dec '09

24 Dec '09

I have a large carrier that I am trying to send calls to, and their major brand SIP/ISUP switch (whose name begins with a "S") has a quirk where it emits a 183 Session Progress message with no SDP payload immediately after 100 Trying, and before ACM has actually been received. When ACM is received, it emits either a 180 Ringing with a SDP payload, or a 183 Session Progress with a SDP payload. So INVITE 100 Trying 183 Session Progress (no SDP payload) 180 Ringing (or 183 Session Progress) (with SDP payload) 200 OK (with SDP payload) is what you normally get, with the two 18x messages coming one or two seconds apart. However, if the called number is busy, you get 100 Trying 183 Session Progress (no SDP payload) 486 Busy Here What the calling party experiences for that is a second or two of ring-back commencing with the 183 Session progress, then a busy signal. That's very non-compliant. So far, the carrier has been unable to get this switch to stop emitting the first 183 Session Progress message. What I would like to do is have SER detect the redundant 183 Session Progress message (which I can already detect), and then have SER discard it, eg not send that one message back to whomever the INVITE came from. So far, I have been unable to get SER to do this. While "drop" is allowed in onreply_route sections, it is silently ignored, and you get a reply anyway. I tried putting a route(666) in the onreply_route section and putting the drop in that route["666"] section, but that had no obvious effect either, although some other functions can now be used in route["666"] that so far aren't solving the problem either. It occurred to me that I could change the 183 Session Progress of the offending message to something else in the "so-what" department, such as a "181 Your Call Is Being Forwarded", but "replace()" doesn't seem to work on the first line of replies, but can certainly alter other things in the reply message. There also doesn't seem to be any way (that actually works) to change the numeric SIP Response Code value to something else, even though clearly SER has it in the variable "status". I even thought of changing the port number or IP address via a rewrite command and send the message off to nowhere, but those don't work on replies or don't appear to. So, any suggestions on how to simply drop a chosen reply message, or misdirect it or malform it to the point that the call originator doesn't recognize it anymore? Yeah, kludgy but I only need it to work for two months. Thanks in advance!

2 2

[Serusers] Ser2.1.0.
by Aleš Podskalský 23 Dec '09

23 Dec '09

Hi all, I tried to install the newest snapshot of the Ser (version 2.1.0+cvs20091126). Server has been instaled correctly, but I can't add new user to the database. I noticed that serctl was changed with new tool called sercmd. With this tool I should be able to create new user using appropriate command, but I can't find some help for it. So my question is, if this version is unable for normal use by then, or if I can fill user data in some another way and how. Thank a lot. Ales P.

2 1

[Kamailio-Users] adding inbound and outbound routes seperately
by Rodney 23 Dec '09

23 Dec '09

Ok, I have kamailio and siremis, and I need to know how to set up a separate in bound and outbound route. Peering with inbound and registering with outbound Any ideas guys? R

3 2

Re: [Kamailio-Users] PCRE Regex / Transformations Bug? (Daniel-Constantin Mierla)
by Brandon Armstead 23 Dec '09

23 Dec '09

Inaki: That is what I was looking for and it does appear you are correct! Daniel, I could see that being as a useful addition, do you imagine there being much involved to implement such a method? Thank you guys for all of your help! Sincerely, Brandon Armstead

1 0

[Kamailio-Users] Question about Contact in NAT
by Ricardo Martinez 22 Dec '09

22 Dec '09

Hello list. I know that probably this questions is more related to the SIP protocol, but is causing me problems and this is a very supportive list. I'm using a HT-286 from Grandstream behind NAT. This is the REGISTER sequence : U 200.120.46.99:29786 -> 200.100.154.35:5060 REGISTER sip:myproxy.mydomain.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.100;branch=z9hG4bKafcb21cb60db91bb. From: <sip:5501234567@myproxy.mydomain.net;user=phone>;tag=478555f337ca8f10. To: <sip:5501234567@myproxy.mydomain.net;user=phone>. Contact: *. Supported: replaces, timer. Call-ID: a51e541e3b0f66fd(a)192.168.1.100. CSeq: 100 REGISTER. Expires: 0. User-Agent: Grandstream HT287 1.1.0.42 DevId 000b822197fe. Max-Forwards: 70. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE. Content-Length: 0. . U 200.100.154.35:5060 -> 200.120.46.99:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.1.100;branch=z9hG4bKafcb21cb60db91bb;received=200.120.46.99. From: <sip:5501234567@myproxy.mydomain.net;user=phone>;tag=478555f337ca8f10. To: <sip:5501234567@myproxy.mydomain.net;user=phone>. Call-ID: a51e541e3b0f66fd(a)192.168.1.100. CSeq: 100 REGISTER. Server: Sip EXpress router (0.9.3 (i386/linux)). Content-Length: 0. Warning: 392 200.100.154.35:5060 "Noisy feedback tells: pid=29777 req_src_ip=200.120.46.99 req_src_port=29786 in_uri=sip:myproxy.mydomain.net out_uri=sip:myproxy.mydomain.net via_cnt==1". . U 200.100.154.35:5060 -> 200.120.46.99:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.1.100;branch=z9hG4bKafcb21cb60db91bb;received=200.120.46.99. From: <sip:5501234567@myproxy.mydomain.net;user=phone>;tag=478555f337ca8f10. To: <sip:5501234567@myproxy.mydomain.net;user=phone>;tag=6eb14299de2cc731d17 3c135064daec5.1fe9. Call-ID: a51e541e3b0f66fd(a)192.168.1.100. CSeq: 100 REGISTER. WWW-Authenticate: Digest realm="myproxy.mydomain.net", nonce="4b30e9281c52f640a2713c3011bb835d06005946", qop="auth". Server: Sip EXpress router (0.9.3 (i386/linux)). Content-Length: 0. Warning: 392 200.100.154.35:5060 "Noisy feedback tells: pid=29777 req_src_ip=200.120.46.99 req_src_port=29786 in_uri=sip:myproxy.mydomain.net out_uri=sip:myproxy.mydomain.net via_cnt==1". As you can see the initial REGISTER has a Contact header like this : Contact: *. Is this ok?. Is this ok by RFC? What does this means? In my cfg file I have : route[2] { # ----------------------------------------------------------------- # REGISTER Message Handler # ----------------------------------------------------------------- sl_send_reply("100", "Trying"); if (!search("^Contact:\ +\*") && client_nat_test("7")) { setflag(6); fix_nated_register(); force_rport(); }; So I think is not matching the regexp "(!search("^Contact:\ +\*")" therefore is not fixing the contact. Any ideas? Ricardo.-

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users