sr-users May 2011

sr-users@lists.kamailio.org

78 participants
129 discussions

Via branch parameter in end2end ACK
by Juha Heinanen 20 May '11

20 May '11

Daniel-Constantin Mierla writes: > if I understood right, it is about 200 ACK which are forwarded > stateless. If yes, then should be only in forward.c, the condition at > line 545, where the assignment can be changed in a memcpy. for example like this? if so, i can go and make the commit. -- juha if (syn_branch ) { memcpy*(*msg->add_to_branch_s, "z9hG4bKcydzigwkX", 16); msg->add_to_branch_len=16; } else {

2 1

IPv6
by Jon Farmer 20 May '11

20 May '11

Hi How do I represent the following if the address was IPv6? if(src_ip ==127.0.0.1) If I specify the IPv6 address with our without [] I get WARNING:core:fix_socket_list: could not rev. resolve <ipv6_addr> Regards Jon -- Jon Farmer Tel: 07795 118140 Email: viperdudeuk(a)gmail.com Twitter: @viperdudeuk

3 2

xHTTP module.
by David J. 20 May '11

20 May '11

I was wondering if I can make an HTTP request to Kamailio; and then have kamailio do a lookup based on passed parameters to connect callers. I am trying to make a click-to-dial type application; I was looking at the HTTP server inside kamailio; It was interesting to me to try to use this as an alternative to php-asterisk; (I know kamailio is not a full blown application server;) If anyone could help me with this I would appreciate it; Thanks in advance. David.

2 4

Re: [SR-Users] ACK to 486 is not being proxied
by Daniel-Constantin Mierla 20 May '11

20 May '11

Please do not write private emails, keep the mailing list cc-ed. Can you get the output of: ngrep -d any -qt -W byline port 5040 on kamailio server for such a call? Include all messages, since you may miss something in your filtering (like you did below), of course you can mask the ip addresses. Also, be sure you do t_relay() to forward the invite from kamailio on. Cheers, Daniel On 5/20/11 3:47 PM, Carl Wagner wrote: > Daniel, > > With a non-2xx reply being hop-by-hop, shouldn't Kamailio receive the > 486, send the ACK to the sender, and then proxy the 486? > > I am not seeing the 486 message in the Kamailio log so I assume that > it automatically handles it without hitting the kamailio.cfg script? > Or do I need to set up a failure_route to catch the 486 and send the > ACK there? > > Please see the log below. > > Thanks, > Carl > > > > # Asterisk to Kamailio > U 2011/05/19 14:13:01.467157 3.4.5.167:5060 -> 3.4.5.164:5060 > INVITE sip:+13031112222@3.4.5.164 SIP/2.0. > Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport. > From: "+13032223333" <sip:+13032223333@3.4.5.167>;tag=as1f559f5a. > To: <sip:+13031112222@3.4.5.164>. > Contact: <sip:+13032223333@3.4.5.167>. > Call-ID: 37ef92a26c31a7f85958ae996d49a872(a)3.4.5.167. > CSeq: 102 INVITE. > User-Agent: Asterisk. > Max-Forwards: 70. > Date: Thu, 19 May 2011 20:13:01 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. > Supported: replaces. > Content-Type: application/sdp. > Content-Length: 238. > . > v=0. > o=root 27806 27806 IN IP4 3.4.5.167. > s=session. > c=IN IP4 3.4.5.167. > t=0 0. > m=audio 13424 RTP/AVP 0 101. > a=rtpmap:0 PCMU/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-16. > a=silenceSupp:off - - - -. > a=ptime:20. > a=sendrecv. > > # Kamailio to provider > U 2011/05/19 14:13:01.468627 3.4.5.164:5060 -> 2.3.4.40:5060 > INVITE sip:+13031112222@2.3.4.40:5060 SIP/2.0. > Record-Route: <sip:3.4.5.164;lr=on>. > Via: SIP/2.0/UDP 3.4.5.164;branch=0. > Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060. > From: "+13032223333" <sip:+13032223333@3.4.5.167>;tag=as1f559f5a. > To: <sip:+13031112222@2.3.4.40:5060>. > Contact: <sip:+13032223333@3.4.5.167>. > Call-ID: 37ef92a26c31a7f85958ae996d49a872(a)3.4.5.167. > CSeq: 102 INVITE. > User-Agent: Asterisk. > Max-Forwards: 69. > Date: Thu, 19 May 2011 20:13:01 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. > Supported: replaces. > Content-Type: application/sdp. > Content-Length: 238. > . > v=0. > o=root 27806 27806 IN IP4 3.4.5.167. > s=session. > c=IN IP4 3.4.5.167. > t=0 0. > m=audio 13424 RTP/AVP 0 101. > a=rtpmap:0 PCMU/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-16. > a=silenceSupp:off - - - -. > a=ptime:20. > a=sendrecv. > > > U 2011/05/19 14:13:01.511775 2.3.4.40:37897 -> 3.4.5.164:5060 > SIP/2.0 100 Trying. > Via: SIP/2.0/UDP 3.4.5.164;branch=0,SIP/2.0/UDP > 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060. > From: "+13032223333" <sip:+13032223333@3.4.5.167>;tag=as1f559f5a. > To: <sip:+13031112222@2.3.4.40:5060>. > Call-ID: 37ef92a26c31a7f85958ae996d49a872(a)3.4.5.167. > CSeq: 102 INVITE. > Content-Length: 0. > . > > > U 2011/05/19 14:13:01.513162 3.4.5.164:5060 -> 3.4.5.167:5060 > SIP/2.0 100 Trying. > Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060. > From: "+13032223333" <sip:+13032223333@3.4.5.167>;tag=as1f559f5a. > To: <sip:+13031112222@2.3.4.40:5060>. > Call-ID: 37ef92a26c31a7f85958ae996d49a872(a)3.4.5.167. > CSeq: 102 INVITE. > Content-Length: 0. > . > > # provider says they are busy > U 2011/05/19 14:13:03.239462 2.3.4.40:37897 -> 3.4.5.164:5060 > SIP/2.0 486 Busy Here. > Via: SIP/2.0/UDP 3.4.5.164;branch=0,SIP/2.0/UDP > 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060. > Record-Route: <sip:3.4.5.164;lr=on>. > From: "+13032223333" <sip:+13032223333@3.4.5.167>;tag=as1f559f5a. > To: <sip:+13031112222@2.3.4.40:5060>;tag=VPST506071629352. > Call-ID: 37ef92a26c31a7f85958ae996d49a872(a)3.4.5.167. > CSeq: 102 INVITE. > Contact: <sip:+13031112222@2.3.4.40:5060;transport=udp>. > Content-Length: 0. > . > > # > # should Kamailio send the ACK here? > # > > # Kamailio proxies the 486 to Asterisk > U 2011/05/19 14:13:03.240820 3.4.5.164:5060 -> 3.4.5.167:5060 > SIP/2.0 486 Busy Here. > Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport=5060. > Record-Route: <sip:3.4.5.164;lr=on>. > From: "+13032223333" <sip:+13032223333@3.4.5.167>;tag=as1f559f5a. > To: <sip:+13031112222@2.3.4.40:5060>;tag=VPST506071629352. > Call-ID: 37ef92a26c31a7f85958ae996d49a872(a)3.4.5.167. > CSeq: 102 INVITE. > Contact: <sip:+13031112222@2.3.4.40:5060;transport=udp>. > Content-Length: 0. > . > > > # ACK from Asterisk - should be swallowed by Kamailio > U 2011/05/19 14:13:03.243870 3.4.5.167:5060 -> 3.4.5.164:5060 > ACK sip:+13031112222@3.4.5.164 SIP/2.0. > Via: SIP/2.0/UDP 3.4.5.167:5060;branch=z9hG4bK3183c9de;rport. > From: "+13032223333" <sip:+13032223333@3.4.5.167>;tag=as1f559f5a. > To: <sip:+13031112222@3.4.5.164>;tag=VPST506071629352. > Contact: <sip:+13032223333@3.4.5.167>. > Call-ID: 37ef92a26c31a7f85958ae996d49a872(a)3.4.5.167. > CSeq: 102 ACK. > User-Agent: Asterisk. > Max-Forwards: 70. > Content-Length: 0. > . > > > ==== a bunch of retransmitted 486's chopped ============= > > > > > > > > On 05/19/2011 02:30 AM, Daniel-Constantin Mierla wrote: >> Hello, >> >> the ACK for non-2xx replies is hop-by-hop, meaning that kamailio will >> generate one when the reply is received, will send back the reply and >> when the ack comes from upstream, it will absorb it. >> >> In this case it seems that ack is not matching any invite transaction >> and thus is not known where to send it. >> >> Can you send the invite, reply and the ack requests taken with ngrep >> for such case? Maybe is something broken in the content of the message. >> >> Cheers, >> Daniel >> >> On 5/18/11 11:23 PM, Carl Wagner wrote: >>> Hi, >>> >>> I have Kamailio set up to act as a proxy and load balancer. Most >>> things are working correctly but for some reason I can't get >>> Kamailio to proxy an ACK to a 486 Busy. >>> I assume that it is something wrong that I have done in the >>> kamailio.cfg file but I am not seeing it. >>> >>> Does the t_check_trans() return false because the call state is Busy? >>> >>> Please let me know if you need other logs or information. >>> >>> Thanks in advance, >>> Carl >>> >>> >>> >>> ================== Call flow: (from ngrep) ====================== >>> >>> Asterisk Kamailio Provider >>> INVITE---------> >>> INVITE---------> >>> <----------100 Trying >>> <---------100 Trying >>> <----------486 Busy >>> <---------486 Busy >>> ACK-------------> >>> ====== Kamailio does not proxy the ACK here ======= >>> <----------486 Busy >>> <---------486 Busy >>> ACK-------------> >>> <----------486 Busy >>> <---------486 Busy >>> >>> >>> === kamailio.cfg snippet >>> ... >>> route >>> { >>> route(REQINIT); # remove malformed messages >>> >>> # handle requests within SIP dialogs >>> route(WITHINDLG); >>> ... >>> } >>> >>> ################################################################### >>> # Handle requests within SIP dialogs (request has a TO: Tag) >>> route[WITHINDLG] >>> { >>> if (has_totag()) >>> { >>> xlog("L_INFO", " WITHINDLG: SIP Request: [$rm] ruri=[$ru] (from >>> [$fu] to [$tu], Call-ID=[$ci], CSeq=[$cs])\n"); >>> if (loose_route()) >>> { >>> ... >>> } >>> else # not loose_route >>> { >>> if ( is_method("ACK") ) >>> { >>> if ( t_check_trans() ) # see if a message is related to >>> a transaction >>> { >>> ... >>> } >>> else >>> { >>> # ACK without matching transaction ... ignore and >>> discard >>> xlog("L_INFO", " WITHINDLG: has TO: tag AND loose_route is NOT true >>> and is_method = ACK and t_check_trans=FALSE\n"); >>> >>> # not forwarded here!!! Tried both t_relay and forward. >>> # $var(a) = t_relay(); >>> $var(a) = forward(); >>> xlog ("L_INFO", " WITHINDLG: (ReturnCode = [$var(a)] >>> exiting)\n"); >>> >>> exit; >>> } >>> } >>> sl_send_reply("404","Not here"); >>> } >>> exit; >>> } >>> } >>> >>> ============= End of kamailio.cfg ================ >>> >>> >>> ============= /var/log/messages - snippit of the message ========== >>> >>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: >>> ======== processing new message >>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: >>> MAIN: SIP Request: [ACK] ruri=[sip:+13031112222@2.3.4.5] (from >>> [sip:+13031112222@3.4.5.6] to [sip:+13031112222@2.3.4.5], >>> Call-ID=[21a30b9168e0a8c963d47ca1361cef77(a)3.4.5.6]) CSeq=[102] >>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: >>> WITHINDLG: SIP Request: [ACK] ruri=[sip:+13031112222@2.3.4.5] (from >>> [sip:+13031112222@3.4.5.6] to [sip:+13031112222@2.3.4.5], >>> Call-ID=[21a30b9168e0a8c963d47ca1361cef77(a)3.4.5.6], CSeq=[102]) >>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: >>> WITHINDLG: has TO: tag >>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: >>> WITHINDLG: has TO: tag AND loose_route is NOT true and is_method = >>> ACK and t_check_trans=FALSE >>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: >>> WITHINDLG: the ACK to a 486 was not being processed so I am >>> adding t_relay here >>> May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: >>> WITHINDLG: (ReturnCode = [1] exiting) >>> >>> >>> >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> Daniel-Constantin Mierla >> http://www.asipto.com > -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda

1 0

nonce reuse parameter
by Bruno Bresciani 20 May '11

20 May '11

Hi, on kamailio 3.1.2 the one_time_nonce parameter of the auth module is similar to the nonce_reuse parameter present on kamailio 1.5.0? I want to disable the check of the nonce reuse in kamailio 3.1.2... regards

2 2

Reactivating a failed dispatcher destination
by Lee Archer 20 May '11

20 May '11

Hi all I wonder if someone can help by pointing me in the right direction. I have dispatcher set to ping and set any failed gateways to probing but how do you get them out of this state when they start working again? I have run some tests and I must be missing something as active servers seem to stay in probing mode. I am using Kamailio 3.0.4. Thanks Lee

3 10

packaging 3.1.4
by Daniel-Constantin Mierla 20 May '11

20 May '11

Hello, I am thinking of packaging v3.1.4 next week on Thursday -- last minor release was more than 1.5month ago. Any comments against it? Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda

1 0

Forward on unanswered call
by Andrew O. Zhukov 20 May '11

20 May '11

Right now I'm try to add the subj feature. Linksys/SPA2102-3.3.6 (just from the box) respond SIP/2.0 480 Temporarily not available Landline over Asterisk with E1: SIP/2.0 603 Limit exceeded Ether I so unlucky, or just forget it and do not provide it to the customers? If so, notes to developers let's take off 408 code processing from sample config. Thanks in advance for your opinion. Andrew.

2 1

Via branch parameter in end2end ACK
by Francesco Castellano 19 May '11

19 May '11

Dear sirs, using version 3.1.3 (kamailio flavour), I noticed that the Via inserted by the proxy, relaying an end2end ACK, contains a branch parameter equal to 0 (with no magic cookie prefixed). No misbehaviour followed, but I was wonder about the reason for this behaviour and whether it can be a fault of my config: route { [some checks] if (!is_method("REGISTER|MESSAGE|PUBLISH")) { record_route(); } else if (is_method("REGISTER")) { route(HANDLE_REGISTER); exit; } if (loose_route()){ if (!has_totag()){ if (!is_method("ACK")){ send_reply("403", "Preset Route Set Not Allowed"); } exit; } t_check_trans(); if (is_method("ACK")){ if ($du == $null){ handle_ruri_alias(); } if (isflagset(T_UAC_NATED) && isflagset(T_UAC_USER)){ add_contact_alias(); } remove_hf("Proxy-Authorization"); t_relay(); exit; } } [other processing] } Here's an example for the forwarded ACK: U 2011/05/17 15:05:49.392201 proxy_1_ip:5060 -> location_callee_ip:5060 ACK sip:5303838@192.168.130.169;user=phone SIP/2.0. Record-Route: <sip:proxy_1_ip;lr=on;ftag=a2z0myc9r6>. Via: SIP/2.0/UDP proxy_1_ip;branch=0. Via: SIP/2.0/UDP proxy_0_ip;rport=5060;branch=0. Via: SIP/2.0/UDP 192.168.130.171:2048;received=location_caller_ip;branch=z9hG4bK-pud4cfiz8vsh;rport=4791. From: "cento tondo" <sip:100@proxy_0_hostname>;tag=a2z0myc9r6. To: <sip:5375485@proxy_1_hostname;user=phone>;tag=00221b79b1b28969. Call-ID: 3c352c0b8419-9tbq023tzfkp. CSeq: 2 ACK. Max-Forwards: 68. Contact: <sip:100@192.168.130.171:2048;alias=location_caller_ip~4791~1;line=gwwqwi25>;reg-id=1. Content-Length: 0. . where proxy_1 does force_rport and record_route() on ACK too, and proxy_0 does not. Both proxies run the same version, and a similar ACK script processing. Best regards, Francesco Castellano

3 5

ACK to 486 is not being proxied
by Carl Wagner 19 May '11

19 May '11

Hi, I have Kamailio set up to act as a proxy and load balancer. Most things are working correctly but for some reason I can't get Kamailio to proxy an ACK to a 486 Busy. I assume that it is something wrong that I have done in the kamailio.cfg file but I am not seeing it. Does the t_check_trans() return false because the call state is Busy? Please let me know if you need other logs or information. Thanks in advance, Carl ================== Call flow: (from ngrep) ====================== Asterisk Kamailio Provider INVITE---------> INVITE---------> <----------100 Trying <---------100 Trying <----------486 Busy <---------486 Busy ACK-------------> ====== Kamailio does not proxy the ACK here ======= <----------486 Busy <---------486 Busy ACK-------------> <----------486 Busy <---------486 Busy === kamailio.cfg snippet ... route { route(REQINIT); # remove malformed messages # handle requests within SIP dialogs route(WITHINDLG); ... } ################################################################### # Handle requests within SIP dialogs (request has a TO: Tag) route[WITHINDLG] { if (has_totag()) { xlog("L_INFO", " WITHINDLG: SIP Request: [$rm] ruri=[$ru] (from [$fu] to [$tu], Call-ID=[$ci], CSeq=[$cs])\n"); if (loose_route()) { ... } else # not loose_route { if ( is_method("ACK") ) { if ( t_check_trans() ) # see if a message is related to a transaction { ... } else { # ACK without matching transaction ... ignore and discard xlog("L_INFO", " WITHINDLG: has TO: tag AND loose_route is NOT true and is_method = ACK and t_check_trans=FALSE\n"); # not forwarded here!!! Tried both t_relay and forward. # $var(a) = t_relay(); $var(a) = forward(); xlog ("L_INFO", " WITHINDLG: (ReturnCode = [$var(a)] exiting)\n"); exit; } } sl_send_reply("404","Not here"); } exit; } } ============= End of kamailio.cfg ================ ============= /var/log/messages - snippit of the message ========== May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: ======== processing new message May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: MAIN: SIP Request: [ACK] ruri=[sip:+13031112222@2.3.4.5] (from [sip:+13031112222@3.4.5.6] to [sip:+13031112222@2.3.4.5], Call-ID=[21a30b9168e0a8c963d47ca1361cef77(a)3.4.5.6]) CSeq=[102] May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: WITHINDLG: SIP Request: [ACK] ruri=[sip:+13031112222@2.3.4.5] (from [sip:+13031112222@3.4.5.6] to [sip:+13031112222@2.3.4.5], Call-ID=[21a30b9168e0a8c963d47ca1361cef77(a)3.4.5.6], CSeq=[102]) May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: WITHINDLG: has TO: tag May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: WITHINDLG: has TO: tag AND loose_route is NOT true and is_method = ACK and t_check_trans=FALSE May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: WITHINDLG: the ACK to a 486 was not being processed so I am adding t_relay here May 18 11:21:05 kam0 /usr/sbin/kamailio[21282]: INFO: <script>: WITHINDLG: (ReturnCode = [1] exiting)

2 1

← Newer
1
...
5
6
7
8
9
10
11
12
13
Older →

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 May 2011