Hi,
registrar at iptel.org (0.10.99-iptelorg/tekelec-SOPv2) and ser 0.9.6 as
well do not return a contact header in 200 response to REGISTER (see
trace below), but in rfc (10.3) I read it's a MUST
8. The registrar returns a 200 (OK) response. The response MUST
contain Contact header field values enumerating all current
bindings. Each Contact value MUST feature an "expires"
parameter indicating its expiration interval chosen by the
registrar. The response SHOULD include a Date header field.
Am I missing something (apart from the contact header) or is my register
message not correct?
Stefan
U 192.168.5.101:5070 -> 213.192.59.75:5060
REGISTER sip:iptel.org SIP/2.0.
Via: SIP/2.0/UDP 192.168.5.101:5070;branch=z9hG4bK15f6.4d8faeb.0.
To: Stefan <sip:sayer@iptel.org>.
From: Stefan <sip:sayer@iptel.org>;tag=0E520893-456AF6AD0009055B-B7963B90.
CSeq: 10 REGISTER.
Call-ID: 0D1543AB-456AF6AD00090738-B7C66B90(a)192.168.5.101.
Content-Length: 0.
User-Agent: Sip EXpress router(0.9.6-sems (i386/linux)).
Contact: <sip:sayer@192.168.5.101:5070>.
Expires: 0.
.
#
U 213.192.59.75:5060 -> 192.168.5.101:5070
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP
192.168.10.144:5070;rport=5070;received=91.64.139.240;branch=z9hG4bK15f6.4d8faeb.0.
To: Stefan <sip:sayer@iptel.org>;tag=17da4c1f77cf571798ae2c71e6d4b5c0.4003.
From: Stefan <sip:sayer@iptel.org>;tag=0E520893-456AF6AD0009055B-B7963B90.
CSeq: 10 REGISTER.
Call-ID: 0D1543AB-456AF6AD00090738-B7C66B90(a)192.168.5.101.
P-Nat: Yes.
WWW-Authenticate: Digest realm="iptel.org",
nonce="456af887c3eac5c30c87bab4268389ee5e796372".
Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)).
Content-Length: 0.
Warning: 392 213.192.59.77:5070 "Noisy feedback tells: pid=4141
req_src_ip=213.192.59.75 req_src_port=5060 in_uri=sip:iptel.orgout_uri=sip:iptel.org via_cnt==2".
.
#
U 192.168.5.101:5070 -> 213.192.59.75:5060
REGISTER sip:iptel.org SIP/2.0.
Via: SIP/2.0/UDP 192.168.5.101:5070;branch=z9hG4bK25f6.dae56b14.0.
To: Stefan <sip:sayer@iptel.org>.
From: Stefan <sip:sayer@iptel.org>;tag=0E520893-456AF6AD0009055B-B7963B90.
CSeq: 11 REGISTER.
Call-ID: 0D1543AB-456AF6AD00090738-B7C66B90(a)192.168.5.101.
Content-Length: 0.
User-Agent: Sip EXpress router(0.9.6-sems (i386/linux)).
Contact: <sip:sayer@192.168.5.101:5070>.
Expires: 0.
Authorization: Digest username="sayer", realm="iptel.org",
nonce="456af887c3eac5c30c87bab4268389ee5e796372", uri="sip:iptel.org",
response="880ff39073b5eeb3cda68352b78de368", algorithm="MD5".
.
#
U 213.192.59.75:5060 -> 192.168.5.101:5070
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.5.101:5070;rport=5070;received=91.64.139.240;branch=z9hG4bK25f6.dae56b14.0.
To: Stefan <sip:sayer@iptel.org>;tag=17da4c1f77cf571798ae2c71e6d4b5c0.4003.
From: Stefan <sip:sayer@iptel.org>;tag=0E520893-456AF6AD0009055B-B7963B90.
CSeq: 11 REGISTER.
Call-ID: 0D1543AB-456AF6AD00090738-B7C66B90(a)192.168.5.101.
P-Nat: Yes.
Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)).
Content-Length: 0.
Warning: 392 213.192.59.77:5070 "Noisy feedback tells: pid=4140
req_src_ip=213.192.59.75 req_src_port=5060 in_uri=sip:iptel.orgout_uri=sip:iptel.org via_cnt==2".
.
--
Stefan Sayer
Media Services Development
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
stefan.sayer(a)iptego.de
www.iptego.de
Hello,
I tried to use avp_subst to extract the part <......> of a Remote-Party-ID
$avp(s:merker)= Remote-Party-ID:
"test"<sip:12345@localhost>;party=calling;id-type=subscriber;screen=yes;privacy=full
avp_subst("$avp(s:merker)/$avp(s:merker1)", "/(.*)>(.*)/\1>/");
the result for merker1 is Remote-Party-ID: "test"<sip:12345@localhost>
what must I change in the re to get this result? <sip:12345@localhost>
thanks in advance,
Andreas
Ricardo -
this is an Asterisk issue.
Configure your SIP.conf in * creating a sip peer with insecure=very fotr the
SER peer, like this:
[ser-peer]
type = friend ; should you want to receive and make calls
to SER
context=from-ser ; the context in dialplan with extensions
allowed to be accessed by SER. Here you must have PSTN extensions
capability.
host=200.XXX.XXX.XXX ; the IP address for SER
fromdomain=domain.com ;the Domain part of uri to be verified by asterisk on
the INVITE received by SER.
qualify= yes ; just to check the latency between SER
and Asterisk (like this, if over 2000ms Ast will report as unavailable
peer).
disallow=all
allow=alaw
allow=g729
insecure= very ; this line garantees that any username part
of Request URI sent by SER in INVITE to Asterisk will be accepted by Ast and
routed to the dialplan.
So, if SER send an INVITE to HYPERLINK
"mailto:5531332818847@domain.com.br"5531332818847(a)domain.com.br , Asterisk
will look for a section of type =user in SIP conf to match the user part
first, it won't find, then it will look for a type=peer. It will find and
try to match the IP address as in host= ...line and will accept any username
part as per insecure=very line. Then, if context=from-ser in the Ast
dialplan allows this dialing string (553132818847), it will proceed from
there.
Hope it helps.
At.
Walter
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.430 / Virus Database: 268.14.16/552 - Release Date: 26/11/2006
11:30
Hi,
I am working on a project which involves testing SER with some dummy clients.
I have downloaded and installed OpenSER. I am using the very basic Hello.cfg configuration file available online.
I find that when SER gets a INVITE request from the caller, it does not deliver it properly to the client (callee). Some debugging revealed that it relays the request to port 5060 at the client rather than the one which was registered by the callee earlier. I tried to look at the source code of SER and found that the callee's contact information never seem to be looked up at any stage.
Is this due to some missing information in my configuration file?
Any feedback would be appreciated.
Thank you
-Kaushik
PS: I have attached (inline) the configuration file
ser.cfg
------------------------------------
debug=9
fork=yes
log_stderror=yes
listen=128.42.3.3
port=5060
children=4
check_via=no # added
dns=no
rev_dns=no
fifo="/tmp/ser_fifo"
loadmodule "/scratch/ser-0.9.7-pre1/modules/sl/sl.so" # Stateless replies
loadmodule "/scratch/ser-0.9.7-pre1/modules/tm/tm.so" # Transaction management
loadmodule "/scratch/ser-0.9.7-pre1/modules/rr/rr.so" # Routing and record-routing
loadmodule "/scratch/ser-0.9.7-pre1/modules/maxfwd/maxfwd.so" # Max fowards check
loadmodule "/scratch/ser-0.9.7-pre1/modules/usrloc/usrloc.so" # User location support
loadmodule "/scratch/ser-0.9.7-pre1/modules/registrar/registrar.so" # Registrar (requires userloc and sl)
loadmodule "/scratch/ser-0.9.7-pre1/modules/textops/textops.so" # Message textual operations
modparam("usrloc", "db_mode", 0) # 0 forces registration data to be stored in memory
modparam("rr", "enable_full_lr", 1)
route {
# ------------------------------------------------------------------------
# Sanity Check Section
# ------------------------------------------------------------------------
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483", "Too Many Hops");
break;
};
if (msg:len > max_len) {
sl_send_reply("513", "Message Overflow");
break;
};
# ------------------------------------------------------------------------
# Record Route Section
# ------------------------------------------------------------------------
if (method!="REGISTER") {
record_route();
};
# ------------------------------------------------------------------------
# Loose Route Section
# ------------------------------------------------------------------------
if (loose_route()) {
append_hf("P-hint: rr-enforced\r\n");
route(1);
break;
};
# ------------------------------------------------------------------------
# Call Type Processing Section
# ------------------------------------------------------------------------
if (uri!=myself) {
append_hf("P-hint: outbound\r\n");
route(1);
break;
};
if (method=="ACK") {
route(1);
break;
} else if (method=="REGISTER") {
route(2);
break;
};
lookup("aliases");
if (uri!=myself) {
append_hf("P-hint: outbound alias\r\n");
route(1);
break;
};
if (!lookup("location")) {
sl_send_reply("404", "User Not Found");
break;
};
append_hf("P-hint: userloc applied\r\n");
route(1);
}
route[1] {
# ------------------------------------------------------------------------
# Default Message Handler
# ------------------------------------------------------------------------
if (!t_relay()) {
log(2, "Failed t_relay");
sl_reply_error();
};
}
route[2] {
# ------------------------------------------------------------------------
# REGISTER Message Handler
# ------------------------------------------------------------------------
if (!save("location")) {
sl_reply_error();
};
}
Hi all,
What sort of if structure can I use to test the Calling ID ?
(ie : my calling id are member of subscriber table).
For the moment I do something like this : "if(uri=~"^sip:119@") {" for
the destination number, but I want to do the same for the calling ID.
Thanks for your help.
Best regards
Dear all,
I already know that there is a “remove_hf_f” function in the textops
module.
I can use this function to remove sip header fields which are supported
by SER such as “From”, “To”, and “Expires” header fields, but it can’t
remove sip header fields which are not support by SER such as
“SIP-If-Match” and “SIP-ETag”.
When I use “sl_send_reply” function to build and send sip response, this
response contains some sip headers field which I don’t like.
How can I remove unnecessary header fields?
Thanks a lot,
Ren-Huang Liou
Does anybody have an example about how to use credentials to permit some
kinds of calls to some users on SER?
I tried this but, it stops work with no cause:
if (uri=~"^sip:0800.*@.*") {
if(!is_user_in("credentials", "0800")) {
sl_send_reply("403", "No 0800");
log(1,"No 0800");
break;
};
consume_credentials();
prefix ("5511");
route(8);
break;
};
Thanks,
Daniel
Hi,
I'm deploying a SER + Asterisk architecture, where SER is used as SIP
registrar, and Asterisk is used for voicemail and PSTN gateway.
This system is already able to make Call Transfers (Blind and Attended)
internally between phones registered in SER, although, I can't make
Call Transfers in some scenarios involving PSTN numbers (which need to
pass through Asterisk).
The problem is that when the REFER message (that carries the Refer-To
number to whom the call should be transferred) gets to Asterisk, it
replies with a 404 Not Found message, and the Call Transfer isn't
established!
Any ideas on how can I solve this problem?
Thanks in advance,
Ricardo.
Hi all,
i have a ser setup (CentOS 4.4/ser 0.9.6) with several ip phones
(SNOM320 and Xlite30) and every thing seems to work fine. The ser
server has a public ip address 89.xxx.xxx.xxx and the ua are behind a
NAT device (corporate FW).
I want now to add some OptiPoint420 SIP but was unable to get them
working. That means that the registration is ok and calls to the
Optipoints from other ua (xlite or Snom) work but i was unable to
place a call from Optipoint to other ua.
In the trace you can notice that the INVITE is sent to ser with Src
Port 38625 and Dst Port 5060. But the response from ser is sent to Src
Port: 5060 (5060), Dst Port: 5060 (5060). The result is of couse ICMP
Destination unreachable (Port unreachable).
I have rtp proxy and ser running on the same server and my ser.cfg
looks like the one from the SER GettingStarted
http://siprouter.onsip.org/doc/gettingstarted/ch08s02.html). I read
the doc about "handling of NAT using RTP Proxy" but was unable to
change the config to get this scenario with OptiPoint working. Has
anyone managed to get OptiPoint to work with ser?
thx in advance?
No. Time Source Destination Protocol Info
14 8.907171 89.xxx.xxx.xxx 89.xxx.xxx.xxx
SIP/SDP Request: INVITE
sip:8001@registrar.mydomaine.com;transport=udp, with session
description
Frame 14 (972 bytes on wire, 972 bytes captured)
Ethernet II, Src: AminoCom_02:02:02 (00:02:02:02:02:02), Dst:
AcerTech_9c:00:8d (00:00:e2:9c:00:8d)
Internet Protocol, Src: 89.xxx.xxx.xxx (89.xxx.xxx.xxx), Dst:
89.xxx.xxx.xxx (89.xxx.xxx.xxx)
User Datagram Protocol, Src Port: 38625 (38625), Dst Port: 5060 (5060)
Session Initiation Protocol
No. Time Source Destination Protocol Info
15 8.907394 89.xxx.xxx.xxx 89.xxx.xxx.xxx SIP
Status: 407 Proxy Authentication Required
Frame 15 (772 bytes on wire, 772 bytes captured)
Ethernet II, Src: AcerTech_9c:00:8d (00:00:e2:9c:00:8d), Dst:
AminoCom_02:02:02 (00:02:02:02:02:02)
Internet Protocol, Src: 89.xxx.xxx.xxx (89.xxx.xxx.xxx), Dst:
89.xxx.xxx.xxx (89.xxx.xxx.xxx)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol