sr-users February 2007

sr-users@lists.kamailio.org

158 participants
286 discussions

[Users] Openser and NATed users
by Victor Gamov 16 Feb '07

16 Feb '07

Hi guys! I try to use OpenSER with NATed-users and now I have some problem. No I'll try to explain it. I have the following network scheme: mySIP-phone_behind_NAT --> NAT --> OpenSER --> OtherProxy --> other_SIP_phone mySIP-phone_behind_NAT have some knowledges about external NAT_ip so it successfully registered on OpenSER using nathelper module and location table have new record looks like: user@mydomain Contact: user@NAT_ip:5060 Received: NAT_ip:NAT_port Then mySIP-phone_behind_NAT send new INVITE with Contact=user@NAT_ip:5060 OpenSER fixup this Contact using fix_nated_contact() and send INVITE to OtherProxy with Contact=user@NAT_ip:NAT_port;nat=yes Then 200OK and ACK successfully traversed via OpenSER and dialog esteblished. Then other_SIP_phone sends BYE request using R-URI learned from previous INVITE Contact-header=ser@NAT_ip:NAT_port;nat=yes OpenSER rewrite this R-URI to user@NAT_ip:NAT_port and send it using t_relay(). The packet goes to NAT_ip:NAT_port but mySIP-phone_behind_NAT sends "404 Not found" because it does not know anything about user@NAT_ip:NAT_port -- it expected user@NAT_ip:5060 as sended in first INVITE. So, my question is: is this my misconfiguration or incorrect logic understanding ? I have some ideas how to fix this problem, for eaxample: when I got INVITE from mySIP-phone_behind_NAT I must rewrite Contact to user@mydomain (assuming that requests to mydomain goes to OpenSER always). Then if OpenSER got BYE from other_SIP_phone it will lookup() and restore Contact and Received info. But I have problem again: If I rewrite R-URI to Contact and t_relay() it -- packet will be discarded by NAT because it does not anything about port 5060. If I rewrite R-URI using Received info I will get problem discribed early. Feature request "Allow AVP in t_relay()" (published in Tracker) will solve this problem Any suggestion? -- CU, Victor Gamov

2 1

[Serusers] XLOG buffer overflow help
by Nuno Ribeiro 16 Feb '07

16 Feb '07

Hello! I'm trying to add an character in the final length of an avp. The avp that I need to modify contain all SDP message. The script code that I'm using is the following: xlset_attr("$sdpnew","%$sdp;") XLOG:xl_print_log: buffer overflow -- increase the buffer size... 2(8682) Pos: 0, Add: 664, Len: 256, Buf: 2(8682) xl_printstr: Error while formating result 2(8682) ERROR: avp.c:807: xlset_attr:Error while expanding xl_format How can I overcome this problem? If there is another way to do this, please tell me Best regards, -- Nuno Ribeiro

2 1

Re: Re: [Serusers] lookup_contacts() error after sd_lookup() from the speeddial mo dule- latest cvs ottendorf
by tzieleniewski 16 Feb '07

16 Feb '07

