sr-users March 2006

sr-users@lists.kamailio.org

223 participants
505 discussions

[Users] NEW Functionalities in UAC module

by Bogdan-Andrei Iancu

Hi, the UAC module from the devel branch includes new functionalities: - you may specify a password for encrypting the original FROM URI as saved as RR parameter. See the new module parameter "from_passwd" http://openser.org/docs/modules/1.1.x/uac.html#AEN9 - uac_replace_from() adds the display name if not present (so far it only replaced it).So, now you can set a display name if none was present. regards, Bogdan

18 years, 9 months

Re: [Serusers] permission module

by Miklos Tirpak

Hi Hakan, There was a bug in the postgres module in the last stable branch. I corrected it, so please update your source and recompile postgres module... Miklos Hakan YASTI wrote: > Hi Miklos, > > > I have added as you said. > > select * from trusted; > src_ip | proto | from_pattern > -------------+-------+---------------------- > 84.51.32.26 | udp | ^sip:902247654321@.* > (1 row) > > But it seems same. Could we see the log where the module is comparing > the parameters which are coming with sip message and the result of the > query ? > > ################### ser log #################### > > sertest# 3(71282) SIP Request: > 3(71282) method: <INVITE> > 3(71282) uri: <sip:02124440111@gi.com.tr;user=phone> > 3(71282) version: <SIP/2.0> > 3(71282) parse_headers: flags=1 > 3(71282) Found param type 232, <branch> = <z9hG4bKacAMoJdyS>; state=16 > 3(71282) end of header reached, state=5 > 3(71282) parse_headers: Via found, flags=1 > 3(71282) parse_headers: this is the first via > 3(71282) After parse_msg... > 3(71282) preparing to run routing scripts... > 3(71282) parse_headers: flags=128 > 3(71282) DEBUG:maxfwd:is_maxfwd_present: value = 70 > 3(71282) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 16 > 3(71282) parse_headers: flags=8 > 3(71282) DEBUG: add_param: tag=1c2131911325 > 3(71282) end of header reached, state=29 > 3(71282) grep_sock_info - checking if host==us: 9==10 && [gi.com.tr] == > [84.51.32.8] > 3(71282) grep_sock_info - checking if port 5060 matches port 5060 > 3(71282) grep_sock_info - checking if host==us: 9==9 && [gi.com.tr] == > [127.0.0.1] > 3(71282) grep_sock_info - checking if port 5060 matches port 5060 > 3(71282) grep_sock_info - checking if host==us: 9==10 && [gi.com.tr] == > [84.51.32.8] > 3(71282) grep_sock_info - checking if port 5060 matches port 5060 > 3(71282) grep_sock_info - checking if host==us: 9==9 && [gi.com.tr] == > [127.0.0.1] > 3(71282) grep_sock_info - checking if port 5060 matches port 5060 > 3(71282) val2str(): converting 84.51.32.26, 11 > 3(71282) PG[217] str2valp got string udp > 3(71282) PG[217] str2valp got string ^sip:902247654321@.* > 3(71282) NOT TRUSTED IP 3(71282) parse_headers: flags=4 > 3(71282) end of header reached, state=9 > 3(71282) DEBUG: get_hdr_field: <To> [40]; > uri=[sip:02124440111@gi.com.tr;user=phone] > 3(71282) DEBUG: to body [<sip:02124440111@gi.com.tr;user=phone> > ] > 3(71282) parse_headers: flags=-1 > 3(71282) get_hdr_field: cseq <CSeq>: <1> <INVITE> > 3(71282) DEBUG: get_hdr_body : content_length=244 > 3(71282) found end of header > 3(71282) check_via_address(84.51.32.26, 84.51.32.26, 1) > 3(71282) DEBUG:destroy_avp_list: destroying list 0x0 > 3(71282) receive_msg: cleaning up > 2(71281) SIP Request: > 2(71281) method: <ACK> > 2(71281) uri: <sip:02124440111@gi.com.tr;user=phone> > 2(71281) version: <SIP/2.0> > 2(71281) parse_headers: flags=1 > 2(71281) Found param type 232, <branch> = <z9hG4bKacAMoJdyS>; state=16 > 2(71281) end of header reached, state=5 > 2(71281) parse_headers: Via found, flags=1 > 2(71281) parse_headers: this is the first via > 2(71281) After parse_msg... > 2(71281) preparing to run routing scripts... > 2(71281) parse_headers: flags=4 > 2(71281) DEBUG: add_param: tag=26a82380ee921ee699cdfa26683b3165.871c > 2(71281) end of header reached, state=29 > 2(71281) DEBUG: get_hdr_field: <To> [82]; > uri=[sip:02124440111@gi.com.tr;user=phone] > 2(71281) DEBUG: to body [<sip:02124440111@gi.com.tr;user=phone>] > 2(71281) DEBUG: sl_filter_ACK : local ACK found -> dropping it! > 2(71281) DEBUG:destroy_avp_list: destroying list 0x0 > 2(71281) receive_msg: cleaning up > > > > ################# ngrep log #################### > > U 84.51.32.26:5060 -> 84.51.32.8:5060 > INVITE sip:02124440111@gi.com.tr;user=phone SIP/2.0..Via: SIP/2.0/UDP > 84.51.32.26;branch=z9hG4bKacAMoJdyS..Max-Forwards: 70..From: > "902247654321" <sip:9 > 02327654321(a)gi.com.tr>;tag=1c2131911325..To: > <sip:02124440111@gi.com.tr;user=phone>..Call-ID: > 1845810222fYtV@84.51.32.26..CSeq: 1 INVITE..Contact: <sip: > 902327654321(a)84.51.32.26>..Supported: > em,100rel,timer,replaces,path..Allow: > REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPD > > ATE..Session-Expires: 3600..Min-SE: 90..User-Agent: > Audiocodes-Sip-Gateway-MP-104 FXS/v.4.40.200.371..Content-Type: > application/sdp..Content-Length: 244 > ....v=0..o=AudiocodesGW 585174 818405 IN IP4 > 84.51.32.26..s=Phone-Call..c=IN IP4 84.51.32.26..t=0 0..m=audio 4000 > RTP/AVP 0 8 96..a=rtpmap:0 pcmu/8000.. > a=rtpmap:8 pcma/8000..a=rtpmap:96 telephone-event/8000..a=fmtp:96 > 0-15..a=ptime:20..a=sendrecv.. > # > U 84.51.32.8:5060 -> 84.51.32.26:5060 > SIP/2.0 403 ONLY REGISTERED USERS......Via: SIP/2.0/UDP > 84.51.32.26;branch=z9hG4bKacAMoJdyS..From: "902247654321" > <sip:902327654321@gi.com.tr>;tag=1c213 > 1911325..To: > <sip:02124440111@gi.com.tr;user=phone>;tag=26a82380ee921ee699cdfa26683b3165.871c..Call-ID: > 1845810222fYtV@84.51.32.26..CSeq: 1 INVITE..Serv > er: Sip EXpress router (0.9.3 (i386/freebsd))..Content-Length: > 0..Warning: 392 84.51.32.8:5060 "Noisy feedback tells: pid=71282 > req_src_ip=84.51.32.26 > req_src_port=5060 in_uri=sip:02124440111@gi.com.tr;user=phone > out_uri=sip:02124440111@gi.com.tr;user=phone via_cnt==1".... > # > U 84.51.32.26:5060 -> 84.51.32.8:5060 > ACK sip:02124440111@gi.com.tr;user=phone SIP/2.0..Via: SIP/2.0/UDP > 84.51.32.26;branch=z9hG4bKacAMoJdyS..Max-Forwards: 70..From: > "902247654321" <sip:9023 > 27654321(a)gi.com.tr>;tag=1c2131911325..To: > <sip:02124440111@gi.com.tr;user=phone>;tag=26a82380ee921ee699cdfa26683b3165.871c..Call-ID: > 1845810222fYtV(a)84.5 > 1.32.26..CSeq: 1 ACK..Contact: > <sip:902327654321@84.51.32.26>..Supported: > em,timer,replaces,path..Allow: > REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,P > RACK,REFER,INFO,SUBSCRIBE,UPDATE..User-Agent: > Audiocodes-Sip-Gateway-MP-104 FXS/v.4.40.200.371..Content-Length: 0.... > > > > > > > > > > ----- Original Message ----- From: "Miklos Tirpak" <miklos(a)iptel.org> > To: "Hakan YASTI" <hakanyasti(a)gmail.com> > Cc: <serusers(a)lists.iptel.org> > Sent: Thursday, March 02, 2006 3:54 PM > Subject: Re: [Serusers] permission module > > >> Hi Hakan, >> >> Try this value for from_patter without quotes: ^sip:902247654321@.* >> udp is correct for proto >> >> Miklos >> >> Hakan YASTI wrote: >> >>> Hi Miklos, >>> >>> It was output of ngrep -W byline, The original ngrep output is as below. >>> >>>> From fielad is like From: "902247654321" >>> >>> >>> <sip:902247654321@gi.com.tr>;tag=1c572128494. >>> >>> What I wonder is ; according to this invite what must be the proto >>> and from_pattern values to allow the call. >>> >>> >>> U 84.51.32.26:5060 -> 84.51.32.8:5060 >>> INVITE sip:02124440111@gi.com.tr;user=phone SIP/2.0..Via: >>> SIP/2.0/UDP 84.51.32.26;branch=z9hG4bKacGtOiLfA..Max-Forwards: >>> 70..From: "902247654321" <sip:9 >>> 02247654321(a)gi.com.tr>;tag=1c572128494..To: >>> <sip:02124440111@gi.com.tr;user=phone>..Call-ID: >>> 195110554Rsep@84.51.32.26..CSeq: 1 INVITE..Contact: <sip:90 >>> 2247654321(a)84.51.32.26>..Supported: >>> em,100rel,timer,replaces,path..Allow: >>> REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDAT >>> E..Session-Expires: 3600..Min-SE: 90..User-Agent: >>> Audiocodes-Sip-Gateway-MP-104 FXS/v.4.40.200.371..Content-Type: >>> application/sdp..Content-Length: 244.. >>> ..v=0..o=AudiocodesGW 484853 895184 IN IP4 >>> 84.51.32.26..s=Phone-Call..c=IN IP4 84.51.32.26..t=0 0..m=audio 4010 >>> RTP/AVP 0 8 96..a=rtpmap:0 pcmu/8000..a= >>> rtpmap:8 pcma/8000..a=rtpmap:96 telephone-event/8000..a=fmtp:96 >>> 0-15..a=ptime:20..a=sendrecv.. >>> # >>> U 84.51.32.8:5060 -> 84.51.32.26:5060 >>> SIP/2.0 403 ONLY REGISTERED USERS......Via: SIP/2.0/UDP >>> 84.51.32.26;branch=z9hG4bKacGtOiLfA..From: "902247654321" >>> <sip:902247654321@gi.com.tr>;tag=1c572 >>> 128494..To: >>> <sip:02124440111@gi.com.tr;user=phone>;tag=26a82380ee921ee699cdfa26683b3165.a215..Call-ID: >>> 195110554Rsep@84.51.32.26..CSeq: 1 INVITE..Server >>> : Sip EXpress router (0.9.3 (i386/freebsd))..Content-Length: >>> 0..Warning: 392 84.51.32.8:5060 "Noisy feedback tells: pid=70414 >>> req_src_ip=84.51.32.26 re >>> q_src_port=5060 in_uri=sip:02124440111@gi.com.tr;user=phone >>> out_uri=sip:02124440111@gi.com.tr;user=phone via_cnt==1".... >>> # >>> U 84.51.32.26:5060 -> 84.51.32.8:5060 >>> ACK sip:02124440111@gi.com.tr;user=phone SIP/2.0..Via: SIP/2.0/UDP >>> 84.51.32.26;branch=z9hG4bKacGtOiLfA..Max-Forwards: 70..From: >>> "902247654321" <sip:9022 >>> 47654321(a)gi.com.tr>;tag=1c572128494..To: >>> <sip:02124440111@gi.com.tr;user=phone>;tag=26a82380ee921ee699cdfa26683b3165.a215..Call-ID: >>> 195110554Rsep(a)84.51. >>> 32.26..CSeq: 1 ACK..Contact: >>> <sip:902247654321@84.51.32.26>..Supported: >>> em,timer,replaces,path..Allow: >>> REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRA >>> CK,REFER,INFO,SUBSCRIBE,UPDATE..User-Agent: >>> Audiocodes-Sip-Gateway-MP-104 FXS/v.4.40.200.371..Content-Length: 0.... >>> >>> ################ SER LOG ########### >>> 2(70414) val2str(): converting 84.51.32.26, 11 >>> 2(70414) PG[217] str2valp got string udp >>> 2(70414) PG[217] str2valp got string "90224765321" >>> 2(70414) NOT TRUSTED IP 2(70414) parse_headers: flags=4 >>> 2(70414) end of header reached, state=9 >>> 2(70414) DEBUG: get_hdr_field: <To> [40]; >>> uri=[sip:02124440111@gi.com.tr;user=phone] >>> 2(70414) DEBUG: to body [<sip:02124440111@gi.com.tr;user=phone> >>> >>> >>> Best Regards, >>> Hakan. >>> >>> >>> >>> >>> >>> >>> ----- Original Message ----- From: "Miklos Tirpak" <miklos(a)iptel.org> >>> To: "Hakan YASTI" <hakanyasti(a)gmail.com> >>> Cc: <serusers(a)lists.iptel.org> >>> Sent: Thursday, March 02, 2006 11:38 AM >>> Subject: Re: [Serusers] permission module >>> >>> >>>> Hi Hakan, >>>> >>>> Does the From header really look like this??? >>>> From: "902247654321" ;tag=1c681629589 >>>> >>>> It is incorrect, and of course the To and Contact headers are also >>>> incorrect. >>>> >>>> Miklos >>>> >>>> Hakan YASTI wrote: >>>> >>>>> Hi, >>>>> I am trying to use permissions module. At configuration side >>>>> everything seems ok. when an invite comes to ser, gets the source >>>>> ip of the invite and select a query from the trusted table. But >>>>> every time, when correlates the from_pattern and proto, they >>>>> mismatch ( I SUPPOSE ). Is there any trick at from_pattern ? I have >>>>> tried so many values like >>>>> .* , sip:.*,empty,^sip:.* and etc. Here is my ser.cfg, logs. >>>>> >>>>> Hakan. >>>>> >>>>> loadmodule "/usr/local/lib/ser/modules/permissions.so" >>>>> # -- permissions parameters -- # >>>>> >>>>> modparam("permissions", "db_url", >>>>> "postgres://xxxxx:xxxx@ip_address/xxxxx") >>>>> modparam("permissions", "db_mode", 0) >>>>> modparam("permissions", "trusted_table", "trusted") >>>>> modparam("permissions", "source_col", "src_ip") >>>>> modparam("permissions", "proto_col", "proto") >>>>> modparam("permissions", "from_col", "from_pattern") >>>>> >>>>> if (method=="INVITE") { >>>>> if (!allow_trusted()) { >>>>> log("THE IP ADDRESS IS NOT ALLOWED"); >>>>> sl_send_reply("403","ONLY REGISTERED USERS ALLOWED "); >>>>> break; >>>>> } >>>>> >>>>> >>>>> >>>>> ########### SER LOG ############# >>>>> >>>>> 2(69289) SIP Request: >>>>> 2(69289) method: >>>>> 2(69289) uri: >>>>> 2(69289) version: >>>>> 2(69289) parse_headers: flags=1 >>>>> 2(69289) Found param type 232, = ; state=16 >>>>> 2(69289) end of header reached, state=5 >>>>> 2(69289) parse_headers: Via found, flags=1 >>>>> 2(69289) parse_headers: this is the first via >>>>> 2(69289) After parse_msg... >>>>> 2(69289) preparing to run routing scripts... >>>>> 2(69289) parse_headers: flags=128 >>>>> 2(69289) DEBUG:maxfwd:is_maxfwd_present: value = 70 >>>>> 2(69289) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 16 >>>>> 2(69289) parse_headers: flags=8 >>>>> 2(69289) DEBUG: add_param: tag=1c681629589 >>>>> 2(69289) end of header reached, state=29 >>>>> 2(69289) grep_sock_info - checking if host==us: 9==10 && >>>>> [gi.com.tr] == [84.51.32.8] >>>>> 2(69289) grep_sock_info - checking if port 5060 matches port 5060 >>>>> 2(69289) grep_sock_info - checking if host==us: 9==9 && [gi.com.tr] >>>>> == [127.0.0.1] >>>>> 2(69289) grep_sock_info - checking if port 5060 matches port 5060 >>>>> 2(69289) grep_sock_info - checking if host==us: 9==10 && >>>>> [gi.com.tr] == [84.51.32.8] >>>>> 2(69289) grep_sock_info - checking if port 5060 matches port 5060 >>>>> 2(69289) grep_sock_info - checking if host==us: 9==9 && [gi.com.tr] >>>>> == [127.0.0.1] >>>>> 2(69289) grep_sock_info - checking if port 5060 matches port 5060 >>>>> 2(69289) val2str(): converting 84.51.32.26, 11 >>>>> 2(69289) PG[217] str2valp got string udp >>>>> 2(69289) PG[217] str2valp got string sip:90224765321@gi.com.tr >>>>> 2(69289) NOT TRUSTED IP 2(69289) parse_headers: flags=4 >>>>> 2(69289) end of header reached, state=9 >>>>> 2(69289) DEBUG: get_hdr_field: [40]; >>>>> uri=[sip:02124440111@gi.com.tr;user=phone] >>>>> 2(69289) DEBUG: to body [ >>>>> ] >>>>> 2(69289) parse_headers: flags=-1 >>>>> 2(69289) get_hdr_field: cseq : <1> >>>>> 2(69289) DEBUG: get_hdr_body : content_length=267 >>>>> 2(69289) found end of header >>>>> 2(69289) check_via_address(84.51.32.26, 84.51.32.26, 1) >>>>> 2(69289) DEBUG:destroy_avp_list: destroying list 0x0 >>>>> 2(69289) receive_msg: cleaning up >>>>> 3(69290) SIP Request: >>>>> 3(69290) method: >>>>> 3(69290) uri: >>>>> 3(69290) version: >>>>> 3(69290) parse_headers: flags=1 >>>>> 3(69290) Found param type 232, = ; state=16 >>>>> 3(69290) end of header reached, state=5 >>>>> 3(69290) parse_headers: Via found, flags=1 >>>>> 3(69290) parse_headers: this is the first via >>>>> 3(69290) After parse_msg... >>>>> 3(69290) preparing to run routing scripts... >>>>> 3(69290) parse_headers: flags=4 >>>>> 3(69290) DEBUG: add_param: tag=26a82380ee921ee699cdfa26683b3165.bcf6 >>>>> 3(69290) end of header reached, state=29 >>>>> 3(69290) DEBUG: get_hdr_field: [82]; >>>>> uri=[sip:02124440111@gi.com.tr;user=phone] >>>>> 3(69290) DEBUG: to body [] >>>>> 3(69290) DEBUG: sl_filter_ACK : local ACK found -> dropping it! >>>>> 3(69290) DEBUG:destroy_avp_list: destroying list 0x0 >>>>> 3(69290) receive_msg: cleaning up >>>>> >>>>> >>>>> >>>>> >>>>> ######### NGREP LOGS ################ >>>>> >>>>> U 84.51.32.26:5060 -> 84.51.32.8:5060 >>>>> INVITE sip:02124440111@gi.com.tr;user=phone SIP/2.0. >>>>> Via: SIP/2.0/UDP 84.51.32.26;branch=z9hG4bKaccQkWrLg. >>>>> Max-Forwards: 70. >>>>> From: "902247654321" ;tag=1c681629589. >>>>> To: . >>>>> Call-ID: *395527579dNhC(a)84.51.32.26.* >>>>> <mailto:395527579dNhC@84.51.32.26.> >>>>> CSeq: 1 INVITE. >>>>> Contact: . >>>>> Supported: em,100rel,timer,replaces,path. >>>>> Allow: >>>>> REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. >>>>> >>>>> Session-Expires: 3600. >>>>> Min-SE: 90. >>>>> User-Agent: Audiocodes-Sip-Gateway-MP-104 FXS/v.4.40.200.371. >>>>> Content-Type: application/sdp. >>>>> Content-Length: 267. >>>>> . >>>>> v=0. >>>>> o=AudiocodesGW 440639 653740 IN IP4 84.51.32.26. >>>>> s=Phone-Call. >>>>> c=IN IP4 84.51.32.26. >>>>> t=0 0. >>>>> m=audio 4010 RTP/AVP 18 8 96. >>>>> a=rtpmap:18 g729/8000. >>>>> a=fmtp:18 annexb=no. >>>>> a=rtpmap:8 pcma/8000. >>>>> a=rtpmap:96 telephone-event/8000. >>>>> a=fmtp:96 0-15. >>>>> a=ptime:40. >>>>> a=sendrecv. >>>>> >>>>> # >>>>> U 84.51.32.8:5060 -> 84.51.32.26:5060 >>>>> SIP/2.0 403 ONLY REGISTERED USERS..... >>>>> Via: SIP/2.0/UDP 84.51.32.26;branch=z9hG4bKaccQkWrLg. >>>>> From: "902247654321" ;tag=1c681629589. >>>>> To: ;tag=26a82380ee921ee699cdfa26683b3165.bcf6. >>>>> Call-ID: *395527579dNhC(a)84.51.32.26.* >>>>> <mailto:395527579dNhC@84.51.32.26.> >>>>> CSeq: 1 INVITE. >>>>> Server: Sip EXpress router (0.9.3 (i386/freebsd)). >>>>> Content-Length: 0. >>>>> Warning: 392 84.51.32.8:5060 "Noisy feedback tells: pid=69289 >>>>> req_src_ip=84.51.32.26 req_src_port=5060 >>>>> in_uri=sip:02124440111@gi.com.tr;user=phone >>>>> out_uri=sip:02124440111@gi.com.tr;user=phone via_cnt==1". >>>>> . >>>>> >>>>> # >>>>> U 84.51.32.26:5060 -> 84.51.32.8:5060 >>>>> ACK sip:02124440111@gi.com.tr;user=phone SIP/2.0. >>>>> Via: SIP/2.0/UDP 84.51.32.26;branch=z9hG4bKaccQkWrLg. >>>>> Max-Forwards: 70. >>>>> From: "902247654321" ;tag=1c681629589. >>>>> To: ;tag=26a82380ee921ee699cdfa26683b3165.bcf6. >>>>> Call-ID: *395527579dNhC(a)84.51.32.26.* >>>>> <mailto:395527579dNhC@84.51.32.26.> >>>>> CSeq: 1 ACK. >>>>> Contact: . >>>>> Supported: em,timer,replaces,path. >>>>> Allow: >>>>> REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. >>>>> >>>>> User-Agent: Audiocodes-Sip-Gateway-MP-104 FXS/v.4.40.200.371. >>>>> Content-Length: 0. >>>>> >>>>> ################################# >>>>> Tried another value for from_pattern... >>>>> >>>>> 3(69290) val2str(): converting 84.51.32.26, 11 >>>>> 3(69290) PG[217] str2valp got string udp >>>>> 3(69290) PG[217] str2valp got string "90224765321" >>>>> >>>>> >>>>> >>>>> select * from trusted; >>>>> src_ip | proto | from_pattern >>>>> -------------+-------+--------------- >>>>> 84.51.32.25 | udp | "90224765321" >>>>> 84.51.32.26 | udp | "90224765321" >>>>> (2 rows) >>>>> . >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Serusers mailing list >>>>> serusers(a)lists.iptel.org >>>>> http://lists.iptel.org/mailman/listinfo/serusers

