sr-users

sr-users@lists.kamailio.org

4 participants
37456 discussions

[Users] Cisco Gateway Disconnects the call
by Hamid Ali Asgari 12 Jul '06

12 Jul '06

Hi, Here comes the dump from ngrep for a sample call. Any idea what's wrong? Thanks, Hamid10.30.30.19: Cisco Gateway 10.30.30.18: OpenSER 192.168.11.102: UA # # U 10.30.30.19:5060 -> 10.30.30.18:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.30.30.18;branch=0,SIP/2.0/UDP 192.168.11.102:5060;branch=z9hG4bK10145. From: 102(a)mydomain.com <sip:102@mydomain.com>;tag=analog-sip28734. To: 0098146 <sip:0098146@mydomain.com>;tag=9A65C-1F0E. Date: Fri, 01 Mar 2002 00:10:32 GMT. Call-ID: 32268(a)192.168.11.102. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 101 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:0098146@10.30.30.19:5060>. Record-Route: <sip:10.30.30.18;ftag=analog-sip28734;lr=on>. Content-Type: application/sdp. Content-Length: 252. . v=0. o=CiscoSystemsSIP-GW-UserAgent 6865 4884 IN IP4 10.30.30.19. s=SIP Call. c=IN IP4 10.30.30.19. t=0 0. m=audio 16400 RTP/AVP 18 103. c=IN IP4 10.30.30.19. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:103 telephone-event/8000. a=fmtp:103 0-15. # U 10.30.30.18:5060 -> 192.168.11.102:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.11.102:5060;branch=z9hG4bK10145. From: 102(a)mydomain.com <sip:102@mydomain.com>;tag=analog-sip28734. To: 0098146 <sip:0098146@mydomain.com>;tag=9A65C-1F0E. Date: Fri, 01 Mar 2002 00:10:32 GMT. Call-ID: 32268(a)192.168.11.102. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 101 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:0098146@10.30.30.19:5060>. Record-Route: <sip:10.30.30.18;ftag=analog-sip28734;lr=on>. Content-Type: application/sdp. Content-Length: 252. . v=0. o=CiscoSystemsSIP-GW-UserAgent 6865 4884 IN IP4 10.30.30.19. s=SIP Call. c=IN IP4 10.30.30.19. t=0 0. m=audio 16400 RTP/AVP 18 103. c=IN IP4 10.30.30.19. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:103 telephone-event/8000. a=fmtp:103 0-15. # U 192.168.11.102:5060 -> 10.30.30.18:5060 ACK sip:10.30.30.18;ftag=analog-sip28734;lr SIP/2.0. Via: SIP/2.0/UDP 192.168.11.102:5060;branch=z9hG4bK9072. To: 0098146 <sip:0098146@mydomain.com>;tag=9A65C-1F0E. From: 102(a)mydomain.com <sip:102@mydomain.com>;tag=analog-sip28734. Call-ID: 32268(a)192.168.11.102. CSeq: 101 ACK. Route:<sip:0098146@mydomain.com>. Contact: <sip:102@192.168.11.102:5060>. Max-Forwards: 70. Content-Length: 0. . # ***** [Remaining retries omitted .] # U 10.30.30.19:55584 -> 10.30.30.18:5060 BYE sip:102@192.168.11.102:5060 SIP/2.0. Via: SIP/2.0/UDP 10.30.30.19:5060;branch=z9hG4bK11BD8. From: 0098146 <sip:0098146@mydomain.com>;tag=9A65C-1F0E. To: 102(a)mydomain.com <sip:102@mydomain.com>;tag=analog-sip28734. Date: Fri, 01 Mar 2002 00:10:32 GMT. Call-ID: 32268(a)192.168.11.102. User-Agent: Cisco-SIPGateway/IOS-12.x. Max-Forwards: 70. Route: <sip:10.30.30.18;ftag=analog-sip28734;lr=on>. Timestamp: 1014941453. CSeq: 101 BYE. Content-Length: 0. . # U 10.30.30.18:5060 -> 192.168.11.102:5060 BYE sip:102@192.168.11.102:5060 SIP/2.0. Record-Route: <sip:10.30.30.18;ftag=9A65C-1F0E;lr=on>. Via: SIP/2.0/UDP 10.30.30.18;branch=z9hG4bK6b5f.4db3aed2.0. Via: SIP/2.0/UDP 10.30.30.19:5060;branch=z9hG4bK11BD8. From: 0098146 <sip:0098146@mydomain.com>;tag=9A65C-1F0E. To: 102(a)mydomain.com <sip:102@mydomain.com>;tag=analog-sip28734. Date: Fri, 01 Mar 2002 00:10:32 GMT. Call-ID: 32268(a)192.168.11.102. User-Agent: Cisco-SIPGateway/IOS-12.x. Max-Forwards: 69. Timestamp: 1014941453. CSeq: 101 BYE. Content-Length: 0. P-hint: rr-enforced. . # U 192.168.11.102:5060 -> 10.30.30.18:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.30.30.18;branch=z9hG4bK6b5f.4db3aed2.0,SIP/2.0/UDP 10.30.30.19:5060;branch=z9hG4bK11BD8. To: 102(a)mydomain.com <sip:102@mydomain.com>;tag=analog-sip28734. From: 0098146 <sip:0098146@mydomain.com>;tag=9A65C-1F0E. Call-ID: 32268(a)192.168.11.102. CSeq: 101 BYE. Record-Route:<sip:10.30.30.18;ftag=9A65C-1F0E;lr>. Content-Length: 0. . # U 10.30.30.18:5060 -> 10.30.30.19:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.30.30.19:5060;branch=z9hG4bK11BD8. To: 102(a)mydomain.com <sip:102@mydomain.com>;tag=analog-sip28734. From: 0098146 <sip:0098146@mydomain.com>;tag=9A65C-1F0E. Call-ID: 32268(a)192.168.11.102. CSeq: 101 BYE. Record-Route:<sip:10.30.30.18;ftag=9A65C-1F0E;lr>. Content-Length: 0.

