sr-users December 2009

sr-users@lists.kamailio.org

67 participants
96 discussions

[Serusers] How to remove npdi & rn parameters from INVITE messages?

by Frank Durda IV

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!

14 years, 3 months

[Serusers] How to drop a redundant/broken SIP reply message?

by Frank Durda IV

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!

14 years, 3 months

[Serusers] Ser2.1.0.

by Aleš Podskalský

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.

14 years, 3 months

[Kamailio-Users] adding inbound and outbound routes seperately

by Rodney

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

14 years, 3 months

Re: [Kamailio-Users] PCRE Regex / Transformations Bug? (Daniel-Constantin Mierla)

by Brandon Armstead

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

14 years, 3 months

[Kamailio-Users] Question about Contact in NAT

by Ricardo Martinez

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.-

14 years, 3 months

[Kamailio-Users] append_hf

by Corey Edwards

I'm upgrading from OpenSER 1.2.2 to Kamailio 1.5.3 and I've run into a problem with append_hf. It seems that my header only gets appended once in a while. Here's the shortened version of what I'm doing: failure_route[1]{ if (t_check_status("(486)|(600)")){ # busy handler route(15); } } route[15]{ # look up forwarding number .... if (does_uri_exist()){ append_hf("Diversion: <sip:$var(orig_user)@$Ri>;user-id=\"$var(orig_user)@$Ri\";reason=busy\r\n"); t_relay(); } } Unfortunately, the Diversion header doesn't get set every time. I can't see any difference in the logs from when it does get set and when it doesn't. I added an xlog right above append_hf and confirmed that append_hf runs each time. On a whim I added a branch_route and called it using t_on_branch. I then added duplicate code to call append_hf. I now seem to be getting more instances of Diversion being set (twice!), but still not every time. Is there something obvious I'm missing here? Any way I can ensure those headers get set every time? Corey

14 years, 3 months

[Kamailio-Users] listing users that were added

by Rafi Gordon

Hello, I had added successfully several users by : kamctl add xxx yyy How can I list all users that exist in the DB? Rgs, Rafi

14 years, 3 months

[Kamailio-Users] Question about AVP in route()

by Ricardo Martinez

Hello. I have the next situation. In my config file I have something like this.. route { ... If INVITE route(3); } ... route[1] { Route(39); t_relay() } route[3] { ... different check for the INVITE radius_load_caller_avps("$fU@$fd") (I load the next AVPS from the radius server : Attributes: SIP-AVP = "tra:sip:0217001234567@10.0.0.211:5060" SIP-AVP = "channels:1") is_avp_set("$avp(s:channels)/n") <-- this AVP seem to be load and is set OK. route(10); } route[10] { rewritehost("myproxy.mydomain.com"); route(1); } route[39] { is_avp_set("$avp(s:channels)/n") } The last check in the route(39) is not working!. Why? Ricardo Martinez Ingeniero de Desarrollo VOISSNET S.A.

14 years, 3 months

[Kamailio-Users] Presence_Dialoginfo versioning

by kamailio.org＠spam.lublink.net

Hey, I have noticed that the XML body of the dialog messages contains a version attribute. The server is counting the versions using the latest subscription as a reference point, and the phone is counting the versions from the first subscription ( at reboot ). Which is the correct way to count these versions? Consider : 10:00 Subscription 10:05 Notification version 1 10:35 Notification version 2 11:01 Subscription 11:05 Notification version X Is X = 3 because it is the third notification or 1 because it is the first after the last subscription? If it's version 1, it could confuse the phone cause a notification that is sent at the same time as the notification would have a confusing version. On the other hand, each subscription, has it's own versioning, so would it not logically follow that the different subscriptions for the same device have seperate versioning? From my phone : BLF Notify received for line: 3 has older version: 3 last version:135 To confirm my theory, I redialed the number 133 times, and once the version number had run up to 136, the lights started flashing again. Is this a bug in Grandstream, Kamailio, or perhaps an RFC which was unclear? Thanks, David

14 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 December 2009