18 years, 9 months

[Users] Route found, but not able to forward call

by Florian Fainelli

Hello all, I am progressing in my dynamic routing with lcr. I am able to make my calls being routed to a given gateway, but they are not forwarded at all, you will find below the error messages I get : 12(13607) SIP Request: 12(13607) method: <CANCEL> 12(13607) uri: <sip:60957512@213.161.196.133> 12(13607) version: <SIP/2.0> 12(13607) parse_headers: flags=2 12(13607) header field type 8, name=<Max-Forwards>, body=<10> 12(13607) Found param type 232, <branch> = <1>; state=16 12(13607) end of header reached, state=5 12(13607) parse_headers: Via found, flags=2 12(13607) parse_headers: this is the first via 12(13607) header field type 1, name=<Via>, body=<SIP/2.0/UDP 157.159.80.57:5060;branch=1> 12(13607) first via: <SIP/2.0/UDP> <157.159.80.57:5060(5060)>12(13607) ;<>12(13607) 12(13607) exiting parse_msg 12(13607) After parse_msg... 12(13607) preparing to run routing scripts... 12(13607) DEBUG:maxfwd:is_maxfwd_present: value = 10 12(13607) parse_headers: flags=200 12(13607) header field type 4, name=<From>, body=<<sip:157.159.80.57>;tag=044864755209883246007508179717> 12(13607) DEBUG:parse_to:end of header reached, state=9 12(13607) DEBUG: get_hdr_field: <To> [32]; uri=[sip:60957512@213.161.196.133] 12(13607) DEBUG: to body [<sip:60957512@213.161.196.133> ] 12(13607) header field type 3, name=<To>, body=<<sip:60957512@213.161.196.133>> 12(13607) header field type 7, name=<Contact>, body=<<sip:157.159.80.57>> 12(13607) header field type 26, name=<User-Agent>, body=<TELES.VoIPBOX 10.0 #302> 12(13607) header field type 6, name=<Call-ID>, body=<000688355273195645908699556113(a)157.159.80.57> 12(13607) get_hdr_field: cseq <CSeq>: <1> <CANCEL> 12(13607) header field type 5, name=<CSeq>, body=<1 CANCEL> 12(13607) header field type 19, name=<Allow>, body=<INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER> 12(13607) DEBUG: get_hdr_body : content_length=0 12(13607) header field type 12, name=<Content-Length>, body=<0> 12(13607) found end of header 12(13607) find_first_route: No Route headers found 12(13607) loose_route: There is no Route HF 12(13607) parsed uri: type=1 user=<60957512>(8) passwd=<>(0) host=<213.161.196.133>(15) port=<>(0): 0 params=<>(0) headers=<>(0) 12(13607) uri params: transport=<>, val=<>, proto=0 12(13607) user-param=<>, val=<> 12(13607) method=<>, val=<> 12(13607) ttl=<>, val=<> 12(13607) maddr=<>, val=<> 12(13607) lr=<> 12(13607) DEBUG: add_param: tag=044864755209883246007508179717 12(13607) DEBUG:parse_to:end of header reached, state=29 12(13607) load_gws(): DEBUG: Added gw_uri_avp <sip:@82.138.76.138:5060;transport=tcp> 12(13607) DEBUG:destroy_avp_list: destroying list 0xb5c01f10 12(13607) receive_msg: cleaning up Thanks in advance for your answers. -- Cordialement, Florian Fainelli --------------------------------------- 5, rue Charles Fourier Chambre 1511 91011 Evry http://www.alphacore.net (+33) 01 60 76 64 86 (+33) 06 09 02 64 95 ---------------------------------------- Institut National des Télécomnications http://www.int-evry.fr/telecomint ----------------------------------------

