sr-users

sr-users@lists.kamailio.org

34 participants
37543 discussions

[Users] ERROR 1062 (23000): Duplicate entry
by alper ozbilen 21 Mar '07

21 Mar '07

Dear All, I can not insert a new subscriber from mysql console. When I look at subscireber table, ha1 & ha1b & and phplib_id fields looks null. So, i can only insert one new subscriber. When i attempt to insert second one, i get error written below: ERROR 1062 (23000): Duplicate entry '' for key 3 Note : My insert sentence like that: insert into subscriber (username, domain, password, email_address) values ("testuser","myfon.com","testpasswd","emailoftestuser(a)myfon.com"); I am confused about what i should to do to fix null statement of ha1 & ha2 & and phplib_id fields. on the other side, there is no probem to add new user through openserctl What was the problem? I will wait your kind suggestion. Regards, Alper Ozbilen _________________________________________________________________ Exercise your brain! Try Flexicon. http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglinema…

1 0

[Users] OpenSER and FWD
by Michel Bensoussan 21 Mar '07

21 Mar '07

Hello. How can I configure OpenSER to outgoing all call to FWD and more important to ensure that all INCOMING call will go through OpenSER? Thanks. Regards, Michel.

4 8

[Users] RPID single quotes problem
by Daryl Sanders 20 Mar '07

20 Mar '07

Is there an easy way to strip the single quotes from RPID in DBTEXT? When I use sc.dbtext it automatically adds single quotes to the entry like so... '17145551212' As a result when I add RPID to my header with the folowing line, I get the single quotes in the header. append_hf("P-Asserted-Identity: \"User\" <sip:+$avp(s:rpid)@x.x.x.x>\r\n"); Regards, Daryl

1 1

Re: [Users] loose_route problem with 1.2
by jh＠tutpro.com 20 Mar '07

20 Mar '07

it turned out that if i have in openser.cfg listen=x.x.x.x alias="sip.foo.bar:5060" port=5060 auto_aliases=no then openser advertises at startup: Aliases: *: sip.foo.bar:5060:* and loose_route DOES NOT recognize that Route header <sip:sip.foo.bar;lr;transport=TCP> is local. on the other hand, if i comment line #auto_aliases=no openser advertises at startup: Aliases: tcp: sip.foo.bar:5060 udp: sip.foo.bar:5060 *: sip.foo.bar:5060:* and it DOES recognize that above Route header is local. if i uncomment auto_aliases=no and change alias="sip.foo.bar:5060" to alias="udp:sip.foo.bar:5060" alias="tcp:sip.foo.bar:5060" then loose_route DOES NOT recognize that the route header is local. my question is, how should i write the alias statements so that the route header is recognized local even when i have auto_aliases=no? -- juha

3 4

Re: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem
by Kostas Marneris 20 Mar '07

20 Mar '07

