sr-users June 2004

sr-users@lists.kamailio.org

176 participants
387 discussions

[Serusers] high delay for user behind nat
by R. Anton Raharja 28 Jun '04

28 Jun '04

case 1: when 2 different user behind nat box from 2 different network communicate nothings wrong, delay minimum and voice ok case 2: when 2 user behind nat box from the same network communicate delay was *sometime* not accpetable, voice jittered (but not often) lets say.. the condition were much worst than case no. 1 im using ser 0.8.12 tcp-non rtpproxy and nathelper ser.cfg standard rtpproxy+nathelper can anyone tell me whats goin on? and howto fix this delay and jittered voice? thx http://sleepless.ngoprek.org VoIP Rakyat: (0921) 20006

3 3

[Serusers]internal LAN-Client cant be called from outside
by Marco Achtziger 28 Jun '04

28 Jun '04

Hello, I'm an IT-Student from Würzburg and i'm working with SER for a project. My SER is running on my linux-router and is listening on my LAN on eth0 and on the internet on ppp0. My problem is, that i can make calls between two clients inside the LAN or between two clients who are located in the internet. If somebody from the internet wants to call somebody in the LAN or reverse i get a request timeout. Also when i want to call somebody who is registrated by a different provider i get a request timeout, after SER has send the trying message to the client. Can anybody give me a hint or are there better how-tos like the ones from iptel? Here is my configuration file. In this i did not do many changes to the original file, but i tried a lot. # # $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="80er.kicks-ass.net" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/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 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; }; # 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 record_route(); # loose-route processing if (loose_route()) { t_relay(); 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) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication if (!www_authorize("80er.kicks-ass.net", "subscriber")) { www_challenge("80er.kicks-ass.net", "0"); break; }; fix_nated_contact(); save("location"); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; # forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP fix_nated_contact(); if (!t_relay()) { sl_reply_error(); }; } regards Marco Achtziger -- Marco Achtziger Eichendorffstrasse 6 97218 Gerbrunn 0931/7052054 0163/2887780

2 1

RE: [Serusers] Mediaproxy | none of caller or called party is local
by dhiraj.2.bhuyan＠bt.com 28 Jun '04

28 Jun '04

Thanks Adrian. Its working now :) I missed the db_url bit for the domain module in ser.cfg Regards, Dhiraj -----Original Message----- From: Adrian Georgescu [mailto:ag@ag-projects.com] Sent: 16 June 2004 13:42 To: Bhuyan,D,Dhiraj,XSG1 R Cc: serusers(a)lists.iptel.org Subject: [Serusers] Mediaproxy | none of caller or called party is local Dhiraj, Mediaproxy is looking in From: and To: Make sure the domains of either user is in ser domain table Example: For user 1234(a)bt.com serctl domain add bt.com Adrian -------- Hello List, I am trying to set up the following senario - [kphone A]-----------[ser/mediaproxy A]---------------------[ser/mediaproxy B]-----------[kphone B] When I try to set up a call between the two ends, proxydispatcher complains that "none of the caller or called party is local. will not use mediaproxy". I am not using DNS SRV at the moment - instead will be using the default unix socket. Kphone A and B are registered respectively to ser/mediaproxy A and B respectively. Anybody has any hint where this thing might be failing? I tried to go through the code - but python is not one stronghold. How does the dispatcher decide whether "caller or called" party is local? Thanks for your help, Dhiraj Bhuyan Network Security Specialist, BT Exact Business Assurance Solutions Tel: +44 1473 643932 Mob: +44 7962 012145 Email: dhiraj.2.bhuyan at bt.com

3 2

RE: [Serusers] as5400 and ser
by CM Rahman 28 Jun '04

28 Jun '04