2 1

[Users] t_relay() to a destination set by dispatcher
by Radu Maierean 12 Jul '06

12 Jul '06

hi all, i need to use the dispatcher module to route (load-balanced) an incoming SIP request to one of my bunch of asterisk machines. openser (1.1.0, the only one that implements the dispatcher as i need it) is also supposed to translate from TCP (the protocol that my peer gateway uses) to UDP (the only protocol that asterisk knows - snip). my attempt was this: # routing INVITE and CANCEL messages received from the gateway to Asterisk if (uri=~"^sip:\+1[0-9]+@xx\.xx\.xx\.xx") { t_on_failure("2"); if ((method=="INVITE") || (method=="CANCEL")) { ds_select_dst("1", "0"); t_relay("udp:$dd:5061"); return; } } note that t_relay() must change the protocol type and set a non-default port number. the problem is that the $dd pseudovariable in t_relay() is not parsed, i actually get an error at openser startup: Jul 11 14:43:31 davinci /usr/local/sbin/openser[16906]: ERROR: mk_proxy: could not resolve hostname: "$dd" Jul 11 14:43:31 davinci /usr/local/sbin/openser[16906]: ERROR:tm:fixup_phostport2proxy: failed to resolve <$dd> Jul 11 14:43:31 davinci /usr/local/sbin/openser[16906]: ERROR: fix_actions: fixing failed (code=-478) at cfg line 119 anybody has any idea about how can i either: (A) set the preferred protocol and destination port for the transaction, then call t_relay() with no arguments, OR (B) capture the destination domain name selected by the dispatcher in a variable, append "udp:" in front of it and ":5061" at the end, and feed it as argument to t_relay(). a hint would be great, a few lines of code would be even better ;) since i have some trouble locating the documentation for the core functions. thanks! Radu M.

3 2

[Users] MySQL problem under 1.1.0
by Britton Payne 12 Jul '06

12 Jul '06

Hello all, I've recently upgraded from 1.0.0 cvs to 1.1.0 release and the db functions have seemed to quit working. [bp@boognish openser]$ /usr/sbin/openserctl lcr show WARINIG: no database engine found - tried '' This command requires a database engine - none was loaded It seems like loadmodule "/usr/lib/openser/modules/mysql.so" in openser.cfg isn't doing the trick anymore. I have used openser_mysql.sh to reinstall the databases, which are in the default places. Any ideas what's going on? Britton

2 1

RE: [Serusers] prevent INVITE without REGISTERing
by İlker Aktuna (Koç.net) 12 Jul '06

12 Jul '06