Hello, What I understand (from Frame12) Session Initiation Protocol Request-Line: BYE sip:000003@1.255.ua_priv__IP SIP/2.0 is that your GW does not comply with the fixed SIP UA Contact address Contact: <sip:000003@213.156.ua_pub_IP:1176> which SER seems to correctly fix it (from Frame6). GW must send the BYE request back to the fixed addr : 213.156.ua_pub_IP:1176. Try a different PSTN-GW or try to isolate the RTP-Proxy solution. I am really confused of your ser.cfg. You use force_rtp_proxy("l") on Loose Route Section / INVITE block, but you don't use force_rtp_proxy() on INVITE handler (Route[3]) and you don't also use rtp_proxy on BYE block at Loose Route Section. I tried this senario without Mediaproxy or RTPproxy with success. regards, Kostas --- K.Marneris(a)otenet.gr ----- Original Message ----- From: "Fabio Macchi" <f.macchi(a)keeptelecom.com> To: <greger(a)teigre.com> Cc: "'Kostas Marneris'" <K.Marneris(a)otenet.gr>; <serusers(a)lists.iptel.org> Sent: 20 March 2007 19:56 Subject: R: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem Hi Greger, I attached an ethereal SIP call trace of a test call ( summary and detailed, I simple maskerade final ip numbers ): below only the INVITE relayed from proxy to gateway: Session Initiation Protocol Request-Line: INVITE sip:9999001234@194.244.gatewayIP:5060 SIP/2.0 Method: INVITE [Resent Packet: False] Message Header Record-Route: <sip:194.244.Proxy__IP;ftag=12e1e2e19d527792;lr=on> Via: SIP/2.0/UDP 194.244.Proxy__IP;branch=z9hG4bKb24f.5133a2c4.0 Transport: UDP Sent-by Address: 194.244.Proxy__IP Branch: z9hG4bKb24f.5133a2c4.0 Via: SIP/2.0/UDP 1.255.ua_priv__IP;rport=1176;received=213.156.ua_pub_IP;branch=z9hG4bK35ca7a df63e3094f Transport: UDP Sent-by Address: 1.255.ua_priv__IP RPort: 1176 Received: 213.156.ua_pub_IP Branch: z9hG4bK35ca7adf63e3094f From: "000003" <sip:000003@194.244.Proxy__IP>;tag=12e1e2e19d527792 SIP Display info: "000003" SIP from address: sip:000003@194.244.Proxy__IP SIP tag: 12e1e2e19d527792 To: <sip:9999001234@194.244.Proxy__IP> SIP to address: sip:9999001234@194.244.Proxy__IP Contact: <sip:000003@213.156.ua_pub_IP:1176> Contact Binding: <sip:000003@213.156.ua_pub_IP:1176> URI: <sip:000003@213.156.ua_pub_IP:1176> SIP contact address: sip:000003@213.156.ua_pub_IP:1176 Supported: replaces Call-ID: 953e8996cfcc4ccc(a)1.255.ua_priv__IP CSeq: 60577 INVITE Sequence Number: 60577 Method: INVITE User-Agent: Grandstream HT386 1.0.3.64 FXS0 Max-Forwards: 16 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE Content-Type: application/sdp Content-Length: 327 Message body As you can see, contact informations are correctly fixed with the pubblic UA address, but when the callee hungs up, the BYE is relayed to the private IP address: am I missing something ? In this invite I see UA private address only in VIA: does BYE look to this parameter ? Later caller hangs up too, and the OK is relayed to the correct IP/port. Any help would be high appreciate, thanks in advance. Fabio _____ Da: Greger V. Teigre [mailto:greger@teigre.com] Inviato: martedμ 20 marzo 2007 9.59 A: Fabio Macchi Cc: 'Kostas Marneris'; serusers(a)lists.iptel.org Oggetto: Re: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem Normally this happens because you haven't fixed the Contact if the original INVITE or OK. g-) Fabio Macchi wrote: First, thanks for answer. I've tryed your trik and in effect this solve the problem of the '200 ok' forwarded to the UA, but my problem still remain alive: when BYE is sent from Gateway, it reaches correctly SER, but it still forward it to the private UA address. I was wondering about the nat_uac_test in this case, as the source of the BYE message is the gateway ( not natted ) and not the UA. Have any idea about this ? Fabio -----Messaggio originale----- Da: Kostas Marneris [mailto:K.Marneris@otenet.gr] Inviato: giovedμ 15 marzo 2007 20.39 A: Fabio Macchi Cc: serusers(a)lists.iptel.org Oggetto: Re: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem Hello, I was working on about the same problem today either with 'Mediaproxy solution' or with 'SER's Nathelper only solution' . The NAT issue is a nightmare, not because of SER but because of different implementations on NAT boxes. Actually my problem was : if the NATed UA send a BYE to SER, SER forward it to PSTN-GW, then the '200 Ok' Response from PSTN-GW is forwarded by SER to UA to the wrong port (Contact or Via header port). I used the following block on Loose Route section, (because BYE is loose_routed if you use Record-Route), and it seems to work. # --------------------------------------- # Loose Route Section # --------------------------------------- if (loose_route()) { # mark routing logic in request if (method == "BYE") { if (nat_uac_test("22")) { xlog("L_NOTICE", "*** LR -> NATed BYE - Use force_rport()"); force_rport(); }; }; route(1); break; }; I faced up your second problem too. The solution was to move the NAT handling block before proxy_authorize block. I think that the different behaviour does not come with the 'standard RFC1918 addresses', but with the different NAT type. I realize that the provisional mesgs '100 Trying' and '407 Proxy Authentication Required' are relayed back to the real IP addr of NATed UA (this is correct), but to the WRONG port (that of Contact/Via header and not the signalling received port). It seems that these mesgs use the IP address part of 'Received' field of Location DB but not the port. It happens to work if NAT box use the SAME port (eg. 5060) on NAT translation (10.10.10.1:5060 --> Real_IP:5060) (eg. with a SAGEM1500 Router) But it does not work if NAT box doesn't use the same port (10.10.10.1:5060 --> Real_IP:38181) I think that this has to be verified by SER developers or SER experts. Kostas --- K.Marneris(a)otenet.gr ----- Original Message ----- From: "Fabio Macchi" <mailto:f.macchi@keeptelecom.com> <f.macchi(a)keeptelecom.com> To: <mailto:serusers@lists.iptel.org> <serusers(a)lists.iptel.org> Sent: 15 March 2007 19:34 Subject: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem Hi all, I'm running the following schema: UA ( possibly natted ) -> SER -> PSTN Gateway I have a problem with UA belonging to a particular network with private address not RFC1918 compliant ( class 1.x.x.x ), SER and PSTN Gateway have pubblic address. The problem is that, after a succesfull call, if the PSTN gateway send a BYE to SER, then SER forward BYE to the private address of UA instead of pubblic one. I don't understand which is the section that handle BYE messages and how can I solve this problem: anyone may help ? Second, another question: with this particular network I had problem with INVITE too, because SER was sending "proxy authorization request" to the wrong TCP port. To solve this, I've moved the nat handling ( with force_rport ) before the proxy_authorize block and it's working, but why this is not necessary on standard RFC1918 compliant natted address ? Many thanks for any explanation Fabio _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.15/728 - Release Date: 20/03/2007 08:07

