[Serusers] SER SDP Port Problem??

Greger V. Teigre greger at teigre.com
Mon Feb 21 16:51:16 CET 2005


If you have the latest cvs version, you can use "19" (add test=16). It may 
make a difference if you have configured your UA with stun.  If not, "3" 
should be good.
Use some sort of stun client implementation to test your nat.
http://sourceforge.net/project/showfiles.php?group_id=47735&package_id=102146

rtpproxy is rather silent.  :-( You should do a tcpdump port control_port to 
see if any traffic is going.
Also, you can do netstat -nlp to see if any udp ports are allocated once you 
believe a call is proxied.
g-)

Aisling O'Driscoll wrote:
> Hi Greger,
>
> I only use nat_uac_test("3") as that is what is given in most
> examples on the mailing list. Is there any way that i can test if I
> am behind symmetric nat? I have rtpproxy running with ser but not
> sure if my below ser.cfg script invokes it correctly. Do you know
> where I could find the rtpproxy debug log?
>
> Thanks again,
> Aisling.
>
> ---- Original Message ----
> From: greger at teigre.com
> To: ashling.odriscoll at cit.ie, serusers at lists.iptel.org
> Subject: Re: [Serusers] SER SDP Port Problem??
> Date: Mon, 21 Feb 2005 12:11:15 +0100
>
>> Aisling,
>> The port is in the m= line. You use nat_uac_test("3"). Any particular
>> reason
>> for not using all tests?
>> Please note that sdp rewriting does not work if the UA is behind a
>> symmetric
>> NAT and you are calling in. You must then via an RTP proxy like
>> mediaproxy
>> or rtpproxy.
>> g-)
>>
>> Aisling O'Driscoll wrote:
>>> Hi,
>>>
>>> I understand the basic problem behind one way audio is that the
>>> client behind nat has a private address in the sdp information,
>>> therefore the voice cannot be delivered to this private address. It
>>> is necessary to rewrite this sdp info with the nat public address.
>>> However I have done this in my ser.cfg and I still have one way
>>> voice.
>>>
>>> I have included some of relevant ethereal messages on SER and my
>>> ser.cfg below. The messages show that the rtp information has been
>>> changed. Does anyone think the problem is because there is no port
>>> information in the "c" and "o" fields in the sdp?? If so how can I
>>> make sure the port is included?
>>>
>>> Many Thanks,
>>> Aisling.
>>>
>>> Ethereal messages:
>>>
>>> call between private client with public nat address 63.218.54.71
>> and
>>> a public client with address 157.190.183.80. The SER address is
>>> 157.190.183.70.
>>>
>>> REGISTER sip:157.190.183.70 SIP/2.0
>>> VIA: SIP/2.0/UDP 63.218.54.71:11987;rport;branch=z9h.....
>>> FROM: whoever <sip:2008 at 157.190.183.70>;tag=455....
>>> TO: whoever <sip:2008 at 157.190.183.70>
>>> CONTACT: "whoever" <sip:2008 at 63.218.54.71:11987>
>>> Call-Id: ....
>>> CSeq: 22227 REGISTER
>>> Expires; 1800
>>> User Agent: X-Lite release 1103m
>>> Content-Length: 0
>>>
>>> SIP/2.0 200 OK
>>> VIA: SIP/2.0/UDP 63.218.54.71:11987;rport;branch=z9h.....
>>> FROM: whoever <sip:2008 at 157.190.183.70>;tag=455....
>>> TO: whoever <sip:2008 at 157.190.183.70>
>>> CONTACT: "whoever" <sip:2008 at 63.218.54.71:11987>;q=0.00
>> expires=1800
>>> Call-Id: ....
>>> CSeq: 22227 REGISTER
>>> Expires; 1800
>>> User Agent: X-Lite release 1103m
>>> Content-Length: 0
>>>
>>> The public client (157.190.183.80 also registers)
>>>
>>> Then the private client invites the public client to a voice
>>> conversation:
>>>
>>> INVITE sip:2001 at 157.190.183.70 SIP/2.0
>>> VIA: SIP/2.0/UDP 63.218.54.71:11987;rport;branch=z9h.....
>>> FROM: whoever <sip:2008 at 157.190.183.70>;tag=455....
>>> TO: whoever <sip:2001 at 157.190.183.70>
>>> CONTACT: "whoever" <sip:2008 at 63.218.54.71:11987>
>>> Call-Id: ....
>>> CSeq: 19929 INVITE
>>> Expires; 1800
>>> User Agent: X-Lite release 1103m
>>> Content-Type=application/sdp
>>> Content-Length: 290
>>>
>>>   Session description Protocol
>>>   Owner/Creator of the Session (o): 2008 245812 272828 IN IP4
>>> 63.218.54.71
>>>   Connection information (c): IN IP4 63.218.54.71
>>>
>>> A 100 Trying is sent back from SER to the private client (i.e.
>> caller)
>>>
>>> The INVITE is forwarded from SER to public client (callee) as show
>>> below:
>>>
>>> INVITE sip:2001 at 157.190.183.70 SIP/2.0
>>> VIA: SIP/2.0/UDP 157.190.183.70;branch=....
>>> VIA: SIP/2.0/UDP 63.218.54.71:11987;branch=z9h.....
>>> FROM: whoever <sip:2008 at 157.190.183.70>;tag=455....
>>> TO: whoever <sip:2001 at 157.190.183.70>
>>> CONTACT: "whoever" <sip:2008 at 63.218.54.71:11987>
>>> Call-Id: ....
>>> CSeq: 19929 INVITE
>>> Expires; 1800
>>> User Agent: X-Lite release 1103m
>>> Content-Type=application/sdp
>>> Content-Length: 290
>>>
>>>   Session description Protocol
>>>   Owner/Creator of the Session (o): 2008 245812 272828 IN IP4
>>> 63.218.54.71
>>>   Connection information (c): IN IP4 63.218.54.71
>>>
>>> 157.190.183.80 157.190.183.70 SIP 100 Trying
>>> 157.190.183.80 157.190.183.70 SIP 180 Ringing
>>> 157.190.183.70 63.218.54.71 SIP 180 Ringing
>>>
>>> 157.190.183.80 157.190.183.70 SIP/SDP Status: 200OK
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP 157.190.183.70;branch=....
>>> Via: SIP/2.0/UDP 63.218.54.71:11987;rport=11987;branch=.....
>>> From: whoever<sip:2008 at 157.190.183.70>;tag=...
>>> To: <sip:2001 at 157.190.183.70>;tag=....
>>> CSeq: 19929 INVITE
>>> User Agent: Grandtsream BT100 1.0.5.18
>>> Contact: <sip:2001 at 157.190.183.80>
>>>
>>>    Session description protocol
>>>    (c) IN IP4 157.190.183.80
>>>
>>>
>>> #
>>> # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
>>> #
>>> # simple quick-start config script
>>> #
>>>
>>> # ----------- global configuration parameters
>> ------------------------
>>>
>>> #debug=3         # debug level (cmd line: -dddddddddd)
>>> #fork=yes
>>> #log_stderror=no # (cmd line: -E)
>>>
>>> /* Uncomment these lines to enter debugging mode
>>> debug=7
>>> fork=no
>>> log_stderror=yes
>>> */
>>>
>>> check_via=no # (cmd. line: -v)
>>> dns=no           # (cmd. line: -r)
>>> rev_dns=no      # (cmd. line: -R)
>>> #port=5060
>>> #children=4
>>> fifo="/tmp/ser_fifo"
>>>
>>> alias="157.190.183.70:5060"
>>>
>>> # ------------------ module loading
>> ----------------------------------
>>>
>>> # Uncomment this if you want to use SQL database
>>> loadmodule "/usr/lib/ser/modules/mysql.so"
>>>
>>> loadmodule "/usr/lib/ser/modules/sl.so"
>>> loadmodule "/usr/lib/ser/modules/tm.so"
>>> loadmodule "/usr/lib/ser/modules/rr.so"
>>> loadmodule "/usr/lib/ser/modules/maxfwd.so"
>>> loadmodule "/usr/lib/ser/modules/usrloc.so"
>>> loadmodule "/usr/lib/ser/modules/registrar.so"
>>> loadmodule "/usr/lib/ser/modules/textops.so"
>>> loadmodule "/usr/lib/ser/modules/nathelper.so"
>>>
>>> # Uncomment this if you want digest authentication
>>> # mysql.so must be loaded !
>>> loadmodule "/usr/lib/ser/modules/auth.so"
>>> loadmodule "/usr/lib/ser/modules/auth_db.so"
>>>
>>> # ----------------- setting module-specific parameters
>> ---------------
>>>
>>> # -- usrloc params --
>>>
>>> #modparam("usrloc", "db_mode",   0)
>>>
>>> # Uncomment this if you want to use SQL database
>>> # for persistent storage and comment the previous line
>>> modparam("usrloc", "db_mode", 2)
>>>
>>> # -- auth params --
>>> # Uncomment if you are using auth module
>>> #
>>> #modparam("auth_db", "calculate_ha1", yes)
>>> #
>>> # If you set "calculate_ha1" parameter to yes (which true in this
>>> config),
>>> # uncomment also the following parameter)
>>> #
>>> #modparam("auth_db", "password_column", "password")
>>>
>>> # -- rr params --
>>> # add value to ;lr param to make some broken UAs happy
>>> #NB Had to up this value from 1 to 11 because reinvites were
>>> bombarding called phone
>>> modparam("rr", "enable_full_lr", 11)
>>>
>>> #!! Nathelper
>>> modparam("registrar", "nat_flag", 6)
>>> modparam("nathelper", "natping_interval", 30) #Ping interval 30 s
>>> modparam("nathelper", "ping_nated_only", 1)   #Ping only clients
>>> behind NAT
>>>
>>> modparam("tm", "fr_inv_timer", 80)
>>>
>>> # -------------------------  request routing logic
>> -------------------
>>>
>>> # main routing logic
>>>
>>> route{
>>>
>>> # initial sanity checks -- messages with
>>> # max_forwards==0, or excessively long requests
>>> if (!mf_process_maxfwd_header("10")) {
>>> sl_send_reply("483","Too Many Hops");
>>> break;
>>> };
>>> if ( msg:len > max_len ) {
>>> sl_send_reply("513", "Message too big");
>>> break;
>>> };
>>>
>>> #########################added for cit client behind nat
>>> 09/02/05#######################
>>> if (nat_uac_test("3")){
>>> if (method == "REGISTER" || ! search("^Record-Route:")){
>>> log("Log: Someone trying to register from private IP,rewriting\n");
>>> fix_nated_contact(); #Rewrite contact with source IP
>>> if (method == "INVITE"){
>>> fix_nated_sdp("1"); #Add direction=active to SDP
>>> };
>>> force_rport(); # Add rport parameter to topmost Via
>>> setflag(6); # Mark as Nated
>>> };
>>> };
>>>
>> #####################################################################
>>> ###################
>>>
>>> # we record-route all messages -- to make sure that
>>> # subsequent messages will go through our proxy; that's
>>> # particularly good if upstream and downstream entities
>>> # use different transport protocol
>>>
>>> if (method =="REGISTER") record_route();
>>>
>>> # loose-route processing
>>> if (loose_route()) {
>>> #commented 11/02/05
>>> #t_relay();
>>> route(1);
>>> break;
>>> };
>>>
>>> # if the request is for other domain use UsrLoc
>>> # (in case, it does not work, use the following command
>>> # with proper names and addresses in it)
>>> if (uri==myself) {
>>>
>>> log(1,"into loop");
>>> if (method=="REGISTER") {
>>>
>>> # Uncomment this if you want to use digest authentication
>>> # if (!www_authorize("157.190.183.70", "subscriber")) {
>>> # www_challenge("157.190.183.70", "0");
>>> # break;
>>> # };
>>>
>>> save("location");
>>> break;
>>> };
>>>
>>> lookup("aliases");
>>> if (!uri==myself) {
>>> append_hf("P-hint: outbound alias\r\n");
>>> route(1);
>>> break;
>>> };
>>>
>>> if (method=="INVITE"){
>>> log(1,"in invite loop");
>>> #break; #no 100 trying
>>> t_on_failure("1");
>>> };
>>>
>>> # native SIP destinations are handled using our USRLOC DB
>>> if (!lookup("location")) {
>>> #sl_send_reply("404", "Not Found");
>>> route(2);
>>> break;
>>> };
>>> };
>>>
>>> # forward to current uri now; use stateful forwarding; that
>>> # works reliably even if we forward from TCP to UDP
>>> #commented 11/02/05#######################
>>> if (!t_relay()) {
>>> sl_reply_error();
>>> };
>>>
>>> }
>>>
>>> ######################################entered
>>>
>> 11/02/05############################################################
>>> route[1]
>>> {
>>> #!!Nathelper
>>> if(uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" &&
>>> !search("^Route:")){
>>> sl_send_reply("479", "We don't forward to private IP addresses");
>>> break;
>>> };
>>>
>>> t_on_reply("1");
>>>
>>> if(!t_relay()){
>>> sl_reply_error();
>>> };
>>> }
>>> ######################################entered
>>>
>> 11/02/05############################################################
>>> #!! Nathelper
>>> onreply_route[1]{
>>> if(isflagset(6) && status =~ "(183)|2[0-9][0-9]"){
>>> fix_nated_contact();
>>> force_rtp_proxy();
>>> } else if (nat_uac_test("1")){
>>> fix_nated_contact();
>>> };
>>> }
>>>
>> #####################################################################
>> #
>>> ###########################################
>>>
>>> # ------------- handling of unavailable user ------------------
>>> route[2] {
>>>
>>>        # non-Voip -- just send "off-line"
>>>        if (!(method == "INVITE" || method == "ACK" || method ==
>>> "CANCEL")) {
>>>                sl_send_reply("404", "Not Found");
>>>                break;
>>>        };
>>>
>>>        # forward to voicemail now
>>>        rewritehostport("157.190.183.70:5062");
>>>        t_relay_to_udp("157.190.183.70", "5062");
>>> }
>>>
>>> # if forwarding downstream did not succeed, try voicemail running
>>> # at 157.190.183.70:5062
>>>
>>> failure_route[1] {
>>>        revert_uri();
>>>        rewritehostport("157.190.183.70:5062");
>>>        append_branch();
>>>        t_relay_to_udp("157.190.183.70", "5062");
>>> }
>>>
>>>
>>>
>>>
>>>
>>> -------------------Legal
>>> Disclaimer---------------------------------------
>>>
>>> The above electronic mail transmission is confidential and intended
>>> only for the person to whom it is addressed. Its contents may be
>>> protected by legal and/or professional privilege. Should it be
>>> received by you in error please contact the sender at the above
>>> quoted email address. Any unauthorised form of reproduction of this
>>> message is strictly prohibited. The Institute does not guarantee
>> the
>>> security of any information electronically transmitted and is not
>>> liable if the information contained in this communication is not a
>>> proper and complete record of the message as transmitted by the
>>> sender nor for any delay in its receipt.
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>> -------------------Legal
>> Disclaimer---------------------------------------
>>
>> The above electronic mail transmission is confidential and intended
>> only for the person to whom it is addressed. Its contents may be
>> protected by legal and/or professional privilege. Should it be
>> received by you in error please contact the sender at the above
>> quoted email address. Any unauthorised form of reproduction of this
>> message is strictly prohibited. The Institute does not guarantee the
>> security of any information electronically transmitted and is not
>> liable if the information contained in this communication is not a
>> proper and complete record of the message as transmitted by the
>> sender nor for any delay in its receipt.
>>
>
>
>
> -------------------Legal
> Disclaimer--------------------------------------- 
>
> The above electronic mail transmission is confidential and intended
> only for the person to whom it is addressed. Its contents may be
> protected by legal and/or professional privilege. Should it be
> received by you in error please contact the sender at the above
> quoted email address. Any unauthorised form of reproduction of this
> message is strictly prohibited. The Institute does not guarantee the
> security of any information electronically transmitted and is not
> liable if the information contained in this communication is not a
> proper and complete record of the message as transmitted by the
> sender nor for any delay in its receipt. 




More information about the sr-users mailing list