18 years, 9 months

[Serusers] serctl PID file exists error with 0.9.7-pre1

by Steve Blair

starting SER 0.9.7-pre1 with serctl results in the PID file exists error. SER will start with the command ser -d -E -f <config file>. Any thoughts on what might be wrong? Thanks,Steve -- ISC Network Engineering The University of Pennsylvania 3401 Walnut Street, Suite 221A Philadelphia, PA 19104 voice: 215-573-8396 215-746-8001 fax: 215-898-9348 sip:blairs@net.isc.upenn.edu

18 years, 9 months

[Users] pseudovaribles in append_to_reply() not working

by Jose Antonio Garvayo

Hi, I am experiencing a problem with pseudovariables in append_to_reply(), seems like they are not being replaced with the real value. In openser.cfg, I am using this: append_to_reply("P-Hint: $Ri : $Rp \r\n"); But I am receiving this: ... P-Hint: $Ri : $Rp Server: OpenSer (1.0.1 (i386/linux)) ... I tried also the same in a append_hf() with the same result, the pseudovariables are not working. I am using openser 1.0.1 in linux, does anyone have any clue on this? Thanks a lot

18 years, 9 months

Re: [Serusers] how to let iptel ser forward an invite message with route header?

by fang tian

Ladislav, the problem is ,if I didn't add these two route headers,the application server will do a DNS lookup,which is more than 30 seconds. I also want to make Iptel ser looks like a S-CSCF which defined in 3GPP standard. thanks Fang tian. On 3/3/06, Ladislav Andel <ladia6(a)centrum.cz> wrote: > > As far as I know you don't need to add any route header in this case. On > the top of SIP message is VIA header which says which > way your application server should answer back.. > > Route header is used when you have more proxies in the way where the > message you want to route through > > from RFC 3261: > > The Route header field is used to force routing for a request through > the listed set of proxies. Examples of the use of the Route header > field are in Section 16.12.1. > > Example: > > Route: <sip:bigbox3.site3.atlanta.com;lr>, > <sip:server10.biloxi.com;lr> > > Can anybody confirm? > > Ladislav > > fang tian wrote: > > Hi , > > I am a new user of iptel ser,I want to make this configuration > > > > UE1,2,3,4<---------->IPtel ser > > <---------------------------------->application server , > > > > the UEs send out invite request to iptel ser first ,I want to make > > iptel ser forward this request to application server with two route > > header added: > > route:application server :5060 > > route:iptel ser :5060 > > > > so the application server can send this request back to iptel ser. > > > > your kindly help is appreciated ,thanks > > > > RGS > > tian. > > > > > > > > -- > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > > -- Best regards Fang Tian.