1 0

Re: R: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem
by Greger V. Teigre 20 Mar '07

20 Mar '07

Thanks for the detailed trace, I wouldn't have spent on this without it ;-) Its' the ACK for the OK that is not done fix_nated_contact for. In fact, checking the getting started rtpproxy file, it seems that this error is also found there. All messages coming from behind NAT should have the contact fixed. Strictly speaking, RFC3261 states that the dialog state should be created from the information found in the INVITE, not the ACK on an OK. Your BYE generating entity does this error. I have seen this problem before, but has not really thought about it from the getting started config file perspective. It is thus safer to change Contact on ALL messages behind NAT, regardless of they are loose routed or not. g-) Fabio Macchi wrote: > > Hi Greger, > > > > I attached an ethereal SIP call trace of a test call ( summary and > detailed, I simple maskerade final ip numbers ): below only the INVITE > relayed from proxy to gateway: > > > > Session Initiation Protocol > > Request-Line: INVITE sip:9999001234@194.244.gatewayIP:5060 SIP/2.0 > > Method: INVITE > > [Resent Packet: False] > > Message Header > > Record-Route: <sip:194.244.Proxy__IP;ftag=12e1e2e19d527792;lr=on> > > Via: SIP/2.0/UDP 194.244.Proxy__IP;branch=z9hG4bKb24f.5133a2c4.0 > > Transport: UDP > > Sent-by Address: 194.244.Proxy__IP > > Branch: z9hG4bKb24f.5133a2c4.0 > > Via: SIP/2.0/UDP > 1.255.ua_priv__IP;rport=1176;received=213.156.ua_pub_IP;branch=z9hG4bK35ca7adf63e3094f > > Transport: UDP > > Sent-by Address: 1.255.ua_priv__IP > > RPort: 1176 > > Received: 213.156.ua_pub_IP > > Branch: z9hG4bK35ca7adf63e3094f > > From: "000003" <sip:000003@194.244.Proxy__IP>;tag=12e1e2e19d527792 > > SIP Display info: "000003" > > SIP from address: sip:000003@194.244.Proxy__IP > > SIP tag: 12e1e2e19d527792 > > To: <sip:9999001234@194.244.Proxy__IP> > > SIP to address: sip:9999001234@194.244.Proxy__IP > > Contact: <sip:000003@213.156.ua_pub_IP:1176> > > Contact Binding: <sip:000003@213.156.ua_pub_IP:1176> > > URI: <sip:000003@213.156.ua_pub_IP:1176> > > SIP contact address: sip:000003@213.156.ua_pub_IP:1176 > > Supported: replaces > > Call-ID: 953e8996cfcc4ccc(a)1.255.ua_priv__IP > > CSeq: 60577 INVITE > > Sequence Number: 60577 > > Method: INVITE > > User-Agent: Grandstream HT386 1.0.3.64 FXS0 > > Max-Forwards: 16 > > Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE > > Content-Type: application/sdp > > Content-Length: 327 > > Message body > > > > As you can see, contact informations are correctly fixed with the > pubblic UA address, but when the callee hungs up, the BYE is relayed > to the private IP address: am I missing something ? > > In this invite I see UA private address only in VIA: does BYE look to > this parameter ? > > Later caller hangs up too, and the OK is relayed to the correct IP/port. > > > > Any help would be high appreciate, thanks in advance. > > > > Fabio > > > >