Thanks, That configuration is accepted but now my "registered" client is denied at both following lines: if (!lookup_user("From")) { if ((!avp_equals_xl("$registered_host", "%si") || !avp_equals_xl("$registered_port", "%sp"))) { How can I print $registered_host to log ? I can print %si with xlog(). Thanks, ilker -----Original Message----- From: Miklos Tirpak [mailto:miklos@iptel.org] Sent: Wednesday, July 12, 2006 4:01 PM To: İlker Aktuna (Koç.net) Cc: serusers(a)iptel.org Subject: Re: [Serusers] prevent INVITE without REGISTERing İlker Aktuna (Koç.net) wrote: > > > Thanks Miklos, > > I think this is just what I'm looking for. > But I get some errors for this line: > if ((src_ip != @ruri.host) || (src_port != @ruri.port)) { You can access src_ip and src_port via xl_lib: $registered_host = @ruri.host; $registered_port = @ruri.port; if ((!avp_equals_xl("$registered_host", "%si")) || (!avp_equals_xl("$registered_port", "%sp"))) { ... Miklos > > 0(30074) parse error (175,16-17): syntax error > 0(30074) parse error (175,16-17): ip address or hostname expected > 0(30074) parse error (175,16-17): bad command > 0(30074) parse error (175,21-22): bad command > 0(30074) parse error (175,21-22): bad command > 0(30074) parse error (175,26-27): bad command > 0(30074) parse error (175,26-27): bad command > 0(30074) parse error (175,28-30): bad command > 0(30074) parse error (175,31-32): bad command > 0(30074) parse error (175,32-40): bad command > 0(30074) parse error (175,41-43): bad command > 0(30074) parse error (175,44-45): bad command > 0(30074) parse error (175,49-50): bad command > 0(30074) parse error (175,49-50): bad command > 0(30074) parse error (175,54-55): bad command > 0(30074) parse error (175,54-55): bad command > 0(30074) parse error (175,55-56): bad command > 0(30074) parse error (175,57-58): bad command > > Any idea why ? > > Thanks, > ilker > > -----Original Message----- > From: Miklos Tirpak [mailto:miklos@iptel.org] > Sent: Wednesday, July 12, 2006 11:58 AM > To: İlker Aktuna (Koç.net) > Cc: serusers(a)iptel.org > Subject: Re: [Serusers] prevent INVITE without REGISTERing > > Hi Ilker, > > just my first idea, not tested: > > > 1. lookup the From HF > > if (!lookup_user("From")) { > # reject the INVITE > ... > } > > 2. save original To UID and Request URI > > $orig_to_uid = $tu.uid; > $orig_req_uri = @ruri; > > 3. set To UID -- registrar module will use this in the lookup > > $tu.uid = $fu.uid; > > 4. lookup From HF and compare the source address of the INVITE with > the source address of the REGISTER message > > if (lookup("location")) { > if ((src_ip != @ruri.host) || (src_port != @ruri.port)) { > # reject the INVITE > ... > } > # restore original To UID and Request URI > $tu.uid = $orig_to_uid; > attr2uri("$orig_req_uri"); > } else { > # reject the INVITE > ... > } > > Note, that the above solution is a bit ugly, you can get into troubles > when the user registers multiple contact addresses. It is better to > disable branches (see append_branches parameter in registrar module), > but you loose some functionality. > > Regards, > Miklos > > İlker Aktuna (Koç.net) wrote: > > > > Hi everyone, > > > > I am still trying to find a solution to this problem. (but couldn't > > find > yet) > Victor was trying to help me but I think he's not > able to reply these days. > > > > Is there any idea to achieve what I need. > > > > Thanks, > > ilker > > > > > ---------------------------------------------------------------------- > > -- > > *From:* serusers-bounces(a)lists.iptel.org > > [mailto:serusers-bounces@lists.iptel.org] *On Behalf Of *İlker Aktuna > > (Koç.net) > *Sent:* Tuesday, July 11, 2006 1:41 PM > *To:* Victor > Stanescu > *Cc:* serusers(a)iptel.org > *Subject:* RE: [Serusers] > prevent INVITE without REGISTERing > > Hi, > > What if my proxy > does not handle authenticating INVITE messages ? > > > > In that case I think the best way is to lookup location table for > the > source URI. > > If the source URI location matches the location in that table then > we > must permit INVITE message. > > How can I configure this ? > > > > Thanks, > > ilker > > > > -----Original Message----- > > From: serusers-bounces(a)lists.iptel.org > > [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Victor Stanescu > > Sent: Monday, July 10, 2006 1:49 PM > Cc: serusers(a)iptel.org > > Subject: Re: [Serusers] prevent INVITE without REGISTERing > > > Please read "domain" instead of "gtstelecom.ro": > > www_authorize("domain", > > "subscriber") and proxy_authorize("domain", "subscriber"), > otherwise > the code fragment will not be correct. I forgot to > replace with a generic name. > > > > Victor Stanescu wrote: > > > I think it is easier to force him to authenticate the INVITE. If > he > is > able to authenticate the INVITE, why do you care if he is > > registered > or not? > > > > > > if (method=="REGISTER") { > > > if(!src_ip=="other") { > > > if (!www_authorize("gtstelecom.ro", "subscriber")) { > > > www_challenge("domain", "0"); > > > break; > > > }; > > > save("location"); > > > log("Replicating REGISTER\n"); > > > t_replicate("other", "5060"); > > > } else { > > > save("location"); > > > }; > > > break; > > > } else { > > > # this is an INVITE > > > if (!proxy_authorize("gtstelecom.ro", "subscriber")) { > > > proxy_challenge("domain", "1"); > > > break; > > > }; > > > # route the call > > > ... > > > }; > > > > > > İlker Aktuna (Koç.net) wrote: > > >> > > >> Hi all, > > >> > > >> Is it possible to prevent any user calling without registering ? > > What >> is the best way to do this ? > > >> I guess I'll have to check if the source URI exists in location > table. > > >> What is the easiest way to do this ? > > >> > > >> If there is a more robust way to do it, please suggest... > > >> > > >> Thanks, > > >> ilker > > >> > > >> > > > > > > <http://387555.sigclick.mailinfo.com/sigclick/00090507/060D4E00/00010A4E/011…> _____________________________________________________________________________________________________________________________________________ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence. _____________________________________________________________________________________________________________________________________________

2 1

[Serusers] SER Presence Snapshot and eyeBeam 1.5.7 - Presence Notes are not working
by Anton Schula 12 Jul '06

12 Jul '06

Hi, Has anybody experience with eyeBeam 1.5? I tested eyeBeam 1.5.7 build 31195 with the SER Presence Snapshot. Basic Presence works O.K. Presence Notes (e.g. Basic: Open, Note: Busy) are not processed by the SER PA module. I traced and found the following differences to the old eyeBeam 1.1 (eyeBeam release 3014w stamp 26703). eyeBeam 1.5.7 presence document in PUBLISH: <?xml version='1.0' encoding='UTF-8'?> <presence xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid' xmlns:c='urn:ietf:par ams:xml:ns:pidf:cipid' entity='pres:sip:a.schula@10.241.143.158'> <tuple id='td4760a41'> <status> <basic>open</basic> </status> </tuple> <dm:person id='paf70ec41'> <rpid:activities> <rpid:busy/> <rpid:unknown/> </rpid:activities> <dm:note>Busy</dm:note> </dm:person> </presence> And here the working resence document from eyeBeam 1.1 PUBLISH: <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pp="urn:ietf:params:xml:ns:pidf:person" xmlns:et="urn:ietf:params:xml:ns:pidf:rpid:rpid-tuple" xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid" entity="sip:T2@10.241.143.158"> <pp:person> <status> <ep:activities> <ep:away/> </ep:activities> </status> </pp:person> <note>Away</note> <tuple id="7520193f"> <contact priority="1"> sip:T2@10.241.143.158 </contact> <status> <basic>open</basic> <es:user-input since="2006-07-12T15:34:42Z"> idle </es:user-input> </status> </tuple> </presence> Is there anything I can do to get presence notes working with eyeBeam 1.5.x? Best regards A. Schula -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

2 1

[Users] 500 internal error
by zhan li 12 Jul '06

12 Jul '06

RTP proxy is enabled, happened for PSTN termination. also happpened when 2 SIP client behind the different NAT, or when the 2 SIP client behind same NAT, the BYE message will cause the same error message. The configuration file is just the same as the file from startup package for RTP Proxy. U 69.88.77.66:5120 -> 201.22.33.178:5060 SIP/2.0 200 OK..Via: SIP/2.0/UDP 201.22.33.178:5060;branch=0..Call-ID: c87 e3594-32a56723-65e5 [!at] 201.22.33.178..CSeq (replace the [!at] with a @): 1 OPTIONS..From: sip:pinger@opens er.org;tag=ad27d066..To: sip:69.88.77.66:5120;tag=qjp2KfWkSXDEoML2..Cont act: <sip:1001@192.168.1.10:5120>..Allow: INVITE, ACK, OPTIONS, BY E, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE..Accept: application /sdp, message/sipfrag, application/dtmf-relay..Supported: replaces..Content -Length: 0.. U 69.88.77.66:5120 -> 201.22.33.178:5060 INVITE sip:12127977000@201.22.33.178 SIP/2.0..Via: SIP/2.0/UDP 192.1 68.1.10:5120;branch=z9hG4bK2xcF52ZeIG9RyjPc..Max-Forwards: 70..User-Agent: COSUN V1.49.002 CFG0 ..From: "1001" <sip:1001@201.22.33. 178>;tag=CXTKU08d8synkO1U..To: "12127977000" <sip:12127977000@2 03.98.176.178>..Call-ID: ziblKnSznNbjxCjv [!at] 192.168.1.10..Contact (replace the [!at] with a @): <sip:08688 99500500 [!at] 192.168.1.10 (replace the [!at] with a @):5120>..CSeq: 1 INVITE..Supported: replaces..Content-T ype: application/sdp..Content-Length: 315....v=0..o=- 91081239 73141710 IN IP4 192.168.1.10..s=SIP CALL..c=IN IP4 192.168.1.10..t=0 0..m=audio 5121 RT P/AVP 18 4 0 97 3 8 101..a=rtpmap:18 G729/8000..a=rtpmap:4 G723/8000..a=rtp map:0 PCMU/8000..a=rtpmap:97 iLBC/8000..a=rtpmap:3 GSM/8000..a=rtpmap:8 PCM A/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. U 201.22.33.178:5060 -> 69.88.77.66:5120 SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 192.16 8.1.10:5120;branch=z9hG4bK2xcF52ZeIG9RyjPc;rport=5120;received=203.122.70.1 55..From: "1001" <sip:1001@201.22.33.178>;tag=CXTKU08d8s ynkO1U..To: "12127977000" <sip:12127977000@201.22.33.178>..Cal l-ID: ziblKnSznNbjxCjv [!at] 192.168.1.10..CSeq (replace the [!at] with a @): 1 INVITE..Server: OpenSer (1.0.1 (i386/linux))..Content-Length: 0..Warning: 392 201.22.33.178:5060 "Noisy feedback tells: pid=16917 req_src_ip=69.88.77.66 req_src_port=5120 in_u ri=sip:12127977000@201.22.33.178 out_uri=sip:12127977000@203.9 8.176.174 via_cnt==1".... U 201.22.33.178:5060 -> 69.88.77.66:5120 SIP/2.0 500 I'm terribly sorry, server error occurred (1/SL)..Via: SIP/2.0/ UDP 192.168.1.10:5120;branch=z9hG4bK2xcF52ZeIG9RyjPc;rport=5120;received=20 3.122.70.155..From: "1001" <sip:1001@201.22.33.178>;tag= CXTKU08d8synkO1U..To: "12127977000" <sip:12127977000@201.22.33 .178>;tag=329cfeaa6ded039da25ff8cbb8668bd2.473f..Call-ID: ziblKnSznNbjxCjv@ 192.168.1.10..CSeq: 1 INVITE..Server: OpenSer (1.0.1 (i386/linux))..Content -Length: 0..Warning: 392 201.22.33.178:5060 "Noisy feedback tells: pid=16 917 req_src_ip=69.88.77.66 req_src_port=5120 in_uri=sip:0069086298266808 2 [!at] 201.22.33.178 (replace the [!at] with a @) out_uri=sip:12127977000@201.22.33.174 via_cnt==1".. .. U 201.22.33.178:5060 -> 201.22.33.174:5060 INVITE sip:12127977000@201.22.33.174 SIP/2.0..Record-Route: <sip:203 .98.176.178;ftag=CXTKU08d8synkO1U;lr=on>..Via: SIP/2.0/UDP 201.22.33.178;b ranch=z9hG4bK96da.4cdeb4.0..Via: SIP/2.0/UDP 192.168.1.10:5120;rport=5120;r eceived=69.88.77.66;branch=z9hG4bK2xcF52ZeIG9RyjPc..Max-Forwards: 69..Us er-Agent: COSUN V1.49.002 CFG0 ..From: "1001" <sip:1001@2 03.98.176.178>;tag=CXTKU08d8synkO1U..To: "12127977000" <sip:006908629 82668082 [!at] 201.22.33.178 (replace the [!at] with a @)>..Call-ID: ziblKnSznNbjxCjv [!at] 192.168.1.10..Contact (replace the [!at] with a @): <sip:1001@69.88.77.66:5120>..CSeq: 1 INVITE..Supported: replace s..Content-Type: application/sdp..Content-Length: 336....v=0..o=- 91081239 73141710 IN IP4 192.168.1.10..s=SIP CALL..c=IN IP4 201.22.33.178..t=0 0..m =audio 35042 RTP/AVP 18 4 0 97 3 8 101..a=rtpmap:18 G729/8000..a=rtpmap:4 G 723/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:97 iLBC/8000..a=rtpmap:3 GSM/8000. .a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. a=nortpproxy:yes.. U 201.22.33.174:5060 -> 201.22.33.178:5060 SIP/2.0 100 Trying..Via: SIP/2.0/UDP 201.22.33.178;branch=z9hG4bK96da.4cde b4.0,SIP/2.0/UDP 192.168.1.10:5120;rport=5120;received=69.88.77.66;branc h=z9hG4bK2xcF52ZeIG9RyjPc..From: "1001" <sip:1001@203.98. 176.178>;tag=CXTKU08d8synkO1U..To: "12127977000" <sip:006908629826680 82 [!at] 201.22.33.178 (replace the [!at] with a @)>;tag=BD997FE4-12B5..Date: Wed, 05 Jul 2006 09:54:41 GMT.. Call-ID: ziblKnSznNbjxCjv [!at] 192.168.1.10..Server (replace the [!at] with a @): Cisco-SIPGateway/IOS-12.x.. CSeq: 1 INVITE..Content-Length: 0.... U 201.22.33.178:5060 -> 69.88.77.66:5120 SIP/2.0 500 I'm terribly sorry, server error occurred (1/SL)..Via: SIP/2.0/ UDP 192.168.1.10:5120;branch=z9hG4bK2xcF52ZeIG9RyjPc;rport=5120;received=20 3.122.70.155..From: "1001" <sip:1001@201.22.33.178>;tag= CXTKU08d8synkO1U..To: "12127977000" <sip:12127977000@201.22.33 .178>;tag=329cfeaa6ded039da25ff8cbb8668bd2.473f..Call-ID: ziblKnSznNbjxCjv@ 192.168.1.10..CSeq: 1 INVITE..Server: OpenSer (1.0.1 (i386/linux))..Content -Length: 0..Warning: 392 201.22.33.178:5060 "Noisy feedback tells: pid=16 917 req_src_ip=69.88.77.66 req_src_port=5120 in_uri=sip:0069086298266808 2 [!at] 201.22.33.178 (replace the [!at] with a @) out_uri=sip:12127977000@201.22.33.174 via_cnt==1".. .. U 69.88.77.66:5120 -> 201.22.33.178:5060 ACK sip:12127977000@201.22.33.178 SIP/2.0..Via: SIP/2.0/UDP 192.168. 1.10:5120;branch=z9hG4bK2xcF52ZeIG9RyjPc..Max-Forwards: 70..User-Agent: COS UN V1.49.002 CFG0 ..From: "1001" <sip:1001@201.22.33.178 >;tag=CXTKU08d8synkO1U..To: "12127977000" <sip:12127977000@203. 98.176.178>;tag=329cfeaa6ded039da25ff8cbb8668bd2.473f..Call-ID: ziblKnSznNb jxCjv [!at] 192.168.1.10..Contact (replace the [!at] with a @): <sip:1001@192.168.1.10:5120>..CSeq: 1 ACK..Content-Length: 0.... U 69.88.77.66:5120 -> 201.22.33.178:5060 ACK sip:12127977000@201.22.33.178 SIP/2.0..Via: SIP/2.0/UDP 192.168. 1.10:5120;branch=z9hG4bK2xcF52ZeIG9RyjPc..Max-Forwards: 70..User-Agent: COS UN V1.49.002 CFG0 ..From: "1001" <sip:1001@201.22.33.178 >;tag=CXTKU08d8synkO1U..To: "12127977000" <sip:12127977000@203. 98.176.178>;tag=329cfeaa6ded039da25ff8cbb8668bd2.473f..Call-ID: ziblKnSznNb jxCjv [!at] 192.168.1.10..Contact (replace the [!at] with a @): <sip:1001@192.168.1.10:5120>..CSeq: 1 ACK..Content-Length: 0.... U 201.22.33.174:5060 -> 201.22.33.178:5060 SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 201.22.33.178;branch=z9hG4b K96da.4cdeb4.0,SIP/2.0/UDP 192.168.1.10:5120;rport=5120;received=203.122.70 .155;branch=z9hG4bK2xcF52ZeIG9RyjPc..From: "1001" <sip:08688995005 00 [!at] 201.22.33.178 (replace the [!at] with a @)>;tag=CXTKU08d8synkO1U..To: "12127977000" <sip:00690 862982668082 [!at] 201.22.33.178 (replace the [!at] with a @)>;tag=BD997FE4-12B5..Date: Wed, 05 Jul 2006 09:5 4:41 GMT..Call-ID: ziblKnSznNbjxCjv [!at] 192.168.1.10..Server (replace the [!at] with a @): Cisco-SIPGateway/ IOS-12.x..CSeq: 1 INVITE..Content-Type: application/sdp..Content-Dispositio n: session;handling=required..Content-Length: 214....v=0..o=CiscoSystemsSIP -GW-UserAgent 5365 5815 IN IP4 201.22.33.174..s=SIP Call..c=IN IP4 203.98. 176.174..t=0 0..m=audio 16512 RTP/AVP 18 101..a=rtpmap:18 G729/8000..a=rtpm ap:101 telephone-event/8000..a=fmtp:101 .. U 201.22.33.178:5060 -> 69.88.77.66:5120 SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 192.168.1.10:5120;rport=5120 ;received=69.88.77.66;branch=z9hG4bK2xcF52ZeIG9RyjPc..From: "08688995005 00" <sip:1001@201.22.33.178>;tag=CXTKU08d8synkO1U..To: "006908629 82668082" <sip:12127977000@201.22.33.178>;tag=BD997FE4-12B5..Date: W ed, 05 Jul 2006 09:54:41 GMT..Call-ID: ziblKnSznNbjxCjv [!at] 192.168.1.10..Serve (replace the [!at] with a @) r: Cisco-SIPGateway/IOS-12.x..CSeq: 1 INVITE..Content-Type: application/sdp ..Content-Disposition: session;handling=required..Content-Length: 232....v= 0..o=CiscoSystemsSIP-GW-UserAgent 5365 5815 IN IP4 201.22.33.174..s=SIP Ca ll..c=IN IP4 201.22.33.178..t=0 0..m=audio 35044 RTP/AVP 18 101..a=rtpmap: 18 G729/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 ..a=nortpproxy: yes..

2 1

[Serusers] Important info regarding SJPhone and ONsip.org NAT-handling
by Greger V. Teigre 12 Jul '06

12 Jul '06

This information is related to SJPhone latest released version (1.60.289a) and the ONsip.org NAT-handling configuration scripts. The ONsip.org configuration files (rtpproxy and mediaproxy) use what is known as "record-route parameters" to store the flag "nat=yes" in a SIP dialog. RFC3261 specifies that ALL such parameters MUST be copied into Route header when a user agent client creates a new request in the dialog. This way a test in ser.cfg can detect if a call is nated and thus needs to be proxied. This is most normally found in reINVITEs (i.e. put on hold, take off hold). Extensive testing shows that SJPhone in the current release (1.60.289a) does not follow RFC3261 and only copies the FIRST record-route parameter into Route headers of subsequent messages. This has the consequence that lr=on (added by rr module to ensure loose routing of messages) is left out when the dialog is nated, which again results in all subsequent transactions being strict routed instead of loose routed. This may or may not have an impact on your setup (but as strict routing normally is allowed for backwards compatibility, you should be fine.) The latest SJPhone preview version (1.61.321a from February 2006) has corrected this bug. However, I have been unable to find any information about the issue or why a bugfix has not been released, and as SJPhone is extensively used, I find it appropriate to report the issue. Also note that if you use other record-route parameters before nat=yes, the nat=yes flag will also be left out and the dialog will not be detected as proxied. Recommendation: If you have SJPhones on your supported clients list and use record-route parameters, you should verify whether this problem is present. It can easily be detected by sending an INVITE to a NATed SJPhone (i.e. nat=yes;lr=on is added to Record-Route in the INVITE). If the Route in the 180 Ringing or the 200 OK received from the SJPhone contains a Route: header where only nat=yes is present, strict routing will be the result. If you use other record-route parameters, you should review the impact on the functionality supported through those. g-)