18 years, 9 months

[Serusers] how to let iptel ser forward an invite message with route header?

by fang tian

Hi , I am a new user of iptel ser,I want to make this configuration UE1,2,3,4<---------->IPtel ser <---------------------------------->application server , the UEs send out invite request to iptel ser first ,I want to make iptel ser forward this request to application server with two route header added: route:application server :5060 route:iptel ser :5060 so the application server can send this request back to iptel ser. your kindly help is appreciated ,thanks RGS tian. --

18 years, 9 months

[Serusers] SEMS + G.729

by Tomasz Stafin

Hi again I have another problem with SEMS. It works fine with codec G.711 but I'd like to use codec G.729. Of course I'd like to buy a licence but I don't know how to do it and if SEMS work with codec G.729. If anyone use this codec with SEMS please help me to configure SEMS with it. Thanks for any help. Swaper

18 years, 9 months

[Serusers] Visual Message Waiting indicator

by tdeillon＠cri74.org

Dear all, I use: - ser as proxy, registrar and redirect server. - asterisk as gateway and voicemail server. But my problem is that I don't have the "Visual Message Waiting indicator" on my phones. Do you have a idea for me ? Best regards, Thomas

18 years, 9 months

Re: [Serusers] rtpproxy

by Andrey Kouprianov