1 0

[Users] NAT Problem with OpenSER behind load balancer
by Tim Madorma 20 Mar '07

20 Mar '07

Hi, I have put the OpenSER version 1.2 behind a BIG IP load balancer which provides a static private IP address (10.1.1.20) via NAT to the OpenSER. In our application, the clients will send to one of the three public addresses that are defined as aliases: alias="65.185.232.62:5061" alias="65.185.232.62:5062" alias="65.185.232.62:5063" An incoming OPTIONS message is received with the host in the REQ URI set to 65.185.232.62:5063 is received and when it hits this section of openser.cfg: if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); }; it executes within the if conditional and tries to route the OPTIONS message. I am wondering why uri does not match myself. The debug output from the log is as follows (it seems that the alias assignments are not working): Mar 19 16:41:11 homer openser[2267]: [ID 487083 local0.debug] grep_sock_info - checking if host==us: 13==9 && [65.185.232.62] == [1 0.1.1.20] Mar 19 16:41:11 homer openser[2267]: [ID 375670 local0.debug] grep_sock_info - checking if port 5061 matches port 5063 Mar 19 16:41:11 homer openser[2267]: [ID 487083 local0.debug] grep_sock_info - checking if host==us: 13==9 && [65.185.232.62] == [1 0.1.1.20] Mar 19 16:41:11 homer openser[2267]: [ID 375670 local0.debug] grep_sock_info - checking if port 5062 matches port 5063 Mar 19 16:41:11 homer openser[2267]: [ID 487083 local0.debug] grep_sock_info - checking if host==us: 13==9 && [65.185.232.62] == [1 0.1.1.20] Mar 19 16:41:11 homer openser[2267]: [ID 375670 local0.debug] grep_sock_info - checking if port 5063 matches port 5063 Mar 19 16:41:11 homer openser[2267]: [ID 140248 local0.debug] DEBUG:check_self: host != me Any suggestions? I have not tried this in any other version. Is this a possible bug in 1.2? thanks, Tim

3 2

RV: RV: [Users] WeSIP session question
by Antonio Abajo 20 Mar '07

20 Mar '07

