sr-users March 2006

sr-users@lists.kamailio.org

223 participants
506 discussions

[Users] Mediaproxy visible IPs
by Chris Roberts 03 Mar '06

03 Mar '06

Heya, I'm trying to understand the logic in the python side of the media proxy. Specifically, I have a user with a public IP address that is behind NAT. This would seem to be okay, except for this check: elif not caller.signedInAddress and caller.local and address[0]==caller.visibleIP: self.signIn(caller, address, data) sender = 0 destination = called.address elif not called.signedInAddress and called.local and address[0]==called.visibleIP: self.signIn(called, address, data) sender = 1 destination = caller.address I don't really understand the logic of this. Reading some more source, local is defined if the SDP header has a local media stream setting in it's m= header, but I do not understand why this would affect this part of the peer logic. If I removed this local check, my mediaproxy would be able to match incoming RTP streams from users with public IP addresses (visibleIP == public IP) behind NAT to their RTPPeer correctly. But I need to understand the implications of doing this, or whether there might be a better way for me to go? Any suggestions? Cheers, Chris. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.1/273 - Release Date: 02/03/2006

1 0

[Users] NEW Functionalities in UAC module
by Bogdan-Andrei Iancu 03 Mar '06

03 Mar '06

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

1 0

Re: [Serusers] permission module
by Miklos Tirpak 03 Mar '06

03 Mar '06

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

1 0

[Users] Route found, but not able to forward call
by Florian Fainelli 03 Mar '06

03 Mar '06

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

2 2

[Serusers] serctl PID file exists error with 0.9.7-pre1
by Steve Blair 03 Mar '06

03 Mar '06

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

1 0

[Users] pseudovaribles in append_to_reply() not working
by Jose Antonio Garvayo 03 Mar '06

03 Mar '06

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

2 1

Re: [Serusers] how to let iptel ser forward an invite message with route header?
by fang tian 03 Mar '06

03 Mar '06

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.

1 0

[Serusers] how to let iptel ser forward an invite message with route header?
by fang tian 03 Mar '06

03 Mar '06

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. --

3 2

[Serusers] SEMS + G.729
by Tomasz Stafin 03 Mar '06

03 Mar '06

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

1 0

[Serusers] Visual Message Waiting indicator
by tdeillon＠cri74.org 03 Mar '06

03 Mar '06

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

2 2

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