sr-users December 2006

sr-users@lists.kamailio.org

152 participants
257 discussions

[Users] OpenSER as load balancer for several Asterisk servers

by Edoardo Serra

Hi guys, I'm having a problem with an OpenSER acting as registrar server and load balancer for many Asterisk servers. In a few words: "users are registering on openser and, when they want to make a call, OpenSER proxies the request to an Asterisk server with the dispatcher module" Here is the intended data flow (SIP goes through OpenSER and media goes directly to Asterisk) User <-- SIP --> OpenSER <-- SIP --> Asterisk User <-- RTP --> Asterisk Both, OpenSER and Asterisks have public IPs I already have a working setup of that and everything seems working correctly. I'm trying to replicate that setup on another site, same configurations of the boxes, same versions of OpenSER and Asterisk, etc... but I'm having monodirectional Audio. Having a look with tethereal I see that OpenSER, when the communication is answered, sends a SIP packet (200 OK) to the user indicating itself as media endpoint instead of the Asterisks. From that moment I see RTP packets flowing from the client to OpenSER This seems really strange to me because I just copied the same configurations file from a working setup to the new installation. Tnx in advance for help. Regards P.S.: Here is my openser.cfg ## $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) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) #children=4 #port=5060 fifo="/tmp/ser_fifo" #uid=nobody #gid=nobody # ------------------ module loading ---------------------------------- loadmodule "/usr/lib/openser/modules/sl.so" loadmodule "/usr/lib/openser/modules/tm.so" loadmodule "/usr/lib/openser/modules/rr.so" loadmodule "/usr/lib/openser/modules/maxfwd.so" loadmodule "/usr/lib/openser/modules/usrloc.so" loadmodule "/usr/lib/openser/modules/registrar.so" loadmodule "/usr/lib/openser/modules/nathelper.so" loadmodule "/usr/lib/openser/modules/textops.so" loadmodule "/usr/lib/openser/modules/exec.so" loadmodule "/usr/lib/openser/modules/uri.so" loadmodule "/usr/lib/openser/modules/uri_db.so" loadmodule "/usr/lib/openser/modules/dispatcher.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/lib/openser/modules/mysql.so" loadmodule "/usr/lib/openser/modules/auth.so" loadmodule "/usr/lib/openser/modules/auth_db.so" modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "mysql://xxx:xxx@xxx.xxx.xxx.xxx/openser") modparam("usrloc", "timer_interval", 120) modparam("auth_db", "calculate_ha1", 0) modparam("auth_db", "db_url", "mysql://xxx:xxx@xxx.xxx.xxx.xxx/voip") modparam("uri_db", "db_url", "mysql://xxx:xxx@xxx.xxx.xxx.xxx/openser") modparam("rr", "enable_full_lr", 1) modparam("registrar", "nat_flag", 6) modparam("registrar", "max_expires", 3600) modparam("registrar", "min_expires", 60) modparam("registrar", "append_branches", 0) modparam("registrar", "desc_time_order", 1) modparam("nathelper", "natping_interval", 20) # Ping interval 20 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT modparam("dispatcher", "force_dst", 1) # ------------------------- 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"); exit; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); exit; }; if ( (method=="OPTIONS") || (method=="SUBSCRIBE") || (method=="NOTIFY") ) { sl_send_reply("405", "Method Not Allowed"); exit; } if (!method=="REGISTER") { record_route(); }; if ((src_ip==xxx.xxx.xxx.xxx) || (src_ip==xxx.xxx.xxx.xxx)) { # IP of Asterisks if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; # forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP if (!t_relay()) { sl_reply_error(); }; exit; }; if (nat_uac_test("3")) { if ((method=="REGISTER") || (method=="INVITE") || (method=="OPTIONS")) { fix_nated_contact(); force_rport(); setflag(6); # Mark as NATed } } # 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 (method=="REGISTER") { if (!proxy_authorize("domain", "openser_view")) { proxy_challenge("domain", "0"); exit; } if (!check_to()) { sl_send_reply("403", "Digest username and URI username do NOT match! Stay away!"); exit; } save("location"); exit; }; if (method=="INVITE") { if (!proxy_authorize("domain", "openser_view")) { proxy_challenge("domain", "0"); exit; } if (!check_from()) { sl_send_reply("403", "Digest username and URI username do NOT match! Stay away!"); exit; } } # loose-route processing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); exit; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); exit; }; append_hf("P-hint: usrloc applied\r\n"); route(1); } 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"); exit; }; # NAT processing of replies; apply to all transactions (for example, # re-INVITEs from public to private UA are hard to identify as # NATed at the moment of request processing); look at replies t_on_reply("1"); # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if ((src_ip!=xxx.xxx.xxx.xxx) && (src_ip!=xxx.xxx.xxx.xxx)) { # IP of Asterisks ds_select_dst("2", "0"); } if (!t_relay()) { sl_reply_error(); }; } # ! Nathelper onreply_route[1] { # NATed transaction ? if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") { fix_nated_contact(); # otherwise, is it a transaction behind a NAT and we did not # know at time of request processing ? (RFC1918 contacts) } else if (nat_uac_test("1")) { fix_nated_contact(); }; }