> Hi, > > seems related to the lookup session we had on beginning of this week. > sd_lookup puts the uid into TO / USER, which is not working with the > head version (lookup_contacts need it in TO / URI) > > You can use this workaround: > if (uri =~ "sip:[0-9]{2}@.*") { > sd_lookup("speed_dial"); > $tr.uid=$tu.uid; > } Yes it seemed to me too but I just wasn't sure:) I checked it if it would help and unfortunately nothing changed. I checked it more deeply to get some more view on this and found strange results. I did the following: dump_attrs(); xlog("L_INFO", " route[INBOUND]: (uri =~ sip:[0-9]{2}@.*) <%rm> <%ru> \n"); if (uri =~ "sip:[0-9]{2}@.*") { xlog("L_INFO", " route[INBOUND]: sd_lookup(speed_dial) \n"); sd_lookup("speed_dial"); }; dump_attrs(); and result showed that there is no uid put into TO / USER so generally putting $tr.uid=$tu.uid does nothing, it is visible below in the output: Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:540: class=GLOBAL Feb 16 09:14:10 rd ser[16874]: AVP["lang"]="en" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 16 09:14:10 rd ser[16874]: AVP["did"]="voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["digest_realm"]="voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:560: track=TO class=DOMAIN Feb 16 09:14:10 rd ser[16874]: AVP["did"]="voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["digest_realm"]="voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:570: track=FROM class=USER Feb 16 09:14:10 rd ser[16874]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["email"]="tzl(a)touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["lang"]="en" Feb 16 09:14:10 rd ser[16874]: AVP["tyk"]="tyk" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:580: track=TO class=USER Feb 16 09:14:10 rd ser[16874]: INFO: No AVP present Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:590: track=FROM class=URI Feb 16 09:14:10 rd ser[16874]: AVP["authuid"]="hellboy(a)voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:600: track=TO class=URI Feb 16 09:14:10 rd ser[16874]: INFO: No AVP present Feb 16 09:14:10 rd ser[16874]: route[INBOUND]: (uri =~ sip:[0-9]{2}@.*) <INVITE> <sip:01@voip.touk.pl> Feb 16 09:14:10 rd ser[16874]: route[INBOUND]: sd_lookup(speed_dial) Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:540: class=GLOBAL Feb 16 09:14:10 rd ser[16874]: AVP["lang"]="en" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:550: track=FROM class=DOMAIN Feb 16 09:14:10 rd ser[16874]: AVP["did"]="voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["digest_realm"]="voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:560: track=TO class=DOMAIN Feb 16 09:14:10 rd ser[16874]: AVP["did"]="voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["digest_realm"]="voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:570: track=FROM class=USER Feb 16 09:14:10 rd ser[16874]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["email"]="tzl(a)touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["lang"]="en" Feb 16 09:14:10 rd ser[16874]: AVP["tyk"]="tyk" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:580: track=TO class=USER Feb 16 09:14:10 rd ser[16874]: INFO: No AVP present Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:590: track=FROM class=URI Feb 16 09:14:10 rd ser[16874]: AVP["authuid"]="hellboy(a)voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: AVP["uid"]="hellboy(a)voip.touk.pl" Feb 16 09:14:10 rd ser[16874]: INFO: avp.c:600: track=TO class=URI Feb 16 09:14:10 rd ser[16874]: INFO: No AVP present And there are still many questions about the lookup_user() function. When I call a subscriber directly not by speeddial number and I invoke it this way: lookup_user("$t.uid", "@ruri"); then the invocation of he lookup_contacts("location") function returns positive result. Any other form of lookup_user() causes the failure of the lookup_contacts() function. I tried to do $tr.uid = $t.uid as well as $tu.uid = $t.uid after lookup_user() but it always didn't cause any change and those avp values where always empty. Please share any ideas:) Cheers -tomasz > > it will set the AVP in the URI track and should be then reachable. > > Michal > > > On Thu, 2007-02-15 at 14:20 +0100, tzieleniewski wrote: > > Hi! > > > > I have encountered the following situation after I make the translation from the speeddial number into the proper uri the user cannot be found by the lookup_contacts() function. Calling a user directly works without any problem: > > > > My logic is the following: > > > > dump_attrs(); > > if (uri =~ "sip:[0-9]{2}@.*") { > > sd_lookup("speed_dial"); > > } > > dump_attrs(); > > if (lookup_user("$t.uid", "@ruri")) { > > dump_attrs(); > > load_attrs("$tu", "@ruri"); > > load_attrs("$tr", "@ruri"); > > dump_attrs(); > > if (lookup_contacts("location")) { > > append_hf("P-hint: usrloc applied\r\n"); > > route(FORWARD); > > drop; > > } else { > > route(CALL_FORWARD_VOICEMAIL); > > drop; > > } > > } > > > > Here is the debug output: > > > > Feb 15 14:15:23 rd ser[14469]: route[INBOUND]: <INVITE> <sip:01@voip.touk.pl> > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:540: class=GLOBAL > > Feb 15 14:15:23 rd ser[14469]: AVP["lang"]="en" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:550: track=FROM class=DOMAIN > > Feb 15 14:15:23 rd ser[14469]: AVP["did"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["digest_realm"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:560: track=TO class=DOMAIN > > Feb 15 14:15:23 rd ser[14469]: AVP["did"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["digest_realm"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:570: track=FROM class=USER > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["email"]="tzl(a)touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["lang"]="en" > > Feb 15 14:15:23 rd ser[14469]: AVP["tyk"]="tyk" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:580: track=TO class=USER > > Feb 15 14:15:23 rd ser[14469]: INFO: No AVP present > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:590: track=FROM class=URI > > Feb 15 14:15:23 rd ser[14469]: AVP["authuid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:600: track=TO class=URI > > Feb 15 14:15:23 rd ser[14469]: INFO: No AVP present > > Feb 15 14:15:23 rd ser[14469]: route[INBOUND]: (uri =~ sip:[0-9]{2}@.*) <INVITE> <sip:01@voip.touk.pl> > > Feb 15 14:15:23 rd ser[14469]: route[INBOUND]: sd_lookup(speed_dial) > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:540: class=GLOBAL > > Feb 15 14:15:23 rd ser[14469]: AVP["lang"]="en" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:550: track=FROM class=DOMAIN > > Feb 15 14:15:23 rd ser[14469]: AVP["did"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["digest_realm"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:560: track=TO class=DOMAIN > > Feb 15 14:15:23 rd ser[14469]: AVP["did"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["digest_realm"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:570: track=FROM class=USER > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["email"]="tzl(a)touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["lang"]="en" > > Feb 15 14:15:23 rd ser[14469]: AVP["tyk"]="tyk" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:580: track=TO class=USER > > Feb 15 14:15:23 rd ser[14469]: INFO: No AVP present > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:590: track=FROM class=URI > > Feb 15 14:15:23 rd ser[14469]: AVP["authuid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:600: track=TO class=URI > > Feb 15 14:15:23 rd ser[14469]: INFO: No AVP present > > Feb 15 14:15:23 rd ser[14469]: route[INBOUND]: (lookup_user($t.uid, @ruri)) <INVITE> <sip:hellboy@voip.touk.pl> > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:540: class=GLOBAL > > Feb 15 14:15:23 rd ser[14469]: AVP["lang"]="en" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:550: track=FROM class=DOMAIN > > Feb 15 14:15:23 rd ser[14469]: AVP["did"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["digest_realm"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:560: track=TO class=DOMAIN > > Feb 15 14:15:23 rd ser[14469]: AVP["did"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["digest_realm"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:570: track=FROM class=USER > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["email"]="tzl(a)touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["lang"]="en" > > Feb 15 14:15:23 rd ser[14469]: AVP["tyk"]="tyk" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:580: track=TO class=USER > > Feb 15 14:15:23 rd ser[14469]: INFO: No AVP present > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:590: track=FROM class=URI > > Feb 15 14:15:23 rd ser[14469]: AVP["authuid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:600: track=TO class=URI > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: route[INBOUND]: load_attrs($tu,@ruri) <INVITE> <sip:hellboy@voip.touk.pl> > > Feb 15 14:15:23 rd ser[14469]: route[INBOUND]: load_attrs($tr,@ruri) <INVITE> <sip:hellboy@voip.touk.pl> > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:540: class=GLOBAL > > Feb 15 14:15:23 rd ser[14469]: AVP["lang"]="en" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:550: track=FROM class=DOMAIN > > Feb 15 14:15:23 rd ser[14469]: AVP["did"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["digest_realm"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:560: track=TO class=DOMAIN > > Feb 15 14:15:23 rd ser[14469]: AVP["did"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["digest_realm"]="voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:570: track=FROM class=USER > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["email"]="tzl(a)touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["lang"]="en" > > Feb 15 14:15:23 rd ser[14469]: AVP["tyk"]="tyk" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:580: track=TO class=USER > > Feb 15 14:15:23 rd ser[14469]: INFO: No AVP present > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:590: track=FROM class=URI > > Feb 15 14:15:23 rd ser[14469]: AVP["authuid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: INFO: avp.c:600: track=TO class=URI > > Feb 15 14:15:23 rd ser[14469]: AVP["uid"]="hellboy(a)voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: AVP["forward_blindd"]="sip:evn@voip.touk.pl" > > Feb 15 14:15:23 rd ser[14469]: route[INBOUND]: (lookup_contacts(location)) > > Feb 15 14:15:23 rd ser[14469]: route[INBOUND]: route(CALL_FORWARD_VOICEMAIL) <INVITE> <sip:hellboy@voip.touk.pl> > > > > Bests > > -tomasz > > _______________________________________________ > > Serusers mailing list > > Serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers >

1 0

[Serusers] Forwarding and mediaproxy
by Shaun Hofer 16 Feb '07

16 Feb '07

Hi, I wish to forward busy and no answer calls to Asterisk, and have the RTP stream go through mediaproxy. At the moment, some calls use mediaproxy and some don't. If the call is not using mediaproxy to get it too. I have noticed that I can't call use_media_proxy() from failed route. I don't want to use mediaproxy for every call between UA's, if not needed. Any suggestions on how I might be able to get calls to use mediaproxy if forwarded ? current fail route: failure_route[1] { if (t_check_status("487")) { break; }; if (isflagset(26) && t_check_status("486")) { avp_delete("s:fwdbusy"); resetflag(26); revert_uri(); rewritehostport("202.168.41.218:5060"); append_branch(); t_relay_to_udp("202.168.41.218", "5060"); break; }; if (isflagset(27) && t_check_status("408")) { avp_delete("s:fwdnoanswer"); resetflag(27); revert_uri(); rewritehostport("202.168.41.218:5060"); append_branch(); t_relay_to_udp("202.168.41.218", "5060"); break; }; end_media_session(); } Thanks -- Shaun Hofer

4 11

[Serusers] SER doesn't create TCP registrations
by Andrew T Gin 16 Feb '07

16 Feb '07

Hi I'm having some trouble getting SER working. I am using example Hello World example ser.cfg (in Ser-GettingStarted.pdf). My client can REGISTER using UDP successfully, but when I to REGISTER with TCP, it fails. I performed a wireshark trace, and the problem is when the client sends a SYN, SER responds with an RST, so the TCP 3 way handshake doesn't finish. The output of SER shows: Listening on udp: 132.181.9.24 [132.181.9.24]:5060 tcp: 132.181.9.24 [132.181.9.24]:5060 Aliases: tcp: cosc4101.cosc.canterbury.ac.nz:5060 udp: cosc4101.cosc.canterbury.ac.nz:5060 What have I done wrong? Thanks Andrew

2 1

[Serusers] Can SER do this?
by David Good 16 Feb '07

16 Feb '07

I have a problem that I *think* SER can help with, but looking through the docs and samples, I don't see anything quite like what I need to do. Here's my situation: I have an Asterisk box setup internally with a few PSTN trunks. We have another box in a colo that we're using to communicate to a SIP trunk from bandwidth.com. Currently we have Asterisk running there, too. What we want to do is: * Have all outbound calls from Asterisk go to the SIP trunk at the colo. We have this working now using Asterisk at the colo. * Have all incoming calls from the SIP trunk (it has several DID numbers) be routed to the internal Asterisk box just like the existing PSTN trunks. I haven't been able to get this part working using Asterisk (which is why I'm looking at SER now) There is NAT involved between the colo server and bandwidth.com. Is this possible?

2 1

[Users] Open SER for SIP NNI
by konstantinos nikou 16 Feb '07

16 Feb '07

Dear all, I am trying to use the Open SER for SIP NNI. I would like all calls with the prefix 077 to be routed to another SIP server and add a prefix (+49). I am using the following code: if (uri=~"^sip:077[0-9]*@*") { strip(1); prefix("+49"); rewritehost("172.17.2.35"); # forward( 172.17.2.35, 5060 ); route(1); } Normally, i believe that when i run this code and i am sending an INVITE from my user to a number e.g. 0771234567, the SER server should send this invite to the IP 172.17.2.35. But i don't see this. The SER responsds directly with a 404 NOT FOUND message. Do you have any idea of how i could solve the problem? I am using Suse Linux and attached you can find my configuration file. Thank you all, K.N. ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/

2 1

[Users] Openser- parser error for openser.cfg
by K Biju 16 Feb '07

16 Feb '07

Hi All, I have installed openser version 1.1.1-notls(i386/linux). I am trying to configure the openser to route all calls to a gateway. For this I have added the following rules in openser.cfg route { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; } record_route(); if (src_ip==1.1.1.1) { forward_tcp(4.4.4.4, 5060); } else { forward_udp(1.1.1.1, 5060); } } Now when I bring up the server I get the following error [root@localhost openser-1.1.1-notls]# /usr/local/sbin/openser -n 1 -ddddd -E -l tcp:47.100.105.195:5060 -l udp:47.100.105.195:5060 0(18381) read 3133282016 from /dev/urandom 0(18381) seeding PRNG with 9917133 0(18381) test random number 521145638 0(18381) parse error (27,46-50): parse error 0(18381) parse error (27,50-51): bad arguments 0(18381) parse error (30,28-29): parse error 0(18381) parse error (30,41-42): bad arguments ERROR: bad config file (4 errors) What is wrong with the syntax or am I missing any modules ? Thanks in advance -Biju ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

2 1

[Users] NAT Types
by raviprakash sunkara 16 Feb '07

16 Feb '07

Hello Users, Good Morning, What are Type of the NAT is used for OpenSER for production , OpenSER is inside the NAT (router/firewall ) 1) I tested with 2 SJ phones and 2 cisco ATA phones, UAC's are in Behind the NAT, UACs are in the Same N/w with one public_address, SJ phone show the NAT type is Symmetric NAT this case is Working Fine, For example : [Behind the NAT1 ] [Behind the NAT2] [Behind the NAT1 ] SJphone -------------------------------> OpenSER---------------------> ATA phone 2) When SJ phones or HardPhones are in Different network behind the NAT of the OpenSER server, here SJ phone shows the Port Restricted core NAT Here media is not is signaling at all , in this Case.... For example : [Behind the NAT1 ] [Behind the NAT2] [Behind the NAT3 ] SJphone -------------------------------> OpenSER---------------------> ATA phone SIP NAT Traversal support only Symmetric NAT , ? Then How to solve this issue ? Please Help ? -- Thanks and Regards Ravi Prakash Sunkara ravi.sunkara(a)hyperion-tech.com M:+91 9985077535 www.hyperion-tech.com Client and Parent company :- www.august-networks.com

1 0

[Users] NAT Types Isssues
by raviprakash sunkara 16 Feb '07

16 Feb '07

Hello Users, Good Morning, What are Type of the NAT is used for OpenSER for production , OpenSER is inside the NAT (router/firewall ) 1) I tested with 2 SJ phones and 2 cisco ATA phones, UAC's are in Behind the NAT, UACs are in the Same N/w with one public_address, SJ phone show the NAT type is Symmetric NAT in Display... this case is Working Fine, 2) When SJ phones or HardPhones are in Different network behind the NAT of the OpenSER server, here SJ phone shows the Port Restricted core NAT Here media is not is signaling at all , in this Case.... SIP NAT Traversal support only Symmetric NAT , ? Then How to solve this issue ? Please Help ? -- Thanks and Regards Ravi Prakash Sunkara ravi.sunkara(a)hyperion-tech.com M:+91 9985077535 Client and Parent company :- www.august-networks.com

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
29
Older →

Jump to page:

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 February 2007