1 0

[Users] Declined INVITE invokes multiple Decline's at Proxy
by Augustin, Andrew (external) 12 Jul '06

12 Jul '06

Hello, I am using openser v1.0. I have a problem with the following SIP scenario with openser: - A invites B to a call session, B declines the invitation The message trace shown below is just part of the message trace produced for the above scenario displaying message frames in sequence F43, F44 ... through F64 Initially everything works as expected: INVITEs, Trying (100) and Ringing 180 messages are routed correctly from A to B and from B to A via the intermediate proxies (this is not shown below). While still 'Ringing', B decline's the call (sends a Decline message) message: F44 in trace below. This also initally routes OK. But the call flow for this scenario is expected to terminate at message: F55 once the 'Decline' has routed its way back from the B-Party to the A-Party and a final 'ACK' is sent by the A-Party to the previous proxy: Proxy-1. But what actually occurs is that openser running on Proxy-1 automatically resends a 'Decline' at message F56 identical to the 'Decline' it first sent at message F46. This in turn prompts further ACKs and 'Decline's until it finally times out at message F107 (not shown below). It appears that openser saves the original message and attempts to retry/resend the 'Decline' message when prompted by an ACK. This continues for several cycles with ACKs and Decline's being sent and received around the system until a timeout occurs. The above behaviour also occurs for the following scenario: - A invites B to a call session, B responds with a Busy Can you help me to: - understand what is going on - terminate what appears to be an open 'transaction' for the 'Decline' and prevent further 'Decline's and ACKs being sent around the system. Best regards, Andrew -------------- A-Party Proxy-1 Proxy-2 Proxy-3 B-Party 10.1.195.134:50 10.1.195.134:50 127.0.0.1:5070 127.0.0.1:5080 10.1.195.208:50 | | | | | |<nging 180 F43<| | | | | | | | | | |<----------------------------- Decline 603 F44<| | | | | | | |>F45 ACK ------------------------------------->| | | | | | | |>F46 603 Decline ------------->| | | | | | | | |<--------------------- ACK F47<| | | | | | | | | |<cline 603 F48<| | | | | | | | | |>F49 ACK ----->| | | | | | | | | |>F50 603 Decli>| | | | | | | | | |<----- ACK F51<| | | | | | | | |<------------- Decline 603 F52<| | | | | | | | |>F53 ACK --------------------->| | | | | | | |<cline 603 F54<| | | | | | | | | |>F55 ACK ----->| | | | | | | | | | |>F56 603 Decline ------------->| | | | | | | | |<--------------------- ACK F57<| | | | | | | |<cline 603 F58<| | | | | | | | | |>F59 ACK ----->| | | | | | | | | | |>F60 603 Decline ------------->| | | | | | | | |<--------------------- ACK F61<| | | | | | | |<cline 603 F62<| | | | | | | | | |>F63 ACK ----->| | | | | | | | | | |>F64 603 Decline ------------->| | | | | | |