Buenas tardes Tele In the capture, I see the following call flow. GW WESIP MS ------ INV(S1)-----> -------INV (S2) ------> <--------183 ----------- ------- 183 -----------> <----------ACK --------- <---------503 ---------- ... 14:07:57 19Mar2007 DEBUG SipProcessor [SipProcessor[4]]- <<<<<<<<< Request Received <<<<<<<<< INVITE sip:390104491079@82.215.163.67 SIP/2.0 Via: SIP/2.0/UDP 82.215.163.5:5060;branch=z9hG4bK6a4fa6b1 Max-Forwards: 69 From: <sip:3405300695@82.215.163.5>;tag=6a4fa6b1 To: <sip:390104491079@82.215.163.67> Call-ID: 1783604896-30787@SVIGateway CSeq: 1 INVITE Contact: <sip:82.215.163.5:5060> Content-Type: application/sdp Content-Length: 213 14:07:58 19Mar2007 DEBUG SipRequest [SipProcessor[4]]- >>>>>>>>> Sending Request >>>>>>>>> INVITE sip:199@82.215.133.50 SIP/2.0 Max-Forwards: 69 From: <sip:3405300695@82.215.163.5>;tag=01E9CCA04D3CF9B8B3BE20CE1385BC2A To: <sip:390104491079@82.215.163.67> CSeq: 1 INVITE Content-Type: application/sdp Call-ID: 11111783604896-30787@SVIGateway Contact: <sip:82.215.163.67:5060;transport=udp> Via: SIP/2.0/UDP 82.215.163.67:5060;branch=z9hG4bK477735439 Content-Length: 21314:07:58 19Mar2007 DEBUG SipProcessor [SipProcessor[4]]- <<<<<<<<< Response Received <<<<<<<<< SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 82.215.163.67:5060;branch=z9hG4bK477735439 From: <sip:3405300695@82.215.163.5>;tag=01E9CCA04D3CF9B8B3BE20CE1385BC2A To: <sip:390104491079@82.215.163.67>;tag=13FB8534-58 Date: Mon, 25 Mar 2002 04:04:50 GMT Call-ID: 11111783604896-30787@SVIGateway Server: Cisco-SIPGateway/IOS-12.x CSeq: 1 INVITE Allow: INVITE,CANCEL,ACK,BYE,INFO,OPTIONS,UPDATE,REGISTER,SUBSCRIBE,NOTIFY,PRACK,RE FER Allow-Events: telephone-event Contact: <sip:199@82.215.133.50:5060> Content-Type: application/sdp Content-Disposition: oSystemsSIP-GW-UserAg Content-Length: 235 14:07:58 19Mar2007 DEBUG SipResponse [SipProcessor[4]]- >>>>>>>>> Sending Response >>>>>>>>> SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 82.215.163.5:5060;branch=z9hG4bK6a4fa6b1 Max-Forwards: 69 From: <sip:3405300695@82.215.163.5>;tag=6a4fa6b1 To: <sip:390104491079@82.215.163.67> CSeq: 1 INVITE Call-ID: 11111783604896-30787@SVIGateway Content-Type: application/sdp Content-Length: 235 v=0 o=CiscoSystemsSIP-GW-UserAgent 9756 1908 IN IP4 82.215.133.50 s=SIP Call c=IN IP4 82.215.133.50 t=0 0 m=audio 19450 RTP/AVP 0 99 c=IN IP4 82.215.133.50 a=rtpmap:0 PCMU/8000 a=rtpmap:99 telephone-event/8000 a=fmtp:99 0-15 14:08:07 19Mar2007 DEBUG SipProcessor [SipProcessor[3]]- <<<<<<<<< Request Received <<<<<<<<< ACK sip:199@82.215.133.50 SIP/2.0 Via: SIP/2.0/UDP 82.215.163.67;branch=z9hG4bK07de.99a696f6.0 From: <sip:3405300695@82.215.163.5>;tag=01E9CCA04D3CF9B8B3BE20CE1385BC2A Call-ID: 11111783604896-30787@SVIGateway To: <sip:390104491079@82.215.163.67>;tag=13FB8534-58 CSeq: 1 ACK User-Agent: OpenSer (1.2.0-pre6-notls (i386/linux)) Content-Length: 0 14:08:07 19Mar2007 DEBUG SipProcessor [SipProcessor[4]]- <<<<<<<<< Response Received <<<<<<<<< SIP/2.0 503 Service Unavailable Via: SIP/2.0/UDP 82.215.163.67:5060;branch=z9hG4bK477735439 From: <sip:3405300695@82.215.163.5>;tag=01E9CCA04D3CF9B8B3BE20CE1385BC2A To: <sip:390104491079@82.215.163.67>;tag=13FB8534-58 Date: Mon, 25 Mar 2002 04:04:50 GMT Call-ID: 11111783604896-30787@SVIGateway Server: Cisco-SIPGateway/IOS-12.x CSeq: 1 INVITE Allow-Events: telephone-event Reason: Q.850;cause=41 Content-Length: 0 The signalling is not correct but, I have looked your code and believe that it is right, revise it and you check if you have the last version of WeSIP and you return to try, because the last release commited in HYPERLINK "http://www.wesip.com/mediawiki/index.php/Downloads:WeSIP_Beta_0.1"http://ww w.wesip.com/mediawiki/index.php/Downloads:WeSIP_Beta_0.1 was fixed a bug with the ApplicationSessions. In my test application I reply your behaviour(with 5xx, with AppSession attributes) and all have working perfectly, I dont understand nothing :( Sorry Good Luck. Antonio -----Mensaje original----- De: tele [mailto:tele@plexia.com] Enviado el: martes, 20 de marzo de 2007 16:46 Para: users(a)openser.org CC: antonio.abajo(a)voztele.com Asunto: Re: RV: [Users] WeSIP session question Hola Antonio, Your example works great and the code is more clear and correct than mine :) i was not clear, my problem was only with the 503 Service Unavailable response, that means a 5xx Server Failure, is it possibile that when the container or openser with seas recive a 5xx response is not able to do for example a creation of a new invite to UA3 recover from the same session?. Or probably i'm occur in a 473 response for an incorrect use of SipApplicationSession. anyway with a 480 Temporarily Unavailable response from the UA2 i solve my problem. thank you very much :tele On Mon, 2007-03-19 at 19:27 +0100, Antonio Abajo wrote: > Hola tele ;) > > I have tested an example similar to yours, and it works ok. It's de > following: > > UA1 ---[1]--> WeSIP --[2]--486 Busy Here---> UA2 > | > [3] > ---OK----_> UA3 > > [1] UA1 generates an INVITE to UA2 ant it 's forwarded to UA2 with a B2BUA > behaviour. In do INVITE. I have implemented the following: > > protected void doInvite(SipServletRequest invite){ > SipServletRequest otherInvite = sf.createRequest(invite, false); > SipURI sipUri = sf.createSipURI("UA2","proxy"); > otherInvite.setRequestURI(sipUri); > otherInvite.getSession().setAttribute("REQUEST", otherInvite); > > otherInvite.getSession().setAttribute("PEER_SESSION",invite.getSession()); > > invite.getSession().setAttribute("PEER_SESSION",otherInvite.getSession()); > invite.getSession().setAttribute("REQUEST", invite); > otherInvite.send(); > } > > [2] UA2 declines the call and a 486 response is received by WeSIP and > process it in doErrorResponse: > > protected void doErrorResponse(SipServletResponse errorResponse) { > switch(errorResponse.getStatus()){ > case 486: > SipServletRequest request = (SipServletRequest) > errorResponse.getSession().getAttribute("REQUEST"); > SipSession otherSession = (SipSession) > errorResponse.getSession().getAttribute("PEER_SESSION"); > SipURI sipUri = sf.createSipURI("UA3", "proxy"); > request.setRequestURI(sipUri); > SipServletRequest newRequest = > sf.createRequest(request,false); > newRequest.getSession().setAttribute("REQUEST", newRequest); > newRequest.getSession().setAttribute("PEER_SESSION", > otherSession); > otherSession.setAttribute("PEER_SESSION", > newRequest.getSession()); > newRequest.setHeader("X-SSVTPBX", "yes"); > newRequest.send(); > break; > } > } > > [3] UA3 Recevies the second call and it takes down. > > > I do not understand the cause of error. I annex you the code of simple sip > application example that replies to your problem. You can start it up and > checking if it works. Else if work for you, I would attempt watching the > particular case when a 5XX responses are received. > > Sorry... > > Best regards. > Antonio. > > -----Mensaje original----- > De: tele [mailto:tele@plexia.com] > Enviado el: lunes, 19 de marzo de 2007 14:33 > Para: Antonio Abajo Álvarez > Asunto: RE: [Users] WeSIP session question > > Hola Antonio, > > The scenario is more complex, i'll try to explain it: > > PSTN > | > | > UA---->GW ------> WeSIP(B2BUA) > | > | > mediaserver > > > GW: 82.215.163.5 > WeSIP: 82.215.163.67 > MS: 82.215.133.50 > > in the mediaserver there is an vxml script that i play in early media > and in case of particular event return to wesip a 503 temporaly > unavailable or e 410 Gone. So my B2BUA application have control of this > and can do stuff with the 503 and 410. > > in particular, in case of 503 temporaly unavailable i get the upstream > session and create a new invite to the media server for play another > announcement associated. in case of 410 gone i generate a new invite to > the GW with the original URI request for the correct termination. > > Yes when the session is removed i'm able to send another call. > > attached here the logs and the servlet. > > don't care about the hardcoded IP and the repeated code :-) > i'm doing testing.. > > regards, > > :tele > > > On Mon, 2007-03-19 at 13:29 +0100, Antonio Abajo Álvarez wrote: > > Hi Tele, > > > > I don't understand very well the problem., for what I understand you have > > the following: > > > > > > UA1 --------------------- WeSIP --------------------- UA2 > > > > ---INV/4XX-6XX/ACK (SS1) --> ----INV/4XX-6XX/ACK(SS2)--> > > > > You try to send another call and receive the 473 response of WeSIP... > > > > ------INV/473/ACK (SS1) --> > > > > And when the session has been removed you can send another call. > > > > If it is the case, I understand that the 473 response is send from > > application or from openser script configuration, because the internal > > behaviour of SIP doesn't send this response automatically. > > > > Can you verify if it is the case? > > > > Thank you very much... > > > > Antonio. > > > > -----Mensaje original----- > > De: users-bounces(a)openser.org [mailto:users-bounces@openser.org] En nombre > > de tele > > Enviado el: lunes, 19 de marzo de 2007 12:35 > > Para: users(a)openser.org > > Asunto: [Users] WeSIP session question > > > > Hi, > > > > I've a problem with WeSIP in B2BUA mode, in case of failed call 4xx-6xx > > correctly terminated, when i try to send another call to WeSIP i recive > > a "473 Filtered destination" then for send another call i've to wait > > WeSIP complete some management with session: > > > > 14:10:16 19Mar2007 DEBUG SipConnector [SipProcessor[3]]- recycle: > > Recycling processor SipProcessor[3] > > 14:10:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- AppSession Id > > [B4D6C9C4288784A68E032D20AB78BD8E] with a number of sessions =1 > > 14:10:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- SipSession > > [z9hG4bK69e6006f] in state [3] with lifetime of :74490 > > 14:10:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- AppSession Id > > [E3E1D9414BC47572CBC73EC7B4A53531] with a number of sessions =1 > > 14:10:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- SipSession > > [z9hG4bK69e68616] in state [3] with lifetime of :40281 > > 14:11:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- AppSession Id > > [B4D6C9C4288784A68E032D20AB78BD8E] with a number of sessions =1 > > 14:11:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- SipSession > > [z9hG4bK69e6006f] in state [3] with lifetime of :134500 > > 14:11:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- AppSession Id > > [E3E1D9414BC47572CBC73EC7B4A53531] with a number of sessions =1 > > 14:11:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- SipSession > > [z9hG4bK69e68616] in state [3] with lifetime of :100291 > > 14:12:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- AppSession Id > > [B4D6C9C4288784A68E032D20AB78BD8E] with a number of sessions =0 > > 14:12:56 19Mar2007 DEBUG StandardAppSessionManager > > [StandardAppSessionManager[/inapp]]- Remove AppSession > > [B4D6C9C4288784A68E032D20AB78BD8E] > > > > When i see Remove AppSession i'm able to send another call... > > I've read the sip servlet spec about that and i'm trying to invalidate() > > or setExpires() to SiApplicationSession in case of failed call. but it's > > not clear how to do yet. > > > > i can provide the full debug if needed. > > > > thank you! > > > > regards > > > > :tele > > > > > > > > _______________________________________________ > > Users mailing list > > Users(a)openser.org > > http://openser.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.14/727 - Release Date: 19/03/2007 11:49 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.14/727 - Release Date: 19/03/2007 11:49 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.14/727 - Release Date: 19/03/2007 11:49 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.14/727 - Release Date: 19/03/2007 11:49

1 0

[Users] DB migration
by Leonid Fainshtein 20 Mar '07

20 Mar '07

Hi, I didn't understand the proposed process of MySQL DB migration from ver.1.1 to 1.2 For example, the result of "openser_mysqldb.sh migrate openser openser12" will be a new database openser12. But how can I copy/rename openser12 to openser? Does it mean that from now, all of my auxiliary software must work with openser12? Thank you, Leonid Fainshtein ******************************************** This outgoing mail message was scanned by McAfee GroupShield Engine

2 1

[Users] Help with dbtext location table - Almost there!
by Daryl Sanders 20 Mar '07

20 Mar '07

I have been struggling to get usrloc to work with... modparam("usrloc", "db_mode", 1) OpenSER 1.2 starts fine but gives the following error when a phone tries to register: 2(26634) db_insert_ucontact(): Error while inserting contact 2(26634) ERROR:usrloc:insert_ucontact: failed to insert in database Regards, Daryl

1 0

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