17 years, 11 months

[Serusers] Multiple domain

by TZieleniewski

Hi ! A have a small technical question:) It considers serving of multiple domain. I would like to make sure that I understand things right. After I read the user doc and README from domain module I came to the following state of art:) 1)one has to create the seperate location and subscriber table for each domain *so if i have for instance two domains : dom1.com and dom2.com then my ser has to have the according dns records in the dns server? 2) after creating the tables i need to add domains record in the database to the domain table *I dont know why but when ever i try to add or show domains o get the following error 500 command 'domain_dump' not available - why is that so? any way instead of an error the serctl command adds the domain record to the database 3) modify the ser.cfg file - add appropriate modparam commands 4) modify the ser.cfg file by adding a regular expression analizys to invoke the save, www_chalenge, proxy_chalenge and lookup correctly with the right domain? Please tell me is my thinking here right? or maybe there is another way As allway thank u for your time. Bests tomek

17 years, 11 months

Re: [Users] Delayed signalling?

by Jiri Kuthan

if you happen to have a PCAP file with the incident, let me please know. -jiri p.s. even if you didn't tweak timers, the results may be suboptimal because the software version you are using is having rather indeterministic timer subsystem. For example, the recent measurements (http://www.iptel.org/ser/doc/performance) show quite scattered server responsiveness under high load. (Note though that the measurement results were achieved in a best-effort manner based on the tester knowledge and understanding of openser and that the result are not officially confirmed by the OpenSER project.) Whether it is indeed the cause is not certain though -- this looks really like a stealth bug. At 15:58 15/12/2006, Max Gregorian wrote: >Thanks very much for all the replies. I shall try and post a config and traces as soon as I can get them from the office. > >Some more information, if it helps: > >Server specs: >- HP ProLiant DL360 G4 (1U rack servers) >- 3 GHz processors (800 MHz FSB) >- 1 GB RAM >- 10K rpm SCSI HDs (in a RAID 1+0 Mirror) > ># Servers are running OpenSER 1.0.1 (no-TLS). ># Servers are listening on 3 ports (both tcp and udp for each port), so in openserctl ps I am seeing 4 child processes for each port. ># Servers running CentOS Linux 4.3 ># MySQL installed when CentOS was installed but not running and not currently being used with Openser. > > >Things I have pretty much managed to eliminate are: >1. It's doesn't seem to be hardware. The specs for the servers are more than sufficient I think. >2. It doesn't seem to be traffic/load related as I see these problems on 2 brand new servers I have just installed with no traffic on them. However, it does seem to get worse with more traffic. >3. I don't think it's database related as I have deliberately not configured mysql on any of the servers in case of database performance. >4. I haven't played with the timers at all so far. >5. I haven't configured nscd yet, but as far as I can tell it's not caching DNS. >6. Though openser is listening on tcp ports as well, currently only the udp ports are being used as most of our customers use hardware phones. In any case, I haven't as yet seen as requests on tcp. >7. I am not sure it is DNS as in the tests I ran I sent requests directly to the external IP of the server and not to the domain name it is responsible for. Also the test servers are now only responsible for one domain, but in future will have more than one. >8. Also TTL on the domain name is really short. Ping from the server itself TTL=64 and ping times are low as you would expect (< 1ms when pinging from the server itself). Ping from outside the network (from the internet - for me - tp the domain was) 12ms (average), no packet loss, TTL = 53. >9. I have not setup any internal DNS entries for the domain. Servers are resolving domain from entries in /etc/hosts. > >Like I said, it doesn't happen all the time - just maybe once or twice every hour on the servers with more traffic. > >I ran SIPp pointing at one of the new servers last week and at around 100CPS I was seeing about 2,000 out of approx. 10,000 calls were failing. Setup was UAC -> openser -> UAS (Both UAC and UAS were running on the same machine, but different ports). Again there is no traffic on these servers now so I have no idea why so many failed calls. > >I am not sure if any of this information helps, but I am certainly open to suggestions on things to try. > >Thanks in advance. > > > >On 12/14/06, samuel <<mailto:samu60@gmail.com>samu60(a)gmail.com> wrote: >It might be due to a DNS query....whenver a request has to be >forwarded to a domain, openSER makes a DNS query to resolv the IP. >During this operation, the child processing the request will not >answer to further incoming messages. > >it also can be happening due to a spiral loop that stays on the server. > >Without further information (confg,logs) it's hard to tell which is >the reason... > >hope it helps, >Samuel. > >without more information > >2006/12/14, Max Gregorian <<mailto:gregorian442@googlemail.com>gregorian442(a)googlemail.com>: >> Hi all, >> >> Just wondering if anyone else has had this problem. I have noticed while >> tracing on my OpenSER server, that every now and then the server receives a >> packet which it does to respond to immediately, resulting in a string of >> packets being sent to the server and then the server responding a few >> seconds later. This does not happen all the time, just say maybe once or >> twice every hour. The rest of the time the signaling is correct and >> responses follow request packets in the correct order. >> >> What I am trying to figure out is whether this is a load traffic issue (i.e. >> can the server not handle too much load), and if so is it OpenSER or the >> network or the server in general? I have run diagnostics on the servers and >> there is nothing wrong with the hardware. >> >> On the other hand Could this be related to any timer issues? I remember >> there was mention of timers in SER but are there any default timer settings >> that can be tweaked? >> >> Thanks in advance for any response. >> >> >> _______________________________________________ >> Users mailing list >> <mailto:Users@openser.org>Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > > >_______________________________________________ >Users mailing list >Users(a)openser.org >http://openser.org/cgi-bin/mailman/listinfo/users -- Jiri Kuthan http://iptel.org/~jiri/

