sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

Re: [Serusers] branch parameter
by Tuffy Dhawan 21 Dec '06

21 Dec '06

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

4 4

Re: [Users] How to get CDR in Openser
by Klaus Darilion 21 Dec '06

21 Dec '06

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

2 2

[Users] A question about cancels..
by nick 21 Dec '06

21 Dec '06

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

2 1

Re: [Serusers] Problem with MTU size in SER with MIPv6.
by Jose Angel Calvo 21 Dec '06

21 Dec '06

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

1 0

Re: [Serusers] Problem with MTU size in SER with MIPv6.
by Jose Angel Calvo 21 Dec '06

21 Dec '06

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

1 0

[Serusers] editing the location table.
by Natambu Obleton 21 Dec '06

21 Dec '06

I want to edit the mysql location table myself, but it seems that SER doesn't read the table everytime a call is received. How can I make it refresh this table? Right now if I stop and restart SER then it will load my new entries. Natambu Obleton Network Engineer FastTrack Communications nobleton(a)fasttrackcomm.net (970) 247-3366 office (970) 247-2426 fax

3 3

[Serusers] Maximum Time of the call
by Digital Tuffy 21 Dec '06

21 Dec '06

How can we restrict a user for the maximum time allowed for a call. _________________________________________________________________ Get up-to-date with movies, music and TV. Its happening on MSN Entertainment http://content.msn.co.in/Entertainment/Default

1 0

RE: [Serusers] editing the location table.
by Digital Tuffy 21 Dec '06

21 Dec '06

use serctl ul command only which will update location table as well as DATA in Memory which is in the form of linked lists etc. >From: "Natambu Obleton" <nobleton(a)fasttrackcomm.net> >To: <serusers(a)iptel.org> >Subject: [Serusers] editing the location table. >Date: Wed, 20 Dec 2006 11:13:01 -0700 > >I want to edit the mysql location table myself, but it seems that SER >doesn't read the table everytime a call is received. How can I make it >refresh this table? Right now if I stop and restart SER then it will load >my >new entries. > > > >Natambu Obleton > >Network Engineer > >FastTrack Communications > >nobleton(a)fasttrackcomm.net > >(970) 247-3366 office > >(970) 247-2426 fax > > > > > >_______________________________________________ >Serusers mailing list >Serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers _________________________________________________________________ Want to know what your favourite stars are up to? Catch the latest gossip in Bollywood on MSN Entertainment! http://content.msn.co.in/Entertainment/Default

1 0

Re: [Users] Delayed signalling?
by Jiri Kuthan 20 Dec '06

20 Dec '06

At 16:03 14/12/2006, samuel 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. Hard to say without more input what the cause may be. Indeed common suspects are DNS (or any other blocking operation, such as dataabse) or timers, but again it is hard to say without more input. If it is DNS or TCP-based blocking, it may be worthwhile trying genuine SER/ottendorf which is having IP blacklisting and DNS cachine in there -- this is indeed something which has been pressing us for a while. If it is timer system, then SER should address it it (it must be the latest ottendorf version though). If it is database that blocks itself and SER consequently too, you have to look at the database. (Even if SER would do something about it, it could do hardly better then sending a negative reply "DB unavailable"). -jiri >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 <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 >>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/

2 2

[Users] OT: network debugging
by Klaus Darilion 20 Dec '06

20 Dec '06

Hi! As SIP debugging often includes low-level network debugging I think this tutorial can give some valuable inputs how to debug network problems. http://penguin-it.co.il/presentations/BrainShare2006/Troubleshooting%20LAN%… regards klaus -- Klaus Darilion nic.at

5 6

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