Sorry guy for the russian language here.... Vitaliy, privet! Ya iz Thailanda... Tochnee kak, zhivu i rabotayu tut (po krainei mere poka), a voobshe iz Moskvy. Zanimayus' razrabotkoi SIP clienta dlya E-learning na Jave. Poka dlya PC i laptopov, a potom nado vayat' analogichnuyu progu na PDA i mobil'niye telefony. Priyatno poznakomitsya :)) Andrey. On 3/3/06, Vitaly Nikolaev <vnikolaev(a)intermedia.net> wrote: > Ahh... :) netuda :) > > A ti otkuda takoi znauchii kstati ? :) > > > -----Original Message----- > From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On > Behalf Of Andrey Kouprianov > Sent: Thursday, March 02, 2006 12:09 PM > To: serusers(a)lists.iptel.org > Subject: Re: [Serusers] rtpproxy > > Im not sure about it, cause I never had chance to play with PSTN > numbers properly. There's something about DID's on page 58 of the > document. > > On 3/3/06, roger leszczynski <rogerles(a)gmail.com> wrote: > > i found it, thanks, now the question is, say i have 100 concurrent > calls, > > and i want to update the configuration with a new DID, how can i avoid > > restarting SER to make these changes take places....has anyone made a > > similar module to reload in asterisk? Or how can i go about using a > > database to implement routing instead? > > > > > > On 3/2/06, Andrey Kouprianov <andrey.kouprianov(a)gmail.com > wrote: > > > > > would "getting started" document from www.onsip.org help? they have a > > good explanation on how to configure SER with RTPProxy... > > > > On 3/2/06, roger leszczynski <rogerles(a)gmail.com> wrote: > > > Anyone use the rtp proxy module yet? I am looking to proxy rtp of > my > > > carrier who sends out calls to me, so if anyone has example > configurations > > > that work i would appreciate it! > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers >

18 years, 9 months

← Newer
1
...
42
43
44
45
46
47
48
...
51
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 March 2006