I am sorry, I didn't show how put the pot in my last email, here it is, dial-peer voice 150 voip description CCSi voip phone destination-pattern 9T progress_ind setup enable 3 session protocol sipv2 session target ipv4:216.236.160.11 codec g723r53 Answer to your question, without putting "isdn protocol-emulate network" I wasn't able to get PRI Layer 2 up. Any other suggestion? &*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&* C.M. Rahman Jr. CTO CCNP, MCSE Security "Secure your self by securing your System" CompTI Security Plus Certified CCS Internet http://www.ccsi.com 13704 Research Blvd. Building O-Suite 4 Austin, TX 78750 Tel: 512-257-2274 Ex: 115 -----Original Message----- From: Richard [mailto:mypop3mail@yahoo.com] Sent: Friday, June 25, 2004 4:11 PM To: CM Rahman; serusers(a)lists.iptel.org Subject: RE: [Serusers] as5400 and ser Don't know why you have the following two lines, isdn protocol-emulate network isdn incoming-voice modem Also you probably need a pots dial-peer... Cisco web site has some configuration samples. --- CM Rahman <cmrahman(a)ccsi.com> wrote: > Once I send a call via messenger, I don't hear > anything other side. But > after a while it disconnect. > > Here are the cisco config > > ****************************** > controller T1 7/0:3 > framing esf > pri-group timeslots 1-24 > description Prism Test > > *************************************** > interface Serial7/0:3:23 > no ip address > isdn switch-type primary-ni > isdn protocol-emulate network > isdn incoming-voice modem > isdn T310 180000 > no cdp enable > !*************************************** > > dial-peer voice 150 voip > description CCSi voip phone > destination-pattern 9T > session protocol sipv2 > session target ipv4:216.236.160.11 > codec g723r53 > > ***************************************** > > > > > *Feb 15 16:18:09.720: ISDN Se7/0:3:23 Q931: Applying > typeplan for > sw-type 0xD is 0x2 0x1, Called num 5122200090 > *Feb 15 16:18:09.720: ISDN Se7/0:3:23 Q931: TX -> > SETUP pd = 8 callref > = 0x002E > Bearer Capability i = 0x8090A2 > Standard = CCITT > Transer Capability = Speech > Transfer Mode = Circuit > Transfer Rate = 64 kbit/s > Channel ID i = 0xA98381 > Exclusive, Channel 1 > Called Party Number i = 0xA1, '5122200090' > Plan:ISDN, Type:National > *Feb 15 16:18:09.732: ISDN Se7/0:3:23 Q931: RX <- > CALL_PROC pd = 8 > callref = 0x802E > Channel ID i = 0xA98381 > Exclusive, Channel 1 > *Feb 15 16:20:17.967: ISDN Se7/0:3:23 Q931: TX -> > DISCONNECT pd = 8 > callref = 0x002E > Cause i = 0x8290 - Normal call clearing > *Feb 15 16:20:17.995: ISDN Se7/0:3:23 Q931: RX <- > RELEASE pd = 8 > callref = 0x802E > *Feb 15 16:20:17.995: ISDN Se7/0:3:23 Q931: TX -> > RELEASE_COMP pd = 8 > callref = 0x002E > > &*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&* > C.M. Rahman Jr. > CCNP, MCSE Security "Secure your self by securing > your System" > CompTI Security Plus Certified > CCS Internet > http://www.ccsi.com > 13704 Research Blvd. Building O-Suite 4 > Austin, TX 78750 > Tel: 512-257-2274 Ex: 115 > > -----Original Message----- > From: serusers-bounces(a)lists.iptel.org > [mailto:serusers-bounces@lists.iptel.org] On > Behalf Of Richard > Sent: Friday, June 25, 2004 3:27 AM > To: serusers(a)lists.iptel.org > Subject: RE: [Serusers] as5400 and ser > > If you check this page, > > http://www.cisco.com/en/US/tech/tk652/tk701/technologies_configuration_g > uide_chapter09186a00800eadfa.html > > PSTN error "63 Service or option unavailable" is > mapped to sip error "503 Service or option > unavailable" which is in the header of the message. > > Also the page shows why IP phone or PSTN generates > this and how proxy is supposed to do with it. Quote, > "The SIP gateway generates this response if it is > unable to process the request due to an overload or > maintenance problem. Upon receiving this response, > the > gateway initiates a graceful call disconnect and > clears the call. " > > Look like a pstn config issue. Use "debug isdn > q931", > "debug isdn q921" and "term mon" for further > debuging. > > Cheers, > Richard > > --- CM Rahman <cmrahman(a)ccsi.com> wrote: > > Looking through your cisco config file, I am > > guessing your E1 are not > > Pri. Ami I correct? I am dealing with a > channelized > > DS3 with T1 Pri. I > > will also share my config file after I can get the > > call routed. > > Currently I am getting this below. My > understanding > > is there is > > something wrong in the call going from cisco to > Pri > > trunk. Anybody can > > give me some clue, that will be great. > > > > > > > > 146.82.136.218:5060 -> 216.236.160.11:5060 > > SIP/2.0 503 Service Unavailable..Via: > SIP/2.0/UDP > > 216.236.160.11;branch=z9h > > G4bKc513.1c338976.0,SIP/2.0/UDP > > 65.70.207.66:8675..From: > > "pappusip(a)backup.c > > csi.com" > > > <sip:pappusip@backup.ccsi.com>;tag=c270cb2a9ab14343b72218adb808612 > > 4;epid=c91b05026b..To: > > > <sip:915125656553@backup.ccsi.com>;tag=E8186070-487. > > .Date: Tue, 15 Feb 2000 01:38:28 GMT..Call-ID: > > 9fef06800312431fbaa33d389f7d > > 3ac7@192.168.1.101..Server: > > Cisco-SIPGateway/IOS-12.x..CSeq: 1 > > INVITE..Allo > > w-Events: telephone-event..Content-Length: 0.... > > > > > > > > > > > > > &*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&* > > C.M. Rahman Jr. > > CTO > > CCNP, MCSE Security "Secure your self by > securing > > your System" > > CompTI Security Plus Certified > > CCS Internet > > http://www.ccsi.com > > 13704 Research Blvd. Building O-Suite 4 > > Austin, TX 78750 > > Tel: 512-257-2274 Ex: 115 > > > > > > -----Original Message----- > > From: Stephen Kingham > > [mailto:Stephen.Kingham@aarnet.edu.au] > > Sent: Thursday, June 24, 2004 11:56 PM > > To: CM Rahman > > Cc: serusers(a)lists.iptel.org > > Subject: Re: [Serusers] as5400 and ser > > > > Hi > > > > Along with several other we are putting together a > > SER implementation > > Tutorial for the R&E sector. > > > > We have a page up the the AS5300 and it may help > > you, also if anyone is > > interested in reviewing it? > > > > > http://www.aarnet.edu.au/events/conferences/2004/apan-questnet/sipworksh > > op/uas/ciscoas5300.html > > > > Regards > > > > Stephen > > > > CM Rahman wrote: > > > > >Anybody here using cisco as5400 for PSTN > > termination? I am having some > > >problem with call routing. If there are such > person > > will to help, > > please > === message truncated === __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

