sr-users July 2006

sr-users@lists.kamailio.org

206 participants
414 discussions

by zhan li

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

18 years, 7 months

[Serusers] Important info regarding SJPhone and ONsip.org NAT-handling

by Greger V. Teigre

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

18 years, 7 months

[Users] Declined INVITE invokes multiple Decline's at Proxy

by Augustin, Andrew (external)

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

18 years, 7 months

Re: [Serusers] Implementing a black list.

by CM0002＠aol.com

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

18 years, 7 months

RE: [Serusers] prevent INVITE without REGISTERing

by İlker Aktuna (Koç.net)

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

18 years, 7 months

RE: [Serusers] European Ph.D VoIP programs

by Benjamin.George＠t-systems.com

Hi, I feel Fraunhofer-Institute, Berlin, Germany would be one of the best institutes which I can suggest for you. They are doing R&D on lot of innovative VOIP and NGN-IMS solutions. :-) -Benjamin _____ From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Voipers Portugal Sent: Wednesday, July 12, 2006 4:21 AM To: sipp-users(a)lists.sourceforge.net; sems(a)iptel.org; serusers(a)iptel.org; Asterisk Users Mailing List - Non-Commercial Discussion Subject: [Serusers] European Ph.D VoIP programs Hi everyone, I know these list aren't the best place to ask for assistance. However, I would like to know if anyone here knows what are the best European University to do a Ph.D degree in something related to VoIP. Anyone here already working on a particular project like this? All answers will be helpful. Thanks, Jose Simoes

18 years, 7 months

[Users] OpenSER 1.1.0 packages

by Bogdan-Andrei Iancu

Hi, first OpenSER 1.1.0 packages were uploaded on the site. At http://www.openser.org/pub/openser/latest/ you can find the debs (for stable, testing and unstable) and rpms for redhat. The debs are also available via apt from: deb http://www.openser.org/debian etch|sarge|sid main FreeBSD port will be soon available also. Regards, Bogdan

18 years, 7 months

[Serusers] SER PRACK

by Razvan Nemesiu

Dear all, Does anyone know if SER (0.8.14) supports PRACK messages ? I want to know if it forwards them.I want to add in my configuration if(method==PRACK) {..} and I want to know if I can do that and if SER allows this configuration line. Best regards, Razvan

18 years, 7 months

RE: [Serusers] prevent INVITE without REGISTERing

by İlker Aktuna (Koç.net)

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/0701054D/036…> _____________________________________________________________________________________________________________________________________________ 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. _____________________________________________________________________________________________________________________________________________

18 years, 7 months

[Users] How to handle "302 Moved temporarily" with TCP transport and changing port

by Ingmar Kliche

Hi all, I'm very new to OpenSER and I would like to ask for your advice to find a solution for my problem: I have a SIP gateway (A) which uses UDP transport and a SIP endpoint (B) which only supports TCP. I'd like to use OpenSER to convert UDP to TCP. The second issue is that the TCP endpoint (B) will redirect the incoming INVITE to itself to another TCP port using a "302 Moved temporarily" containing a CONTACT header. Here is my approach: My current understanding is that I would have to add something to the routing block to select the traffic for my TCP endpoint. Then I would have to add route where I would have to handle the TCP forwarding, something like: if (uri=~"...") { t_relay_to_tcp("<ip>", "5060"); } This looks very straight forward and should solve the UDP to TCP issue as I understand it. Is this approach correct? For the second issue I don't have a solution right now. As described above the TCP endpoint (B) will answer something like SIP/2.0 302 Moved Temporarily FROM: <sip:tel@HOST_A>;tag=1c552078080 TO: <sip:tel@HOST_B>;tag=7189e7deae CSEQ: 1 INVITE CALL-ID: 552077216117200615500@HOST_A MAX-FORWARDS: 70 VIA: SIP/2.0/TCP HOST_A;branch=z9hG4bKac552089789;alias CONTENT-LENGTH: 0 SERVER: RTCC/2.0.6011.0 CONTACT: <sip:tel@HOST_B:1223;transport=tcp;maddr=HOST_B;x-mss-call-id=552077216117200615500%40HOST_B> I want OpenSER now to send out another INVITE via TCP to HOST_B Port 1223 (but the port changes for each call). In principle I would need a possiblity to extract the host and the port out of the CONTACT header of the message to send another t_relay_to_tcp("<host>", "<port>"). But how to do that? Or is there another possibility to tell OpenSER to take the target info out of the CONTACT header? Thanks in advance! Ingmar

18 years, 7 months

← Newer
1
...
26
27
28
29
30
31
32
...
42
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 July 2006