17 years, 11 months

[Users] Problem with avp_check

by Jose Gil Navarrete

Hi I try to check the username in the URI, this is, if the username do not have ten digits then send a message, I made: avp_write("^[0-9]{10}","$avp(s:fm_avp)"); if(avp_check("$fU","fm/$avp(s:fm_avp)/g")) { insert_hf("To-username: -$fU- \r\n", "Call-ID"); } else { sl_send_reply("400", "Bad Request"); exit; }; but I ever obtain 400 message. I try too with: if(avp_check("$fU","re/[0-9]{10}$/g")) { insert_hf("To-username: -$fU- \r\n", "Call-ID"); else{ sl_send_reply("400", "Bad request"); exit; } But I obtain the same message. Any idea? __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/

17 years, 11 months

[Users] flags in reply route

by Klaus Darilion

Hi! Do I have access to the flags of a transaction in a reply route? regards klaus -- Klaus Darilion nic.at

17 years, 11 months

Re: [Serusers] branch parameter

by Tuffy Dhawan

SER is identifying call even W/O branch parameter and i have not used forward(). My only question was to make sure that RTC/1.2 should generate branch parameter. >From: Martin Hoffmann <hn(a)nvnc.de> >To: Jiri Kuthan <jiri(a)iptel.org> >CC: Kapil Dhawan <digitaltuffy(a)hotmail.com>, serusers(a)lists.iptel.org >Subject: Re: [Serusers] branch parameter >Date: Mon, 18 Dec 2006 16:58:00 +0100 > >Jiri Kuthan wrote: > > At 17:05 17/12/2006, Kapil Dhawan wrote: > > > > > I am using RTC/1.2 library and its not generating branch parameter. > > > > too bad, most implementation can deal with it in backw2ards >compatibility mode > > but clients should no longer generate such branch. I would be looking >for > > a more up-to-date stack if I was you. > ><evil> >Ever used forward() in SER? ></evil> > >Regards, >Martin _________________________________________________________________ Christmas is drawing near and the excitement is in the air! Check out this cool photofeature on Christmas celebrations the world over http://www.msnspecials.in/photogallery/photogallery.asp?id=a200611814137906

17 years, 11 months

Re: [Users] How to get CDR in Openser

by Klaus Darilion

Howard Tang wrote: > Hi klaus, > > I am new to the VOIP / Voice world. Thank you for your reply. I just > want openser to generate CDR. Do i need radius to do that? > > Regards, > Howard > > Klaus Darilion wrote: >> Howard Tang wrote: >>> Hi, >>> >>> Can someone give me some idea of how i can obtain CDR from Openser >>> please? >>> >>> I saw a open source software called cdrtools, however, i don't want >>> to install apache on my machine. >> >> cdrtools does not generate CDRs. It just analyzes the CDRs. >> >> Thus, what do you want? >> Creating CDRs or analyzing? >> >> openser can create CDRs for DB, Radius or syslog using the acc module >> (see module documentation on openser.org) no, you do not need radius. you can alos use syslog accounting or database accounting. http://www.openser.org/docs/modules/1.1.x/acc.html btw: please cc the mailing list regards klaus >> >> regards >> klaus >> >>> >>> Any other CDR software will work with openser >> >>> >>> Regards, >>> Howard >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)openser.org >>> http://openser.org/cgi-bin/mailman/listinfo/users >> >> > -- Klaus Darilion nic.at

17 years, 11 months

[Users] A question about cancels..

by nick

When I make a call to someone, a call which is correctly connected, for example via PSTN gateway, I can watch INVITEs, ACKs, OKs and BYEs being relayed from my station the my openser to the gateway, and back.. However if the phone rings, and I decide to terminate the call (before the other person responds), I see the CANCEL going from my station to the sipserver, but I don't see it being sent to the PSTN gateway.. Is this something I have to specifically route for? The CANCEL is part of the same call sequence, is there a reason it wouldn't be relayed, other than a mistake in my routing, obviously.. Nick

17 years, 11 months

Re: [Serusers] Problem with MTU size in SER with MIPv6.

by Jose Angel Calvo

Now, i'll explain and show the INVITE causing the crash: The INVITE packet is fragmented in two frames. The capture is done with the ethereal (wireshark now) and it's the next: *********************************************************************** No. Time Source Destination Protocol Info 1 0.000000 2001:720:1500:24:fcfd:ff:fe0d:101 2001:720:1500:1b:20c:76ff:fe6c:4658 IPv6 IPv6 fragment (nxt=UDP (0x11) off=1408 id=0x5) Frame 1 (431 bytes on wire, 431 bytes captured) Arrival Time: Nov 30, 2006 16:40:02.345512000 Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Frame Number: 1 Packet Length: 431 bytes Capture Length: 431 bytes Protocols in frame: sll:ipv6:data Linux cooked capture Packet type: Unicast to another host (3) Link-layer address type: 1 Link-layer address length: 6 Source: Cisco_17:28:70 (00:d0:06:17:28:70) Protocol: IPv6 (0x86dd) Internet Protocol Version 6 Version: 6 Traffic class: 0x00 Flowlabel: 0x00000 Payload length: 375 Next header: IPv6 fragment (0x2c) Hop limit: 61 Source address: 2001:720:1500:24:fcfd:ff:fe0d:101 (2001:720:1500:24:fcfd:ff:fe0d:101) Destination address: 2001:720:1500:1b:20c:76ff:fe6c:4658 (2001:720:1500:1b:20c:76ff:fe6c:4658) Fragmentation Header Next header: UDP (0x11) Offset: 1408 More fragments: No Identification: 0x00000005 Data (367 bytes) 0000 00 03 00 01 00 06 00 d0 06 17 28 70 00 00 86 dd ..........(p.... 0010 60 00 00 00 01 77 2c 3d 20 01 07 20 15 00 00 24 `....w,= .. ...$ 0020 fc fd 00 ff fe 0d 01 01 20 01 07 20 15 00 00 1b ........ .. .... 0030 02 0c 76 ff fe 6c 46 58 11 00 05 80 00 00 00 05 ..v..lFX........ 0040 50 44 41 54 45 0d 0a 52 65 70 6c 61 63 65 73 3a PDATE..Replaces: 0050 20 64 34 63 38 37 63 39 30 32 64 31 62 35 32 62 d4c87c902d1b52b 0060 32 38 36 62 61 64 39 36 66 33 63 62 62 36 31 34 286bad96f3cbb614 0070 34 40 5b 32 30 30 31 3a 37 32 30 3a 31 35 30 30 4@[2001:720:1500 0080 3a 31 61 3a 32 33 30 3a 31 62 66 66 3a 66 65 31 :1a:230:1bff:fe1 0090 30 3a 35 66 62 33 5d 3b 72 65 61 73 6f 6e 3d 53 0:5fb3];reason=S 00a0 49 50 20 72 6f 75 74 65 20 68 61 73 20 63 68 61 IP route has cha 00b0 6e 67 65 64 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 nged..Content-Ty 00c0 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f pe: application/ 00d0 73 64 70 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e sdp..Content-Len 00e0 67 74 68 3a 20 31 39 35 0d 0a 0d 0a 76 3d 30 0d gth: 195....v=0. 00f0 0a 6f 3d 69 73 61 62 65 6c 20 30 20 30 20 49 4e .o=isabel 0 0 IN 0100 20 49 50 36 20 5b 32 30 30 31 3a 37 32 30 3a 31 IP6 [2001:720:1 0110 35 30 30 3a 31 61 3a 32 33 30 3a 31 62 66 66 3a 500:1a:230:1bff: 0120 66 65 31 30 3a 35 66 62 33 5d 0d 0a 73 3d 2d 0d fe10:5fb3]..s=-. 0130 0a 63 3d 49 4e 20 49 50 36 20 32 30 30 31 3a 37 .c=IN IP6 2001:7 0140 32 30 3a 31 35 30 30 3a 31 61 3a 32 33 30 3a 31 20:1500:1a:230:1 0150 62 66 66 3a 66 65 31 30 3a 35 66 62 33 0d 0a 74 bff:fe10:5fb3..t 0160 3d 30 20 30 0d 0a 6d 3d 61 75 64 69 6f 20 32 32 =0 0..m=audio 22 0170 32 32 34 20 52 54 50 2f 41 56 50 20 30 20 33 20 224 RTP/AVP 0 3 0180 34 20 35 20 36 20 38 20 31 35 20 31 38 0d 0a 6d 4 5 6 8 15 18..m 0190 3d 76 69 64 65 6f 20 32 32 32 32 32 20 52 54 50 =video 22222 RTP 01a0 2f 41 56 50 20 32 36 20 33 34 20 33 31 0d 0a /AVP 26 34 31.. No. Time Source Destination Protocol Info 2 0.000117 2001:720:1500:24:fcfd:ff:fe0d:101 2001:720:1500:1b:20c:76ff:fe6c:4658 SIP Request: INVITE sip:[2001:720:1500:1b:20c:76ff:fe6c:4658]:5060;transport=udp Frame 2 (1512 bytes on wire, 1512 bytes captured) Arrival Time: Nov 30, 2006 16:40:02.345629000 Time delta from previous packet: 0.000117000 seconds Time since reference or first frame: 0.000117000 seconds Frame Number: 2 Packet Length: 1512 bytes Capture Length: 1512 bytes Protocols in frame: sll:ipv6:ipv6:udp:sip Linux cooked capture Packet type: Sent by us (4) Link-layer address type: 1 Link-layer address length: 6 Source: fe:fd:00:0c:00:01 (fe:fd:00:0c:00:01) Protocol: IPv6 (0x86dd) Internet Protocol Version 6 Version: 6 Traffic class: 0x00 Flowlabel: 0x00000 Payload length: 1456 Next header: IPv6 (0x29) Hop limit: 64 Source address: 2001:720:1500:1b:fcfd:ff:fe0c:1 (2001:720:1500:1b:fcfd:ff:fe0c:1) Destination address: 2001:720:1500:24:20c:76ff:fe6c:4658 (2001:720:1500:24:20c:76ff:fe6c:4658) Internet Protocol Version 6 Version: 6 Traffic class: 0x00 Flowlabel: 0x00000 Payload length: 1416 Next header: IPv6 fragment (0x2c) Hop limit: 60 Source address: 2001:720:1500:24:fcfd:ff:fe0d:101 (2001:720:1500:24:fcfd:ff:fe0d:101) Destination address: 2001:720:1500:1b:20c:76ff:fe6c:4658 (2001:720:1500:1b:20c:76ff:fe6c:4658) Fragmentation Header Next header: UDP (0x11) Offset: 0 More fragments: Yes Identification: 0x00000005 User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Source port: sip (5060) Destination port: sip (5060) Length: 1775 Checksum: 0x9301 Session Initiation Protocol Request-Line: INVITE sip:[2001:720:1500:1b:20c:76ff:fe6c:4658]:5060;transport=udp SIP/2.0 Method: INVITE Resent Packet: False Message Header Record-Route: <sip:[2001:720:1500:24:FCFD:FF:FE0D:101];ftag=12122347;lr=on> Record-Route: <sip:[2001:720:1500:1B:FCFD:FF:FE0C:103];ftag=12122347;lr=on> Record-Route: <sip:[2001:720:1500:1A:FCFD:FF:FE0A:103];ftag=12122347;lr=on> Record-Route: <sip:[2001:720:1500:19:FCFD:FF:FE0E:101];ftag=12122347;lr=on> Call-ID: 138104335821ad9b21971c7d6059b6c8@[2001:720:1500:1a:230:1bff:fe10:5fb3] CSeq: 1 INVITE From: "ueA" <sip:ueA@domainA.ammi.dit.upm.es>;tag=12122347 SIP Display info: "ueA" SIP from address: sip:ueA@domainA.ammi.dit.upm.es SIP tag: 12122347 To: <sip:ueC@domainC.ammi.dit.upm.es> SIP to address: sip:ueC@domainC.ammi.dit.upm.es Via: SIP/2.0/UDP [2001:720:1500:24:FCFD:FF:FE0D:101];branch=z9hG4bK1205.ddbf87e4.0 Via: SIP/2.0/UDP [2001:720:1500:1B:FCFD:FF:FE0C:103];branch=z9hG4bK1205.c8a66626.0 Via: SIP/2.0/UDP [2001:720:1500:1B:FCFD:FF:FE0C:102];branch=z9hG4bK1205.1cb3a0b4.0 Via: SIP/2.0/UDP [2001:720:1500:1A:FCFD:FF:FE0A:103];branch=z9hG4bK1205.44344f04.0 Via: SIP/2.0/UDP [2001:720:1500:19:FCFD:FF:FE0E:101];branch=z9hG4bK1205.a44e3b34.0 Via: SIP/2.0/UDP [2001:720:1500:1a:230:1bff:fe10:5fb3]:61052;branch=z9hG4bK40e1844512a234e326ef8222f8b204fb Max-Forwards: 12 Contact: "ueA" <sip:[2001:720:1500:1a:230:1bff:fe10:5fb3]:61052;transport=udp> Contact Binding: "ueA" <sip:[2001:720:1500:1a:230:1bff:fe10:5fb3]:61052;transport=udp> URI: "ueA" <sip:[2001:720:1500:1a:230:1bff:fe10:5fb3]:61052;transport=udp> SIP Display info: "ueA" SIP contact address: sip:[2001:720:1500:1a:230:1bff:fe10:5fb3]:61052 P-Preferred-Identity: "ueA" <sip:ueA@domainA.ammi.dit.upm.es>;tag=12122347 Privacy: none P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=181086 Allow: INVITE,ACK,CANCEL,BYE,PRACK,U 0000 00 04 00 01 00 06 fe fd 00 0c 00 01 00 00 86 dd ................ 0010 60 00 00 00 05 b0 29 40 20 01 07 20 15 00 00 1b `.....)@ .. .... 0020 fc fd 00 ff fe 0c 00 01 20 01 07 20 15 00 00 24 ........ .. ...$ 0030 02 0c 76 ff fe 6c 46 58 60 00 00 00 05 88 2c 3c ..v..lFX`.....,< 0040 20 01 07 20 15 00 00 24 fc fd 00 ff fe 0d 01 01 .. ...$........ 0050 20 01 07 20 15 00 00 1b 02 0c 76 ff fe 6c 46 58 .. ......v..lFX 0060 11 00 00 01 00 00 00 05 13 c4 13 c4 06 ef 93 01 ................ 0070 49 4e 56 49 54 45 20 73 69 70 3a 5b 32 30 30 31 INVITE sip:[2001 0080 3a 37 32 30 3a 31 35 30 30 3a 31 62 3a 32 30 63 :720:1500:1b:20c 0090 3a 37 36 66 66 3a 66 65 36 63 3a 34 36 35 38 5d :76ff:fe6c:4658] 00a0 3a 35 30 36 30 3b 74 72 61 6e 73 70 6f 72 74 3d :5060;transport= 00b0 75 64 70 20 53 49 50 2f 32 2e 30 0d 0a 52 65 63 udp SIP/2.0..Rec 00c0 6f 72 64 2d 52 6f 75 74 65 3a 20 3c 73 69 70 3a ord-Route: <sip: 00d0 5b 32 30 30 31 3a 37 32 30 3a 31 35 30 30 3a 32 [2001:720:1500:2 00e0 34 3a 46 43 46 44 3a 46 46 3a 46 45 30 44 3a 31 4:FCFD:FF:FE0D:1 00f0 30 31 5d 3b 66 74 61 67 3d 31 32 31 32 32 33 34 01];ftag=1212234 0100 37 3b 6c 72 3d 6f 6e 3e 0d 0a 52 65 63 6f 72 64 7;lr=on>..Record 0110 2d 52 6f 75 74 65 3a 20 3c 73 69 70 3a 5b 32 30 -Route: <sip:[20 0120 30 31 3a 37 32 30 3a 31 35 30 30 3a 31 42 3a 46 01:720:1500:1B:F 0130 43 46 44 3a 46 46 3a 46 45 30 43 3a 31 30 33 5d CFD:FF:FE0C:103] 0140 3b 66 74 61 67 3d 31 32 31 32 32 33 34 37 3b 6c ;ftag=12122347;l 0150 72 3d 6f 6e 3e 0d 0a 52 65 63 6f 72 64 2d 52 6f r=on>..Record-Ro 0160 75 74 65 3a 20 3c 73 69 70 3a 5b 32 30 30 31 3a ute: <sip:[2001: 0170 37 32 30 3a 31 35 30 30 3a 31 41 3a 46 43 46 44 720:1500:1A:FCFD 0180 3a 46 46 3a 46 45 30 41 3a 31 30 33 5d 3b 66 74 :FF:FE0A:103];ft 0190 61 67 3d 31 32 31 32 32 33 34 37 3b 6c 72 3d 6f ag=12122347;lr=o 01a0 6e 3e 0d 0a 52 65 63 6f 72 64 2d 52 6f 75 74 65 n>..Record-Route 01b0 3a 20 3c 73 69 70 3a 5b 32 30 30 31 3a 37 32 30 : <sip:[2001:720 01c0 3a 31 35 30 30 3a 31 39 3a 46 43 46 44 3a 46 46 :1500:19:FCFD:FF 01d0 3a 46 45 30 45 3a 31 30 31 5d 3b 66 74 61 67 3d :FE0E:101];ftag= 01e0 31 32 31 32 32 33 34 37 3b 6c 72 3d 6f 6e 3e 0d 12122347;lr=on>. 01f0 0a 43 61 6c 6c 2d 49 44 3a 20 31 33 38 31 30 34 .Call-ID: 138104 0200 33 33 35 38 32 31 61 64 39 62 32 31 39 37 31 63 335821ad9b21971c 0210 37 64 36 30 35 39 62 36 63 38 40 5b 32 30 30 31 7d6059b6c8@[2001 0220 3a 37 32 30 3a 31 35 30 30 3a 31 61 3a 32 33 30 :720:1500:1a:230 0230 3a 31 62 66 66 3a 66 65 31 30 3a 35 66 62 33 5d :1bff:fe10:5fb3] 0240 0d 0a 43 53 65 71 3a 20 31 20 49 4e 56 49 54 45 ..CSeq: 1 INVITE 0250 0d 0a 46 72 6f 6d 3a 20 22 75 65 41 22 20 3c 73 ..From: "ueA" <s 0260 69 70 3a 75 65 41 40 64 6f 6d 61 69 6e 41 2e 61 ip:ueA@domainA.a 0270 6d 6d 69 2e 64 69 74 2e 75 70 6d 2e 65 73 3e 3b mmi.dit.upm.es>; 0280 74 61 67 3d 31 32 31 32 32 33 34 37 0d 0a 54 6f tag=12122347..To 0290 3a 20 3c 73 69 70 3a 75 65 43 40 64 6f 6d 61 69 : <sip:ueC@domai 02a0 6e 43 2e 61 6d 6d 69 2e 64 69 74 2e 75 70 6d 2e nC.ammi.dit.upm. 02b0 65 73 3e 0d 0a 56 69 61 3a 20 53 49 50 2f 32 2e es>..Via: SIP/2. 02c0 30 2f 55 44 50 20 5b 32 30 30 31 3a 37 32 30 3a 0/UDP [2001:720: 02d0 31 35 30 30 3a 32 34 3a 46 43 46 44 3a 46 46 3a 1500:24:FCFD:FF: 02e0 46 45 30 44 3a 31 30 31 5d 3b 62 72 61 6e 63 68 FE0D:101];branch 02f0 3d 7a 39 68 47 34 62 4b 31 32 30 35 2e 64 64 62 =z9hG4bK1205.ddb 0300 66 38 37 65 34 2e 30 0d 0a 56 69 61 3a 20 53 49 f87e4.0..Via: SI 0310 50 2f 32 2e 30 2f 55 44 50 20 5b 32 30 30 31 3a P/2.0/UDP [2001: 0320 37 32 30 3a 31 35 30 30 3a 31 42 3a 46 43 46 44 720:1500:1B:FCFD 0330 3a 46 46 3a 46 45 30 43 3a 31 30 33 5d 3b 62 72 :FF:FE0C:103];br 0340 61 6e 63 68 3d 7a 39 68 47 34 62 4b 31 32 30 35 anch=z9hG4bK1205 0350 2e 63 38 61 36 36 36 32 36 2e 30 0d 0a 56 69 61 .c8a66626.0..Via 0360 3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 20 5b 32 : SIP/2.0/UDP [2 0370 30 30 31 3a 37 32 30 3a 31 35 30 30 3a 31 42 3a 001:720:1500:1B: 0380 46 43 46 44 3a 46 46 3a 46 45 30 43 3a 31 30 32 FCFD:FF:FE0C:102 0390 5d 3b 62 72 61 6e 63 68 3d 7a 39 68 47 34 62 4b ];branch=z9hG4bK 03a0 31 32 30 35 2e 31 63 62 33 61 30 62 34 2e 30 0d 1205.1cb3a0b4.0. 03b0 0a 56 69 61 3a 20 53 49 50 2f 32 2e 30 2f 55 44 .Via: SIP/2.0/UD 03c0 50 20 5b 32 30 30 31 3a 37 32 30 3a 31 35 30 30 P [2001:720:1500 03d0 3a 31 41 3a 46 43 46 44 3a 46 46 3a 46 45 30 41 :1A:FCFD:FF:FE0A 03e0 3a 31 30 33 5d 3b 62 72 61 6e 63 68 3d 7a 39 68 :103];branch=z9h 03f0 47 34 62 4b 31 32 30 35 2e 34 34 33 34 34 66 30 G4bK1205.44344f0 0400 34 2e 30 0d 0a 56 69 61 3a 20 53 49 50 2f 32 2e 4.0..Via: SIP/2. 0410 30 2f 55 44 50 20 5b 32 30 30 31 3a 37 32 30 3a 0/UDP [2001:720: 0420 31 35 30 30 3a 31 39 3a 46 43 46 44 3a 46 46 3a 1500:19:FCFD:FF: 0430 46 45 30 45 3a 31 30 31 5d 3b 62 72 61 6e 63 68 FE0E:101];branch 0440 3d 7a 39 68 47 34 62 4b 31 32 30 35 2e 61 34 34 =z9hG4bK1205.a44 0450 65 33 62 33 34 2e 30 0d 0a 56 69 61 3a 20 53 49 e3b34.0..Via: SI 0460 50 2f 32 2e 30 2f 55 44 50 20 5b 32 30 30 31 3a P/2.0/UDP [2001: 0470 37 32 30 3a 31 35 30 30 3a 31 61 3a 32 33 30 3a 720:1500:1a:230: 0480 31 62 66 66 3a 66 65 31 30 3a 35 66 62 33 5d 3a 1bff:fe10:5fb3]: 0490 36 31 30 35 32 3b 62 72 61 6e 63 68 3d 7a 39 68 61052;branch=z9h 04a0 47 34 62 4b 34 30 65 31 38 34 34 35 31 32 61 32 G4bK40e1844512a2 04b0 33 34 65 33 32 36 65 66 38 32 32 32 66 38 62 32 34e326ef8222f8b2 04c0 30 34 66 62 0d 0a 4d 61 78 2d 46 6f 72 77 61 72 04fb..Max-Forwar 04d0 64 73 3a 20 31 32 0d 0a 43 6f 6e 74 61 63 74 3a ds: 12..Contact: 04e0 20 22 75 65 41 22 20 3c 73 69 70 3a 5b 32 30 30 "ueA" <sip:[200 04f0 31 3a 37 32 30 3a 31 35 30 30 3a 31 61 3a 32 33 1:720:1500:1a:23 0500 30 3a 31 62 66 66 3a 66 65 31 30 3a 35 66 62 33 0:1bff:fe10:5fb3 0510 5d 3a 36 31 30 35 32 3b 74 72 61 6e 73 70 6f 72 ]:61052;transpor 0520 74 3d 75 64 70 3e 0d 0a 50 2d 50 72 65 66 65 72 t=udp>..P-Prefer 0530 72 65 64 2d 49 64 65 6e 74 69 74 79 3a 20 22 75 red-Identity: "u 0540 65 41 22 20 3c 73 69 70 3a 75 65 41 40 64 6f 6d eA" <sip:ueA@dom 0550 61 69 6e 41 2e 61 6d 6d 69 2e 64 69 74 2e 75 70 ainA.ammi.dit.up 0560 6d 2e 65 73 3e 3b 74 61 67 3d 31 32 31 32 32 33 m.es>;tag=121223 0570 34 37 0d 0a 50 72 69 76 61 63 79 3a 20 6e 6f 6e 47..Privacy: non 0580 65 0d 0a 50 2d 41 63 63 65 73 73 2d 4e 65 74 77 e..P-Access-Netw 0590 6f 72 6b 2d 49 6e 66 6f 3a 20 33 47 50 50 2d 55 ork-Info: 3GPP-U 05a0 54 52 41 4e 2d 54 44 44 3b 75 74 72 61 6e 2d 63 TRAN-TDD;utran-c 05b0 65 6c 6c 2d 69 64 2d 33 67 70 70 3d 31 38 31 30 ell-id-3gpp=1810 05c0 38 36 0d 0a 41 6c 6c 6f 77 3a 20 49 4e 56 49 54 86..Allow: INVIT 05d0 45 2c 41 43 4b 2c 43 41 4e 43 45 4c 2c 42 59 45 E,ACK,CANCEL,BYE 05e0 2c 50 52 41 43 4b 2c 55 ,PRACK,U *********************************************************************** If you want the .cap file for open it with ethereal, ask it for me. Thanks for your help. ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

17 years, 11 months

Re: [Serusers] Problem with MTU size in SER with MIPv6.

by Jose Angel Calvo

I'm sorry for the delay, but we had to do a deliverable in this date, and it was imposible to answer before. >Could you try again after runing: >ulimit -c unlimited # you need bash for this >ser -f ser.cfg -w /tmp/ The parameter "unlimited" already was in this node, so I think this is not the problem. The scenario used in our test is the following: - There are two user terminals that are communicated by SIP Communicator program. The INVITE message (problematic paquet) travels through the nodes until it arrive at the Proxy node. In this node is the problem with the core shown in my previous message. We have MIPv6 in our scenario. In our case, we use mipv6-2.0.2 from http://www.mobile-ipv6.org/ . We have ubuntu with kernel 2.6.16.24 Next, i'll show you the configuration file in the Proxy node: ****************************************************************** # # P-CSCF # # ----------- global configuration parameters ------------------------ check_via=no # (cmd. line: -v) dns=yes # (cmd. line: -r) rev_dns=yes # (cmd. line: -R) fifo="/tmp/ser_fifo" listen="pcscf" # ------------------ module loading ---------------------------------- 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/textops.so" loadmodule "/usr/lib/ser/modules/xlog.so" # ----------------- setting module-specific parameters --------------- # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # ------------------------- 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; }; if (method=="REGISTER") { # Append the Path header # FIXME: "Require" and "Supported" issues append_hf("Path: <sip:term@pcscf.domainA.ammi.dit.upm.es;lr>\r\n"); append_hf("Require: path\r\n"); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (method != "REGISTER") { record_route(); }; if (loose_route()) { route(1); break; }; # forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP route(1); } route[1] { # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- if (!t_relay()) { sl_reply_error(); }; } **************************************************************** In the next message i'll show the packet INVITE that produces the error becuase. Otherwise, the message would be very big (>40 KB) and it would not be shown. Thanks. ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

17 years, 11 months

← Newer
1
...
4
5
6
7
8
9
10
...
26
Older →

Jump to page:

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 December 2006