2 1

[Serusers] [BUG] rtpproxy relay packet to incorrect dst port ?
by jimmy huang 28 Jun '04

28 Jun '04

Hi all: I am trying ser + nat module + rtpproxy case 1 UA 1 ---------------NAT1------------------ser/rtpproxy-------------NAT2---------------------UA2 192.168.4.2 61.228.9.233 61.228.9.66 61.228.23.191 192.168.2.10 rtpproxy run as rtpproxy,UA1 call UA2 case 2 UA 1 ---------------NAT1------------------ser/rtpproxy-------------NAT2---------------------UA2 192.168.4.2 61.228.9.233 61.228.9.66 61.228.23.191 192.168.2.10 UA1 call UA2 rtpproxy -l "61.228.9.66/192.168.5.1" (bridge mode) In case 1,when UA1 send ACK ,UA1 start sends rtp packet . and UA2 still not send rtpproxy will send to the port which UA2 original request in his SDP (like 1034) Obviously it's not correctly, and will be discard by NAT2 but after UA2 start send rtp packet to rtpproxy , rtpproxy will fix the correct port to send UA1's packet to NAT2 so NAT2 will relay it to UA2 But in case 2, after UA2 start send rtp packet to rtpproxy,rtpproxy did not fix the correct port, so rtpproxy still send UA1's rtp packet to incorrect port to NAT2 and the packet is discard by NAT2 , UA2 can't receive UA1's rtp packet Is this a bug? or something i need to configure more correctly ? Can anyone give me any idea about these ? Thanks in advanced Jimmy

