Good day,
I’m experiencing some problems with our VoiP providers handling of REGISTER requests. We are using a Gigaset PRO N720 as UAC behind a Juniper SSG 140 with SIP-Alg enabled. This setup kind of works with UDP but our provider wants us to use TCP. With TCP enforced incoming calls don’t work. I’ve done some wire tracing and to me it seems that the providers configuration is to blame, but then - there are many RFCs out there and many NAT and UAC bug workarounds. Anyway, I wanted to get the opinion of “the" experts about how the requests send to the UAS SHOULD be correctly interpreted.
The REGISTER requests/responses look like this (outside of the firewall):
Protocol TCP!
client port 19091 <-> server port 5060
REGISTER sip:pbx.peoplefone.ch SIP/2.0
Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bKc1375589832468de63a719eac31156ec
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>
Call-ID: 2825358480@10_10_128_10
CSeq: 1 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>
Max-Forwards: 70
User-Agent: N720-DM-PRO/70.089.00.000.000
Expires: 180
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bKc1375589832468de63a719eac31156ec
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.b8fc
Call-ID: 2825358480@10_10_128_10
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy"
Server: kamailio (3.2.1 (x86_64/linux))
Content-Length: 0
REGISTER sip:pbx.peoplefone.ch SIP/2.0
Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>
Call-ID: 2825358480@10_10_128_10
CSeq: 2 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>
Authorization: Digest username="90780408050", realm="pbx.peoplefone.ch", uri="sip:pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy", response="764f371a08d258157a249f8d1b852514"
Max-Forwards: 70
User-Agent: N720-DM-PRO/70.089.00.000.000
Expires: 180
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.6bda
Call-ID: 2825358480@10_10_128_10
CSeq: 2 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>;q=0;expires=180;received="sip:212.126.160.92:19091;transport=TCP"
Server: kamailio (3.2.1 (x86_64/linux))
Content-Length: 0
The ip:port the firewall is sending those requests from is ip 212.126.160.92 port 19091. So this does NOT match the port from the Contact header. For TCP this seems rather logical to me, as one cant be listening on a TCP port and use it for sending at the same time. The UAC closes this “register connection” with TCP FIN after the register, and so does the firewall.
However unfortunately subsequent requests from the provider (ie UAS) come in on port 19091 (not port 6717 from the Contact header) and the firewall simply drops them.
Observations:
- the server does NOT include received=212.126.160.92 in the Via of the reponse. According to RFC3581 this is mandatory when rport is present in the request, so this is probably an error in the server.
- the server does include received="sip:212.126.160.92:19091;transport=TCP” in the Contact of the response. I didnt see this in any RFC (which means nothing;-) but it could be an error.
- after the client received the 200 OK it closes the TCP connection.
- the server tries several times to re-contact the client (incoming TCP SYN). However not on port 6717 (defined in the Contact header) but on port 19091 (where the REGISTER came from).
RFC3581 defines special behaviour when “rport” is defined in the request (i.e. response should go to the same port the request came from) - however it’s not so clear if this should apply to subsequent (INVITE/OPTIONS) requests from the server to the client. Those are strictly spoken not replies (or are they?).
RFC5626 defines that a “proxy” should keep track of the flows over which it received a registration and send requests over the same flow. It is not clear if RFC5626 should be applied. The RFC5626 defines that a UAC includes an “ob” parameter in the Contact field if it whishes further requests over the same flow. Also the RFC mandates a client to add a "reg-id=x" in the Contact field. Both are not the case here, so in short I think RFC5626 should NOT be applied. In which case conecting to the originating port (instead of the Contact port) would be a server error.
So in short and if I interpret the RFCs correctly, the client is reachable and should be contacted on
Transport: TCP
IP: 212.126.160.92
Port: 6717
If anyone who lives and breathes SIP could enlighten me if the UAS is right to call back on 19091 instead of 6717 I would really appreciate it;-))
Best regards,
Joachim
Hi,
What would be the best way to generate and send an INVITE message generated by the Kamailio server. This would be for a new dialog session, UAS initiated (e.g. to make a click 2 call like service).
I've tried the $uac_req(method)="INVITE"; uac_req_send(); but didn't work. I gather something would be needed first to open the dialogue before doing it but couldn't find it on the dialogue module.
Thanks,
Joao Alves
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Hello,
I have configured kamailio 4.0.4 long back. Now, I wanted to enable the
usage of port 5061 with TLS. By doing so, the client(video camera) can
place outgoing calls fine. But while receiving an incoming call, the
message does not get sent out to the other client. Hence, the call fails. I
can place and receive calls on port 5060 successfully without any issues.
Can anyone please tell me why port 5061 is giving me a problem.
Also, as a test, I set up kamailio on another machine(version 4.1) and 5061
works fine in all directions. It's only on the other machine that I have
problems with.
Appreciate any help!
Thank you,
Ankhit
Hi Daniel and others,
I'm having a problem with acc module if I'm using the event_route/
branch-failure:
say, the call comes from the app server and goes to the registered user.
We arm the the failure route and per-branch failure route for the 302
redirect from the UA. We explicitly reset the accounting flags because
we don't want to account the calls from the app server. The transaction
is created implicitly by the t_relay().
Now if the UA responds with the 302 response and we are going to process
that, we want to create an acc record for the new target from 302
message because this call may incur additional costs. I'm setting the
accounting flags and calling t_flush_flags() but that doesn't work (no
accounting record). Any idea if I'm doing something wrong or maybe
there's a bug when changing the flags and then calling t_flush_flags
from the event_route?
Here are the module parameters:
modparam("acc", "early_media", 0)
modparam("acc", "report_ack", 0)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 1)
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "db_url", PAIR_URL)
modparam("acc", "db_extra",
"src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd")
modparam("acc", "multi_leg_info", "src_leg=$avp(i:901);dst_leg=$avp(i:902)")
modparam("acc", "time_mode", 2)
modparam("acc", "time_attr", "time_hires")
modparam("acc", "cdr_log_enable", 0)
FTR, we tried 4.1.6 and 4.1.8.
And here is the event route (with flags defined like this:
flags FLAG_ACC_DB:1, FLAG_ACC_MISSED:2, FLAG_ACC_FAILED:3, ...):
event_route[tm:branch-failure:redirect]
{
route(ROUTE_STOP_RTPPROXY_BRANCH);
if($T_rpl($rs) == 301 || $T_rpl($rs) == 302)
{
# initialise variables when entering failure route
route(ROUTE_INITVARS);
# these need to be avps because we need it in reply/failure-route
$(avp(s:from_faxserver)[*]) = 0;
$(avp(s:to_faxserver)[*]) = 0;
$(avp(s:cf_from_pstn)[*]) = 0;
$(avp(s:from_pstn)[*]) = 0;
$(avp(s:proxylu_from_pstn)[*]) = 0;
$(avp(s:lcr_flags)[*]) = 0;
$(avp(s:em_call)[*]) = 0;
$(avp(s:from_pbx)[*]) = 0;
$(avp(s:p_to_device)[*]) = 0;
$(avp(s:p_to_group)[*]) = 0;
$(avp(s:is_primary)[*]) = 0;
# now let's process a 30x
$(avp(s:acc_state)[*]) = "cfb";
$(avp(s:orig_acc_caller_user)[*]) = $avp(s:acc_caller_user);
$(avp(s:orig_acc_caller_domain)[*]) = $avp(s:acc_caller_domain);
$(avp(s:acc_caller_user)[*]) = $avp(s:acc_callee_user);
$(avp(s:acc_caller_domain)[*]) = $avp(s:acc_callee_domain);
$(avp(s:caller_uuid)[*]) = $avp(s:callee_uuid);
$(avp(s:callee_uuid)[*]) = $null;
# the $var(no_acc) is 0 at this point but the flags may have
been reset
# if this is a call from PBX user - we do want accounting for
the 302 redirect
if(isflagset(FLAG_ACC_DB)) {
xlog("L_NOTICE", "++++++ ACC flag is set - [% logreq -%]\n");
} else {
xlog("L_NOTICE", "------ ACC flag is NOT set - [% logreq
-%]\n");
}
setflag(FLAG_ACC_FAILED);
setflag(FLAG_ACC_DB);
t_flush_flags();
# get last URI from destination-set and set it as R-URI
$var(contact) = $T_rpl($ct);
$var(contact) = $(var(contact){nameaddr.uri});
if($var(contact) == 0 || $var(contact) == $null)
{
xlog("L_ERROR", "Failed to fetch contact '$ct' from 301/302
- [% logreq -%]\n");
acc_db_request("480", "acc");
$var(announce_handle) = "callee_tmp_unavailable";
$var(announce_set) = $xavp(callee_real_prefs[0]=>sound_set);
$(avp(s:announce_code)[*]) = 480;
$(avp(s:announce_reason)[*]) = "Temporarily Unavailable";
route(ROUTE_EARLY_REJECT);
}
$ru = $var(contact);
xlog("L_NOTICE", "Redirect from UAC intercepted - [% logreq -%]\n");
$(avp(s:forwarder_cli_userprov)[*]) = $T_rpl($tU);
$(avp(s:forwarder_domain_userprov)[*]) = $T_rpl($td);
$var(forward) = 1;
$var(redirected_forward) = 1;
route(ROUTE_LOAD_CALLER_PREF);
route(ROUTE_FIND_CALLEE);
}
}
Thanks.
Andrew
Hello all,
Just wondering if anyone know any tutorial on setting up HA+DRBD solution for kamailio.
Especially creating partitions, DRBD devices and mount points.
Thanks in advance,
-Sid
"May the light be with you." ______________________________________________
Siddhardha Garige
www.luminepixels.com
I'm using allow_address function of the permissions module and I'm seeing
strange behavior with network masks not divisible by 8. I have 172.16.0.0/12
in my address table and Kamailio is marking packets from 172.56.16.232 as
being part of that local subnet. If I change the subnet to 172.16.0.0/16, I
no longer have an issue.
I know there was a bug several years ago related to this (
http://git.kamailio.org/gitlist/index.php/sip-router/commit/0ead7ab31bf0df6…),
but that code is very different, so I'm wondering if a regression has crept
in? I'm using Kam 4.1.6.
Thanks,
Kyle
--
*Kyle Kurz*
Digium, Inc. · Senior Software Engineer
9115 Brown Deer Rd · San Diego, CA 92121 · US
direct +1 858.537.1166
Check us out at: http://digium.com · http://asterisk.org
<http://www.asterisk.org/>
Hello everybody,
My SIP vendor request me to replace FROM before sending the traffic. In
order to achieve this I use uac_replace_from.
UAC module is setup in restore_mode = auto.
In my insfrastructure I have an Asterisk and then a Kamailio that connects
to vendor via internet.
Softphone -> Asterisk -> Kamailio -> Internet -> SIP vendor
If caller ID is setup in Asterisk using CALLERID(num)=34888888888 and then
INVITE is forwarded to Kamailio, the call is established and finished
correctly but the URI in TO field in BYE request from Kamailio to Asterisk
contains garbage. In the scenario the callee hangs up the call.
Example of TO Field with garbage: 34888888888 <sip:50026896@no{soy,ns^^>
What I do see is that the number "50026896" that is part of the URI is the
same I use in:
uac_replace_from("50026896", "sip:50026896@sip.vendor.es");
Something else that I have found is that vsf field is the same in the
INVITE and in the BYE.
----------------------------------------------------------------------------------------------------------------
2015/06/23 17:48:38.552442 192.168.0.2:5060 -> 192.168.0.1:5060
BYE sip:34888888888@192.168.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.0.2;branch=z9hG4bKfb49.73c6517609cdb6f7ec00b1f40a05dbe9.0
Via: SIP/2.0/UDP
8.8.8.8.8;rport=5060;branch=z9hG4bKfcdf.3767c59c2d0e3d8ab695669845ce4cea.0
branch=z9hG4bK04boo6104o5hcso0c2a1sd0000g00.1
Call-ID: 4bf8effb45b0ae8e049366297924cbba@192.168.0.1:5060
From: <sip:28999999999@192.168.0.2;tag=k0eci3x3-CC-30
To: 34888888888 <sip:50026896@no{soy,ns^^>;tag=as041b7d84
CSeq: 1 BYE
Reason: Q.850;cause=16;text="normal call clearing"
Max-Forwards: 67
Content-Length: 0
------------------------------------------------------------------------------------------------------------------
DEBUG: uac [replace.c:525]: restore_uri(): getting 'vsf' Route param
DEBUG: uac [replace.c:533]: restore_uri(): route param is
'AAAAAAEECQkCAgsNAXBeL0NGQUsfVl02Ni44Mw--' (len=40)
DEBUG: uac [replace.c:607]: restore_uri(): decoded uris are:
new=[sip:50026896@no{soy,ns#005#007] old=[sip:34888888888@8.8.8.8]
DEBUG: uac [replace.c:525]: restore_uri(): getting 'vst' Route param
DEBUG: uac [replace.c:533]: restore_uri(): route param is
'AAAAAAQPAw8MDgsAAHZBKRVdAhoVHQ4XH1BdYWJhbnRlLmVz' (len=48)
DEBUG: uac [replace.c:607]: restore_uri(): decoded uris are: new=[
sip:28999999999@192.168.0.1] old=[sip:999999999@sip.vendor.es]
-----------------------------------------------------------------------------------------------------------------------------------
At my confiig I have route like this
onreply_route[REPLY_FROM_WS] {
if(status=~"[12][0-9][0-9]") {
xlog("L_INFO", "Manage_Reply from webrtc client {$si:$sp} for method {$rm}:
$rs");
rtpengine_manage("force trust-address replace-origin
replace-session-connection DTLS=passive ICE=remove RTP/AVP");
route(NATMANAGE);
}
}
This route successfully handling replies 180 183 and 200 and then (after
natmanage route) resend to mediaserver.
When callee client reject call it send 480 ot 486 message that not
resended by kamailio nowhere.
First of all I thought that 480 and 486 replies are failure replies but at
log I see its at onreply route.
So Ok . I added this to onreply_route
if (status=~"48[06]"){
xlog("L_INFO", "Manage_Reply from webrtc client {$si:$sp} for method {$rm}:
$rs");
rtpengine_manage("force trust-address replace-origin
replace-session-connection DTLS=passive ICE=remove RTP/AVP");
route(NATMANAGE);
}
But message just going through natmanage route and goes nowhere
My NATMANAGE route is
xlog("L_INFO","NATMANAGE reply {$rm}");
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
add_contact_alias();
}
xlog("L_INFO","reply {$rm}");
}
I see at my log only first NATMANAGE xlog... no more...
thnks for answer
Hi,
Lasting night i was doing some tests and identified a strange behavior from
dialog module. I am using Kamailio v4.3.0 rev. c6aa95.
I basically wanted to identify if an incoming sequential ACK (from caller
for an answered call) or a BYE (from callee who wants to hangup the call)
belong to an existing dialog.
First I tried to use dialog profiles as they were already enabled in my
kamailio.cfg for every call. Calling the function "is_in_profile" after
loose_route in WITHINDLG route, does not works for ACK, but works for BYE.
Then I added dialog flags to initial INVITE (using function "dlg_setflag")
and check them for ACK and BYE after loose_route (using "dlg_isflagset"
method), i have the same behavior. They worked/matched only for BYE, not
for ACK.
Lastly I set dialog variables (e.g. dlg_var(my_call) = "1") in initial
INVITE and checked for them for ACK and BYE requests after loose_route.
Only they worked perfectly, i.e. i can match them for both incoming ACK and
BYE requests.
Is this correct and expected behavior? Why dialog profile and flags do not
match for a dialog in unconfirmed state (i.e. ACK from caller after
successful call answer)? They only work for confirmed dialogs (e.g. BYE
from callee).On the other hand, dialog variables seems to work everywhere
(i.e. all sequential requests).
Thank you.