2 1

Re: [Serusers] Implementing a black list.
by CM0002＠aol.com 12 Jul '06

12 Jul '06

try this: # block expensive area codes if (uri=~"^sip:00355[0-9].*@.*" | uri=~"^sip:00358830[0-9].*@.*" | uri=~"^sip:001670.*@.*" | uri=~"^sip:001671.*@.*" | uri=~"^sip:00247[0-9].*@.*" ) { sl_send_reply("409", "Country not in plan"); break; }; regards Christian

4 6

RE: [Serusers] prevent INVITE without REGISTERing
by İlker Aktuna (Koç.net) 12 Jul '06

12 Jul '06

Thanks Miklos, I think this is just what I'm looking for. But I get some errors for this line: if ((src_ip != @ruri.host) || (src_port != @ruri.port)) { 0(30074) parse error (175,16-17): syntax error 0(30074) parse error (175,16-17): ip address or hostname expected 0(30074) parse error (175,16-17): bad command 0(30074) parse error (175,21-22): bad command 0(30074) parse error (175,21-22): bad command 0(30074) parse error (175,26-27): bad command 0(30074) parse error (175,26-27): bad command 0(30074) parse error (175,28-30): bad command 0(30074) parse error (175,31-32): bad command 0(30074) parse error (175,32-40): bad command 0(30074) parse error (175,41-43): bad command 0(30074) parse error (175,44-45): bad command 0(30074) parse error (175,49-50): bad command 0(30074) parse error (175,49-50): bad command 0(30074) parse error (175,54-55): bad command 0(30074) parse error (175,54-55): bad command 0(30074) parse error (175,55-56): bad command 0(30074) parse error (175,57-58): bad command Any idea why ? Thanks, ilker -----Original Message----- From: Miklos Tirpak [mailto:miklos@iptel.org] Sent: Wednesday, July 12, 2006 11:58 AM To: İlker Aktuna (Koç.net) Cc: serusers(a)iptel.org Subject: Re: [Serusers] prevent INVITE without REGISTERing Hi Ilker, just my first idea, not tested: 1. lookup the From HF if (!lookup_user("From")) { # reject the INVITE ... } 2. save original To UID and Request URI $orig_to_uid = $tu.uid; $orig_req_uri = @ruri; 3. set To UID -- registrar module will use this in the lookup $tu.uid = $fu.uid; 4. lookup From HF and compare the source address of the INVITE with the source address of the REGISTER message if (lookup("location")) { if ((src_ip != @ruri.host) || (src_port != @ruri.port)) { # reject the INVITE ... } # restore original To UID and Request URI $tu.uid = $orig_to_uid; attr2uri("$orig_req_uri"); } else { # reject the INVITE ... } Note, that the above solution is a bit ugly, you can get into troubles when the user registers multiple contact addresses. It is better to disable branches (see append_branches parameter in registrar module), but you loose some functionality. Regards, Miklos İlker Aktuna (Koç.net) wrote: > > Hi everyone, > > I am still trying to find a solution to this problem. (but couldn't > find > yet) > Victor was trying to help me but I think he's not able to reply these days. > > Is there any idea to achieve what I need. > > Thanks, > ilker > > ---------------------------------------------------------------------- > -- > *From:* serusers-bounces(a)lists.iptel.org > [mailto:serusers-bounces@lists.iptel.org] *On Behalf Of *İlker Aktuna > (Koç.net) > *Sent:* Tuesday, July 11, 2006 1:41 PM > *To:* Victor Stanescu > *Cc:* serusers(a)iptel.org > *Subject:* RE: [Serusers] prevent INVITE without REGISTERing > > Hi, > > What if my proxy does not handle authenticating INVITE messages ? > > In that case I think the best way is to lookup location table for the > source URI. > If the source URI location matches the location in that table then we > must permit INVITE message. > How can I configure this ? > > Thanks, > ilker > > -----Original Message----- > From: serusers-bounces(a)lists.iptel.org > [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Victor Stanescu > Sent: Monday, July 10, 2006 1:49 PM > Cc: serusers(a)iptel.org > Subject: Re: [Serusers] prevent INVITE without REGISTERing > > Please read "domain" instead of "gtstelecom.ro": > www_authorize("domain", > "subscriber") and proxy_authorize("domain", "subscriber"), otherwise > the code fragment will not be correct. I forgot to replace with a generic name. > > Victor Stanescu wrote: > > I think it is easier to force him to authenticate the INVITE. If he > is > able to authenticate the INVITE, why do you care if he is > registered > or not? > > > > if (method=="REGISTER") { > > if(!src_ip=="other") { > > if (!www_authorize("gtstelecom.ro", "subscriber")) { > > www_challenge("domain", "0"); > > break; > > }; > > save("location"); > > log("Replicating REGISTER\n"); > > t_replicate("other", "5060"); > > } else { > > save("location"); > > }; > > break; > > } else { > > # this is an INVITE > > if (!proxy_authorize("gtstelecom.ro", "subscriber")) { > > proxy_challenge("domain", "1"); > > break; > > }; > > # route the call > > ... > > }; > > > > İlker Aktuna (Koç.net) wrote: > >> > >> Hi all, > >> > >> Is it possible to prevent any user calling without registering ? > What >> is the best way to do this ? > >> I guess I'll have to check if the source URI exists in location table. > >> What is the easiest way to do this ? > >> > >> If there is a more robust way to do it, please suggest... > >> > >> Thanks, > >> ilker > >> > >> > > > > <http://387555.sigclick.mailinfo.com/sigclick/07090204/04064D07/070105 > 4D/0364151131.jpg> > ______________________________________________________________________ > ______________________________________________________________________ > _ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor > olabilir. > Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir > sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen > e-posta mesajini kullaniciya hemen geri gonderiniz ve tum > kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir > sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. > Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan > taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma > sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti > etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu > kabul etmez. > This message is intended solely for the use of the individual or > entity to whom it is addressed , and may contain confidential > information. If you are not the intended recipient of this message or > you receive this mail in error, you should refrain from making any use > of the contents and from opening any attachment. In that case, please > notify the sender immediately and return the message to the sender, > then, delete and destroy all copies. This e-mail message, can not be > copied, published or sold for any reason. This e-mail message has been > swept by anti-virus systems for the presence of computer viruses. In > doing so, however, sender cannot warrant that virus or other forms of > data corruption may not be present and do not take any responsibility in any occurrence. > ______________________________________________________________________ > ______________________________________________________________________ > _ > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers <http://387555.sigclick.mailinfo.com/sigclick/060A030C/040D4D00/06020645/031…> _____________________________________________________________________________________________________________________________________________ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence. _____________________________________________________________________________________________________________________________________________

2 1

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