1 0

[Serusers] Radvision viaIP400 working with SER
by Stephen Kingham 28 Jun '04

28 Jun '04

Hi I was woundering if anyone had the Radvision viaIP 400 working with their SER Proxy Server and could share a howto? I have the MCU register it's self to the SIP Proxy Server with each of the conference numbers according to the serctl ul show. But calls to the MCU fail :-(, I have the log from the viaIP and an ngrep from the SIP Proxy server: It would appear that SER server is sending the call through to the Radvision, but the viaIP appears not to like something about the call and never responds back. I am also posting this problem to Radvision and will hope to get a solution and put together a howto guide. Extract from serctl ul show ...Record(0xbd7302f0)... domain: 'location' aor : '61262223595' ~~~Contact(0xbd730338)~~~ domain : 'location' aor : '61262223595' Contact: 'sip:203.22.212.248:5060;transport=UDP' Expires: 1785 q : 0.00 Call-ID: 'cb16d4f8-13c4-409f9da1-95c4-2cad' CSeq : 148 replic : 0 State : CS_SYNC Flags : 0 next : (nil) prev : (nil) ~~~/Contact~~~~ .../Record... 09:36:12 SIP |ADAP SIP: STACK-> ERROR - PARSER - SIP Parser Error : Unexpected '=', line 3, column 86 09:36:12 09:36:12 SIP |ADAP SIP: STACK-> ERROR - PARSER - Parse - Syntax Error - The parser didn't manage to read all the buffer 09:36:12 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderUdpSetMsg - Message 73731620 failed to be parsed 09:36:12 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderReceivedMsg - failed to build message - status = -1010 09:36:12 SIP |ADAP SIP: STACK-> ERROR - PARSER - SIP Parser Error : Unexpected '=', line 3, column 86 09:36:12 09:36:12 SIP |ADAP SIP: STACK-> ERROR - PARSER - Parse - Syntax Error - The parser didn't manage to read all the buffer 09:36:12 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderUdpSetMsg - Message 73733700 failed to be parsed 09:36:12 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderReceivedMsg - failed to build message - status = -1010 09:36:14 MCU |CPU&BUS Usage: 4.18 Time 395376814 09:36:14 09:36:14 SIP |ADAP SIP: STACK-> ERROR - PARSER - SIP Parser Error : Unexpected '=', line 3, column 86 09:36:14 09:36:14 SIP |ADAP SIP: STACK-> ERROR - PARSER - Parse - Syntax Error - The parser didn't manage to read all the buffer 09:36:14 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderUdpSetMsg - Message 73734740 failed to be parsed 09:36:14 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderReceivedMsg - failed to build message - status = -1010 09:36:18 SIP |ADAP SIP: STACK-> ERROR - PARSER - SIP Parser Error : Unexpected '=', line 3, column 86 09:36:18 09:36:18 SIP |ADAP SIP: STACK-> ERROR - PARSER - Parse - Syntax Error - The parser didn't manage to read all the buffer 09:36:18 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderUdpSetMsg - Message 73736820 failed to be parsed 09:36:18 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderReceivedMsg - failed to build message - status = -1010 09:36:22 SIP |ADAP SIP: STACK-> ERROR - PARSER - SIP Parser Error : Unexpected '=', line 3, column 86 09:36:22 09:36:22 SIP |ADAP SIP: STACK-> ERROR - PARSER - Parse - Syntax Error - The parser didn't manage to read all the buffer 09:36:22 SIP |ADAP SIP: STACK-> ERROR - MSGBUILD - TransportMsgBuilderUdpSetMsg - Message 73737860 failed to be parsed 203.22.212.248 is the Radvision MCU 192.94.63.28 is the SER 192.94.209.147 is a Cisco 7960 U 192.94.209.147:50255 -> 192.94.63.28:5060 INVITE sip:61262223595@192.94.63.28 SIP/2.0..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=003094c38857000418 c1b198-4e75c458..To: <sip:61262223595@192.94.63.28>..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 INVITE..User-Agent: CSCO/6..Contact: <sip:61262112676@192.94.209.147:5060> ..Expires: 180..Content-Type: application/sdp..Content-Length: 251..Accept: application/sdp....v=0..o=Cisco-SIPUA 21420 21544 IN IP4 192.94.209.147..s=SIP Call..c=IN IP4 192.94.209.147..t=0 0..m=aud io 26434 RTP/AVP 0 8 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. # U 192.94.63.28:5060 -> 192.94.209.147:5060 SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=003094c3885 7000418c1b198-4e75c458..To: <sip:61262223595@192.94.63.28>..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 INVITE..Server: Sip EXpress router (0.8.12 (i386/linux))..Content-L ength: 0..Warning: 392 192.94.63.28:5060 "Noisy feedback tells: pid=834 req_src_ip=192.94.209.147 req_src_port=50255 in_uri=sip:61262223595@192.94.63.28 out_uri=sip:203.22.212.248:5060;transport=UD P via_cnt==1".... # U 192.94.63.28:5060 -> 203.22.212.248:5060 INVITE sip:203.22.212.248:5060;transport=UDP SIP/2.0..Max-Forwards: 10..Record-Route: <sip:61262223595@192.94.63.28;ftag=003094c38857000418c1b198-4e75c458;lr=on>..Via: SIP/2.0/UDP 192.94.63.28;branc h=z9hG4bKb50f.22eda3f6.0..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=003094c38857000418c1b198-4e75c458..To : <sip:61262223595@192.94.63.28>..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 INVITE..User-Agent: CSCO/6..Contact: <sip:61262112676@192.94.209.147:5060>..Expires: 180..Con tent-Type: application/sdp..Content-Length: 251..Accept: application/sdp....v=0..o=Cisco-SIPUA 21420 21544 IN IP4 192.94.209.147..s=SIP Call..c=IN IP4 192.94.209.147..t=0 0..m=audio 26434 RTP/AVP 0 8 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. # U 192.94.63.28:5060 -> 192.94.209.147:5060 SIP/2.0 500 I'm terribly sorry, server error occured (1/SL)..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=00 3094c38857000418c1b198-4e75c458..To: <sip:61262223595@192.94.63.28>;tag=d66bc43ced006f1f8deae57b87432dea.0b76..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 INVITE..Server: Sip EXpress router (0.8.12 (i386/linux))..Content-Length: 0..Warning: 392 192.94.63.28:5060 "Noisy feedback tells: pid=834 req_src_ip=192.94.209.147 req_src_port=50255 in_uri=sip:61262223595@192.94 .63.28 out_uri=sip:203.22.212.248:5060;transport=UDP via_cnt==1".... ################################# U 192.94.209.147:50266 -> 192.94.63.28:5060 ACK sip:61262223595@192.94.63.28 SIP/2.0..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=003094c38857000418c1b 198-4e75c458..To: <sip:61262223595@192.94.63.28>;tag=d66bc43ced006f1f8deae57b87432dea.0b76..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 ACK..Content-Length: 0.... ##################################################### U 192.94.63.28:5060 -> 203.22.212.248:5060 INVITE sip:203.22.212.248:5060;transport=UDP SIP/2.0..Max-Forwards: 10..Record-Route: <sip:61262223595@192.94.63.28;ftag=003094c38857000418c1b198-4e75c458;lr=on>..Via: SIP/2.0/UDP 192.94.63.28;branc h=z9hG4bKb50f.22eda3f6.0..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=003094c38857000418c1b198-4e75c458..To : <sip:61262223595@192.94.63.28>..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 INVITE..User-Agent: CSCO/6..Contact: <sip:61262112676@192.94.209.147:5060>..Expires: 180..Con tent-Type: application/sdp..Content-Length: 251..Accept: application/sdp....v=0..o=Cisco-SIPUA 21420 21544 IN IP4 192.94.209.147..s=SIP Call..c=IN IP4 192.94.209.147..t=0 0..m=audio 26434 RTP/AVP 0 8 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. ########################################################################################################################################################################################################### ########################################################################################################## U 192.94.63.28:5060 -> 203.22.212.248:5060 INVITE sip:203.22.212.248:5060;transport=UDP SIP/2.0..Max-Forwards: 10..Record-Route: <sip:61262223595@192.94.63.28;ftag=003094c38857000418c1b198-4e75c458;lr=on>..Via: SIP/2.0/UDP 192.94.63.28;branc h=z9hG4bKb50f.22eda3f6.0..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=003094c38857000418c1b198-4e75c458..To : <sip:61262223595@192.94.63.28>..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 INVITE..User-Agent: CSCO/6..Contact: <sip:61262112676@192.94.209.147:5060>..Expires: 180..Con tent-Type: application/sdp..Content-Length: 251..Accept: application/sdp....v=0..o=Cisco-SIPUA 21420 21544 IN IP4 192.94.209.147..s=SIP Call..c=IN IP4 192.94.209.147..t=0 0..m=audio 26434 RTP/AVP 0 8 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. ########################################################################################################################################################################################################### ########################################################################################################################################################################################################### ########################################################################################################################################################################################################### # U 192.94.63.28:5060 -> 203.22.212.248:5060 INVITE sip:203.22.212.248:5060;transport=UDP SIP/2.0..Max-Forwards: 10..Record-Route: <sip:61262223595@192.94.63.28;ftag=003094c38857000418c1b198-4e75c458;lr=on>..Via: SIP/2.0/UDP 192.94.63.28;branc h=z9hG4bKb50f.22eda3f6.0..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=003094c38857000418c1b198-4e75c458..To : <sip:61262223595@192.94.63.28>..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 INVITE..User-Agent: CSCO/6..Contact: <sip:61262112676@192.94.209.147:5060>..Expires: 180..Con tent-Type: application/sdp..Content-Length: 251..Accept: application/sdp....v=0..o=Cisco-SIPUA 21420 21544 IN IP4 192.94.209.147..s=SIP Call..c=IN IP4 192.94.209.147..t=0 0..m=audio 26434 RTP/AVP 0 8 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. ########################################################################################################################################################################################################### ########################################################################################################################################################################################################### ######################################################################################################################################################################################################### U 192.94.63.28:5060 -> 203.22.212.248:5060 INVITE sip:203.22.212.248:5060;transport=UDP SIP/2.0..Max-Forwards: 10..Record-Route: <sip:61262223595@192.94.63.28;ftag=003094c38857000418c1b198-4e75c458;lr=on>..Via: SIP/2.0/UDP 192.94.63.28;branc h=z9hG4bKb50f.22eda3f6.0..Via: SIP/2.0/UDP 192.94.209.147:5060;branch=z9hG4bK51575cca..From: "Stephen Kingham 61 2 6211 2676" <sip:61262112676@192.94.63.28>;tag=003094c38857000418c1b198-4e75c458..To : <sip:61262223595@192.94.63.28>..Call-ID: 003094c3-88570007-61abc25d-05501a14@192.94.209.147..CSeq: 101 INVITE..User-Agent: CSCO/6..Contact: <sip:61262112676@192.94.209.147:5060>..Expires: 180..Con tent-Type: application/sdp..Content-Length: 251..Accept: application/sdp....v=0..o=Cisco-SIPUA 21420 21544 IN IP4 192.94.209.147..s=SIP Call..c=IN IP4 192.94.209.147..t=0 0..m=audio 26434 RTP/AVP 0 8 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:18 G729/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. ########################################################################################################################################################################################################### ########################################################################################################################################################################################################### ############################################################################################### -- Stephen Kingham, MIT, BSc, E&C Cert Project Manager and Consulting Engineer mailto:Stephen.Kingham@aarnet.edu.au Telephone +61 2 6222 3575 (office) +61 419 417 471 (mobile) Voice and Video over IP for The Australian Academic Research Network (AARNet) and http://www.aarnet.edu.au -- Stephen Kingham, MIT, BSc, E&C Cert Project Manager and Consulting Engineer mailto:Stephen.Kingham@aarnet.edu.au Telephone +61 2 6222 3575 (office) +61 419 417 471 (mobile) Voice and Video over IP for The Australian Academic Research Network (AARNet) and http://www.aarnet.edu.au

