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 {
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
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.
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.comhttp://linkedin.com/in/miconda -- http://twitter.com/miconda
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
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
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.
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
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)