3 5

[Serusers] Re: Serusers Digest, Vol 14, Issue 31
by RaghavendraK 70574 27 Jun '04

27 Jun '04

Great and Thanks for a early response. regrads ragha ----- Original Message ----- From: serusers-request(a)lists.iptel.org Date: Sunday, June 27, 2004 6:00 pm Subject: Serusers Digest, Vol 14, Issue 31 > Send Serusers mailing list submissions to > serusers(a)lists.iptel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.iptel.org/mailman/listinfo/serusers > or, via email, send a message with subject or body 'help' to > serusers-request(a)lists.iptel.org > > You can reach the person managing the list at > serusers-owner(a)lists.iptel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Serusers digest..." > > > Today's Topics: > > 1. non-unique call id problem (Greg Fausak) > 2. Re: non-unique call id problem (GR S) > 3. Re: Download help (Andrei Pelinescu-Onciul) > 4. Re: Replacing URI (Andrei Pelinescu-Onciul) > 5. Re: non-unique call id problem (Andrei Pelinescu-Onciul) > 6. Re: aa - Application Agent (Andrei Pelinescu-Onciul) > 7. Re: setflag() clarification (Andrei Pelinescu-Onciul) > > > ------------------------------------------------------------------- > --- > > Message: 1 > Date: Sat, 26 Jun 2004 18:22:45 -0500 > From: Greg Fausak <greg(a)addabrand.com> > Subject: [Serusers] non-unique call id problem > To: serusers(a)lists.iptel.org > Message-ID: <BB1A78F0-C7C7-11D8-A098-000A95ACCFB2(a)addabrand.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > I am seeing non-unique call IDs from a UA. > SHould I reject a call if the Call-ID is not unique? Has > anyone else messed with this? It is a big accounting problem! > > -g > > > Greg Fausak > www.AddaBrand.com > (US) 469-546-1265 > > > > ------------------------------ > > Message: 2 > Date: Sun, 27 Jun 2004 01:35:47 -0700 (PDT) > From: GR S <gr_sh2003(a)yahoo.com> > Subject: Re: [Serusers] non-unique call id problem > To: Greg Fausak <greg(a)addabrand.com> > Cc: serusers(a)lists.iptel.org > Message-ID: <20040627083547.79042.qmail(a)web54007.mail.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Greg, > > We experienced similer problems when we tried to parallelly fork > calls thru our PSTN gateway. All the calls had same call-id, and > the only difference was the branch-id's in the via headers of the > forked calls. The gateway accepted only the first call and > rejected others. I asked about this in the sipping forum, and was > informed that it could be a bug in the implementation of the UA > server (PSTN gateways are UAS). The UAS has to consider branch- > id's for the transactions. AFAIK, for a proxy, it is the > combination of the Call-ID and the tags that uniquely identify the > dialog. (Request others to correct if i am wrong on this). Not > sure what exactly is your problem. > > Regards, > > Greg Fausak <greg(a)addabrand.com> wrote: > I am seeing non-unique call IDs from a UA. > SHould I reject a call if the Call-ID is not unique? Has > anyone else messed with this? It is a big accounting problem! > > -g > > Greg Fausak > > > Girish Gopinath <gr_sh2003(a)yahoo.com> > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >

1 0

[Serusers] aa - Application Agent
by Jev 27 Jun '04

27 Jun '04

At what stage in development is the Application Agent (aa)? Is there a functioning b2bua yet? Thanks! :) -Jev

2 1

[Serusers] Download help
by RaghavendraK 70574 27 Jun '04

27 Jun '04

Hi, I want to download the src from windows. Can please help me, i don't have cvs client on windows machine and my linux has not net connectivity. I have gone through the help, but setting the env to pserver can be done in unix kind of env. Please let me know if i can get any tar or gzip version of the src code. thanks N regards ragha

3 2

[Serusers] "ser dead subsys locked"
by linda xiao 25 Jun '04

25 Jun '04

Hello; I am new to SER. I have just installed the latest SER on my redhat linux 9 platform. when I call #service ser start it returns ok. when I call #service ser status it returns : "ser dead subsys locked" Can anyone elaberate how to reslove this issue? Thanks & regards Lynette __________________________________________________ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
39
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 June 2004