sr-users

sr-users@lists.kamailio.org

20 participants
37472 discussions

Start a nNew thread

Re: [Kamailio-Users] Remote-Party-ID header
by ingdavidcespedes＠cable.net.co 07 Nov '08

07 Nov '08

2 1

Re: [Kamailio-Users] CANCEL and 487 Request Terminated
by ingdavidcespedes＠cable.net.co 06 Nov '08

06 Nov '08

I think that's the way it should be. First it receive 487 from SBC and immediately it responds it to SBC with the ACK. Then it passes the 487 to the UAC and receive the ACK, that's all. It doesn't have to forward that last ACK to the SBC. ----- Mensaje original ----- De: Krom <kyle.romulas(a)gmail.com> Fecha: Jueves, Noviembre 6, 2008 4:06 pm Asunto: Re: [Kamailio-Users] CANCEL and 487 Request Terminated > My apologies for the drawing. Openser is receiving the 487 from the > SBC, ACKing back to the SBC and then passing the 487 to the UAC and > the the UAC ACK's back to Openser. At which time the error occurs > because the ACK will not be forwarded since it already ACK'd for the > 487 to the SBC. > > -Kyle > > On Thu, Nov 6, 2008 at 2:42 PM, <ingdavidcespedes(a)cable.net.co> > wrote:> The final 487 should go from openser to UAC, not from SBC > to UAC. That's why the final ACK is getting lost, because it was > allready ACK'd by openser. > > > > ----- Mensaje original ----- > > De: Krom <kyle.romulas(a)gmail.com> > > Fecha: Jueves, Noviembre 6, 2008 1:18 pm > > Asunto: Re: [Kamailio-Users] CANCEL and 487 Request Terminated > > > >> Klaus, > >> > >> Some additional information. After viewing a trace I can see > that the > >> error is being generated from the last ACK received from the UAC. > >> OpenSER/Kamailio is ACK'ing to the 487 from the PSTN provider > and then > >> relaying the 487 to the UAC which in turn ACK's back. It is the > last>> ACK from the UAC that is getting the error on t_relay. I > can assume > >> because the ACK to the 487 was already sent by OpenSER/Kamailio > to the > >> PSTN upon receiving the initial 487. Something in the script I can > >> change to prevent this or just ignore the error and move on. :-) > >> > >> UAC OSER SBC > >> > >> CANCEL ---> | > >> > >> CANCEL ---> | > >> > >> <--- 200 canceling > >> > >> | <--- 200 OK > >> > >> | <--- 487 Request Terminated > >> > >> ACK ---> > >> > >> <--- 487 Reqest Terminated > >> > >> ACK ---> | > >> > >> > >> Regards, > >> -Kyle > >> > >> > >> On Thu, Nov 6, 2008 at 9:05 AM, Krom <kyle.romulas(a)gmail.com> > wrote:>> > Klaus, > >> > > >> > Thank you for the reply and the link. The link help in > checking my > >> > work. My script is very simple and even checking against the > >> compiled> scripted from sipwise.com the error persists. > >> > > >> > Here is my CANCEL and ACK handling. > >> > if(is_method("CANCEL") || is_method("ACK")) { > >> > if(t_check_trans()) { > >> > if(!t_relay()) sl_reply_error(); > >> > } > >> > exit; > >> > } > >> > > >> > Here is my route block for PSTN calls. > >> > route[4] > >> > { > >> > if (!load_gws()) { > >> > sl_send_reply("500", "Server Internal Error"); > >> > exit; > >> > } > >> > if (!next_gw()) { > >> > sl_send_reply("503", "Service Unavailable"); > >> > exit; > >> > } > >> > t_on_failure("2"); > >> > t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder > >> Controller> > >> > exit; > >> > > >> > } > >> > > >> > Here is my failure route. > >> > failure_route[2] > >> > { > >> > > >> > if(t_check_status("408|500|503")) { > >> > if (!next_gw()) { > >> > t_reply("503", "Service Unavailable"); > >> > exit; > >> > } > >> > t_on_failure("2"); > >> > t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder > >> Controller> } > >> > > >> > exit; > >> > > >> > } > >> > > >> > Any thoughts or errors you see? > >> > > >> > Regards. > >> > > >> > > >> > On Thu, Nov 6, 2008 at 3:56 AM, Klaus Darilion > >> > <klaus.mailinglists(a)pernau.at> wrote: > >> >> looks like the ACK is miss-routed. > >> >> > >> >> Usually calling t_relay() for ACK is sufficient (take a look at > >> the config > >> >> file generated with sipwise.com wizard for correct CANCEL/ACK > >> handling.>> > >> >> regards > >> >> klaus > >> >> > >> >> Krom schrieb: > >> >>> > >> >>> Et al, > >> >>> > >> >>> Version: openser-1.1.1-notls > >> >>> > >> >>> I am receiving the following after calling t_relay within the > >> default>>> route block. > >> >>> ERROR: t_newtran: transaction already in process 0xb0139638 > >> >>> WARNING:sl:sl_send_reply: I won't send a reply for ACK!! > >> >>> WARNING: script writer didn't release transaction > >> >>> > >> >>> This is happening when a downstream UAC dials outbound to the > >> PSTN and > >> >>> then terminates the call prior to the far ending answering. > >> >>> > >> >>> UAC send a CANCEL to the proxy, the proxy responds to the UAC > >> with a > >> >>> '200 canceling' and forwards the CANCEL to the PSTN provider. > >> >>> The PSTN provider sends 487 Request Terminated to the proxy and > >> the>>> proxy sends it on to the UAC. UAC responds with an ACK to > >> the proxy. > >> >>> > >> >>> Is this an issue? How do I handle this dialog withou > getting the > >> >>> t_relay error message? > >> >>> > >> >>> > >> >> > >> > > >> > > >> > > >> > -- > >> > Thanks, > >> > -- Kyle > >> > > >> > >> > >> > >> -- > >> Thanks, > >> -- Kyle > >> > >> _______________________________________________ > >> Users mailing list > >> Users(a)lists.kamailio.org > >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > >> > > > > > > > > -- > Thanks, > -- Kyle >

2 1

Re: [Kamailio-Users] CANCEL and 487 Request Terminated
by Krom 06 Nov '08

06 Nov '08

My apologies for the drawing. Openser is receiving the 487 from the SBC, ACKing back to the SBC and then passing the 487 to the UAC and the the UAC ACK's back to Openser. At which time the error occurs because the ACK will not be forwarded since it already ACK'd for the 487 to the SBC. -Kyle On Thu, Nov 6, 2008 at 2:42 PM, <ingdavidcespedes(a)cable.net.co> wrote: > The final 487 should go from openser to UAC, not from SBC to UAC. That's why the final ACK is getting lost, because it was allready ACK'd by openser. > > ----- Mensaje original ----- > De: Krom <kyle.romulas(a)gmail.com> > Fecha: Jueves, Noviembre 6, 2008 1:18 pm > Asunto: Re: [Kamailio-Users] CANCEL and 487 Request Terminated > >> Klaus, >> >> Some additional information. After viewing a trace I can see that the >> error is being generated from the last ACK received from the UAC. >> OpenSER/Kamailio is ACK'ing to the 487 from the PSTN provider and then >> relaying the 487 to the UAC which in turn ACK's back. It is the last >> ACK from the UAC that is getting the error on t_relay. I can assume >> because the ACK to the 487 was already sent by OpenSER/Kamailio to the >> PSTN upon receiving the initial 487. Something in the script I can >> change to prevent this or just ignore the error and move on. :-) >> >> UAC OSER SBC >> >> CANCEL ---> | >> >> CANCEL ---> | >> >> <--- 200 canceling >> >> | <--- 200 OK >> >> | <--- 487 Request Terminated >> >> ACK ---> >> >> <--- 487 Reqest Terminated >> >> ACK ---> | >> >> >> Regards, >> -Kyle >> >> >> On Thu, Nov 6, 2008 at 9:05 AM, Krom <kyle.romulas(a)gmail.com> wrote: >> > Klaus, >> > >> > Thank you for the reply and the link. The link help in checking my >> > work. My script is very simple and even checking against the >> compiled> scripted from sipwise.com the error persists. >> > >> > Here is my CANCEL and ACK handling. >> > if(is_method("CANCEL") || is_method("ACK")) { >> > if(t_check_trans()) { >> > if(!t_relay()) sl_reply_error(); >> > } >> > exit; >> > } >> > >> > Here is my route block for PSTN calls. >> > route[4] >> > { >> > if (!load_gws()) { >> > sl_send_reply("500", "Server Internal Error"); >> > exit; >> > } >> > if (!next_gw()) { >> > sl_send_reply("503", "Service Unavailable"); >> > exit; >> > } >> > t_on_failure("2"); >> > t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder >> Controller> >> > exit; >> > >> > } >> > >> > Here is my failure route. >> > failure_route[2] >> > { >> > >> > if(t_check_status("408|500|503")) { >> > if (!next_gw()) { >> > t_reply("503", "Service Unavailable"); >> > exit; >> > } >> > t_on_failure("2"); >> > t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder >> Controller> } >> > >> > exit; >> > >> > } >> > >> > Any thoughts or errors you see? >> > >> > Regards. >> > >> > >> > On Thu, Nov 6, 2008 at 3:56 AM, Klaus Darilion >> > <klaus.mailinglists(a)pernau.at> wrote: >> >> looks like the ACK is miss-routed. >> >> >> >> Usually calling t_relay() for ACK is sufficient (take a look at >> the config >> >> file generated with sipwise.com wizard for correct CANCEL/ACK >> handling.>> >> >> regards >> >> klaus >> >> >> >> Krom schrieb: >> >>> >> >>> Et al, >> >>> >> >>> Version: openser-1.1.1-notls >> >>> >> >>> I am receiving the following after calling t_relay within the >> default>>> route block. >> >>> ERROR: t_newtran: transaction already in process 0xb0139638 >> >>> WARNING:sl:sl_send_reply: I won't send a reply for ACK!! >> >>> WARNING: script writer didn't release transaction >> >>> >> >>> This is happening when a downstream UAC dials outbound to the >> PSTN and >> >>> then terminates the call prior to the far ending answering. >> >>> >> >>> UAC send a CANCEL to the proxy, the proxy responds to the UAC >> with a >> >>> '200 canceling' and forwards the CANCEL to the PSTN provider. >> >>> The PSTN provider sends 487 Request Terminated to the proxy and >> the>>> proxy sends it on to the UAC. UAC responds with an ACK to >> the proxy. >> >>> >> >>> Is this an issue? How do I handle this dialog withou getting the >> >>> t_relay error message? >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > Thanks, >> > -- Kyle >> > >> >> >> >> -- >> Thanks, >> -- Kyle >> >> _______________________________________________ >> Users mailing list >> Users(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> > > -- Thanks, -- Kyle

1 0

[Kamailio-Users] CANCEL and 487 Request Terminated
by Krom 06 Nov '08

06 Nov '08

Et al, Version: openser-1.1.1-notls I am receiving the following after calling t_relay within the default route block. ERROR: t_newtran: transaction already in process 0xb0139638 WARNING:sl:sl_send_reply: I won't send a reply for ACK!! WARNING: script writer didn't release transaction This is happening when a downstream UAC dials outbound to the PSTN and then terminates the call prior to the far ending answering. UAC send a CANCEL to the proxy, the proxy responds to the UAC with a '200 canceling' and forwards the CANCEL to the PSTN provider. The PSTN provider sends 487 Request Terminated to the proxy and the proxy sends it on to the UAC. UAC responds with an ACK to the proxy. Is this an issue? How do I handle this dialog withou getting the t_relay error message? -- Thanks, -- Kyle

2 3

[Serusers] Assistance with SER setup
by Scott Seltzer 06 Nov '08

06 Nov '08

Hello, my name is Scott Seltzer, from ConnectMe (www.connectmevoice.com <http://www.connectmevoice.com/> ) Connectme is currently in the process of setting up SER for use as a Proxy and Registrar. We will ultimately need to be able to use an API to setup new SIP URIs for each new customer. We are not familiar at all with SER, and would like to find out what support options there may be out there. We would also be interested in using some consulting services to help get us started, and support us along the way. Please let me know if there is anybody that can help us out with this. Thanks! Scott Seltzer

1 0

[Serusers] FW: Support for SER setup
by Scott Seltzer 06 Nov '08

06 Nov '08

Hello, my name is Scott Seltzer, from ConnectMe (www.connectmevoice.com <http://www.connectmevoice.com> ) Connectme is currently in the process of setting up SER for use as a Proxy and Registrar. We will ultimately need to be able to use an API to setup new SIP URIs for each new customer. We are not familiar at all with SER, and would like to find out what support options there may be out there. We would also be interested in using some consulting services to help get us started, and support us along the way. Please let me know if there is anybody that can help us out with this. Thanks! Scott Seltzer

1 0

[Kamailio-Users] two endpoints
by Alex R.S.M 06 Nov '08

06 Nov '08

Hi, If ENUM lookup returns 2 destinations, does kamailio fork the message and send two INVITE? What function can be used to force kamailio to fork a message? Regards, Alex _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster…

2 1

[Kamailio-Users] rewriteuser with AVP
by Samuel Muller 06 Nov '08

06 Nov '08

Hello all, I've a little question : I got a username in an AVP by avp_load_radius, and I would rewrite the uri with it. The objectives is to replace the r-uri by an ipbx uri, then forward the call to it by a new branch (to not loose the phone number requested). in this case : 0123452000 is behind a spa9000. The user 0123452000 has an AVP called "ipbx", that i'm using to do some groups and permissions (plus the rewrite). actually, it does not work, i tried many ways : # load radius attributes of the callee if (!avp_load_radius("callee")) { xlog("L_INFO","-> user unknown in radius usr db : $ru"); route(15); # route PSTN } # verify the AVPs we got (caller and callee) xlog("L_INFO", " -AVP------------------------------------- "); avp_print(); xlog("L_INFO", " ----------------------------------------- "); # callee is behind an ipbx (avp ipbx) ? if (is_avp_set("$avp(s:callee_ipbx)")) { xlog("L_INFO", "-> callee is behind an ipbx : $avp(s:callee_ipbx)"); setflag(14); # flag IPBX #subst_user('/$rU$/$avp(s:callee_ipbx)/'); #rewriteuri("sip:$avp(s:callee_ipbx)@$rd"**); rewriteuser($avp(s:callee_ipbx)); } # callee in usrloc ? if (lookup("location")) { append_hf("P-hint: usrloc applied\r\n"); xlog("L_INFO","-> registered user called : $tu"); route(7); # route FORWARD } else { xlog("L_INFO","-> 480: local user not found in usrloc : $tu"); sl_send_reply("480","Temporarily Unavailable"); drop; } and in the debugs log : Nov 5 13:04:51 ser0 kamailio[2930]: -ROUTE--INBOUND-------------------------- Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: rc_auth Success Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: AVP 'callee_asserted_id'/0='0123452000'/0 has been added Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: AVP 'callee_ipbx'/0='spa9000'/0 has been added Nov 5 13:04:51 ser0 kamailio[2930]: -AVP------------------------------------- Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: p=0x7fb3d7e5cfe8, flags=0x0003 Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Iname=<callee_ipbx> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Ival_str=<spa9000 / 7> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: p=0x7fb3d7e5cf88, flags=0x0003 Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Iname=<callee_asserted_id> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Ival_str=<0123452000 / 10> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: p=0x7fb3d7e5ced8, flags=0x0003 Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Iname=<caller_asserted_id> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Ival_str=<0123451011 / 10> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: p=0x7fb3d7e5ce38, flags=0x0003 Nov 5 13:04:51 ser0 kamailio[2930]: ----------------------------------------- Nov 5 13:04:51 ser0 kamailio[2930]: -> callee is behind an ipbx : spa9000 Nov 5 13:04:51 ser0 kamailio[2930]: DBG:registrar:lookup: '$avp( s(a)sip.720.fr' Not found in usrloc Nov 5 13:04:51 ser0 kamailio[2930]: -> 480: local user not found in usrloc : sip:0123452000@sip.720.fr <sip%3A0123452000(a)sip.720.fr> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:parse_headers: flags=ffffffffffffffff Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:check_via_address: params 77.246.81.162, 192.168.0.134, 0 Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:destroy_avp_list: destroying list 0x7fb3d7e5d040 Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:receive_msg: cleaning up -> But, if I did it by : if (uri =~ "^sip:012345200{1}") { rewriteuri("sip:spa9000@sip.720.fr<sip%3Aspa9000(a)sip.720.fr> "); } if (lookup("location")) { append_hf("P-hint: usrloc applied\r\n"); xlog("L_INFO","-> registered user called : $tu"); route(7); # route FORWARD } it works great, and the call is ok (the ipbx forward correctly the request the phone behind him). Anyone has an idea ? thanks in advance ! -- Samuel MULLER

2 3

[Kamailio-Users] Fwd: Openser as Proxy and Asterisk as Registrar
by Cosimo Fadda 06 Nov '08

06 Nov '08

Hi David, thank you for you answer, 2008/11/6, ingdavidcespedes(a)cable.net.co <ingdavidcespedes(a)cable.net.co>: > > Hi! > > I had the same problem (My PC was responding everything it receives through > the default gateway "eth0" ). Everybody say that it was an Asterisk bug, > but it was a problem in the routing table. Yes, I'm new to Openser but I know quite well Asterisk, and I don't think it is a bug or a misconfiguration . Type route in a terminal and check if they are the way you are thinking. If > not, add the correct route. Tell me if it solve your problem. The route table is correct, but a strange thing happens since the SIP packet is sent from the correct nic, but un the UDP header of that packet I see as source the IP of the other nic (the one that received the orinal packet) I have to investigate a little more on this aspect anyway. C. David Cespedes > > ----- Mensaje original ----- > De: Cosimo Fadda <cfadda.lists(a)gmail.com> > Fecha: Miércoles, Noviembre 5, 2008 9:36 am > Asunto: [Kamailio-Users] Openser as Proxy and Asterisk as Registrar > > > Hi everybody > > I'd like to implement this scenario: > > > > ----------- ------------------- ---------- > > ----- > > | GW/FW > > |<----LAN1---->|eth0|Openser|eth1|<----LAN2---->|eth0|asterisk| -- > > >PSTN----------- ------------------- | ----- > > ---------- > > |_______________________________________________| > > > > > > > > > > > > Where: > > - Openser is reachable from the outside with a public IP > > forwarded to > > eth0 private address; > > > > - Asterisk is connected to Openser using another separated LAN > > - Openser acts as proxy (for requests coming from the outside) and > > Asterisk act as registrar and gateway. > > > > > > This is the description, now the questions: > > -since opneser has two different nics, how can configure it to > > properly > > send register request to asterisk? > > This is what currently happens: > > 192.168.40.68:5060: is eth0 Openser Address > > 192.168.12.165 is eth1 Openser Address > > 192.168.12.106 is Asterisk address > > 82.187.X.X is Openser public address > > Network 192.168.40.X is not reachable from net 192.168.12.X > > > > <-- SIP read from 192.168.40.68:5060: REGISTER sip:192.168.12.106 > > SIP/2.0 // 12.106 is Asterisk address > > Via: SIP/2.0/UDP 82.187.X.X;branch=z9hG4bKfe0f.21364c47.0 Via: > > SIP/2.0/UDP > > 192.168.40.254:2660 > ;rport=2265;received=82.187.Y.Ybranch=z9hG4bK532058BAC7C544E0961E038CC29B2106 > > > > From: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68> > >;tag=3189722840 > > To: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68>> > > Contact: "Cfadda" <sip:225@192.168.40.254:2660> > > Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X > > CSeq: 65140 REGISTER > > Expires: 1800 > > Max-Forwards: 69 > > User-Agent: X-PRO release 1105x > > Content-Length: 0 > > > > > > Nov 5 10:37:28 VERBOSE[23848] logger.c: --- (12 headers 0 lines) -- > > - > > Nov 5 10:37:28 VERBOSE[23848] logger.c: Using latest REGISTER > > request > > as basis request > > Nov 5 10:37:28 VERBOSE[23848] logger.c: Sending to 82.187.X.X : > > 5060 > > (non-NAT) > > Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to > > 192.168.40.68:5060: > > SIP/2.0 100 Trying > > Via: SIP/2.0/UDP 82.187.X.X > > ;branch=z9hG4bKfe0f.21364c47.0;received=192.168.40.68 > > Via: SIP/2.0/UDP > > 192.168.40.254:2660 > ;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 > > > > From: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68> > >;tag=3189722840 > > To: Cfadda <sip:225@82.187.X.X > > > Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X > > CSeq: 65140 REGISTER > > User-Agent: Asterisk PBX > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > > Contact: <sip:225@192.168.12.106 <sip%3A225(a)192.168.12.106>> > > Content-Length: 0 > > > > > > --- > > Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to > > 192.168.40.68:5060: > > SIP/2.0 401 Unauthorized > > Via: SIP/2.0/UDP 82.187.X.X > > ;branch=z9hG4bKfe0f.21364c47.0;received=192.168.40.68 > > Via: SIP/2.0/UDP > > 192.168.40.254:2660 > ;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 > > > > From: Cfadda <sip:225@82.187.X.X >;tag=3189722840 > > To: Cfadda <sip:225@82.187.X.X >;tag=as4c420a53 > > Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X > > CSeq: 65140 REGISTER > > User-Agent: Asterisk PBX > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > > WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", > > nonce="05f14a3e"Content-Length: 0 > > > > So asterisk sends response to the wrong interface. > > > > How can I solve this? > > > > Thanks in advance, > > > > C. > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > >

1 0

[Kamailio-Users] Fwd: Openser as Proxy and Asterisk as Registrar
by Cosimo Fadda 06 Nov '08

06 Nov '08

Hi Daniel, I'll try to use the force_send_sock function, maybe this solve the issue; btw I don't think it is a strictly Asterisk related problem, thank you for the hint, C. 2008/11/5, Daniel-Constantin Mierla <miconda(a)gmail.com>: > > Hello, > > On 11/05/08 16:36, Cosimo Fadda wrote: > >> Hi everybody >> I'd like to implement this scenario: >> >> ----------- ------------------- --------------- >> | GW/FW |<----LAN1---->|eth0|Openser|eth1|<----LAN2---->|eth0|asterisk| >> -->PSTN >> ----------- ------------------- | --------------- >> |_______________________________________________| >> >> >> >> Where: >> - Openser is reachable from the outside with a public IP forwarded to >> eth0 private address; >> >> - Asterisk is connected to Openser using another separated LAN >> - Openser acts as proxy (for requests coming from the outside) and >> Asterisk act as registrar and gateway. >> >> >> This is the description, now the questions: >> -since opneser has two different nics, how can configure it to properly >> send register request to asterisk? >> >> > if you want to force an interface for outgoing sip requests, see > force_send_sock() function: > > http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:1.4.x#force_send_so… > > This is what currently happens: >> 192.168.40.68:5060: is eth0 Openser Address >> 192.168.12.165 is eth1 Openser Address >> 192.168.12.106 is Asterisk address >> 82.187.X.X is Openser public address >> Network 192.168.40.X is not reachable from net 192.168.12.X >> >> <-- SIP read from 192.168.40.68:5060: REGISTER sip:192.168.12.106SIP/2.0 // 12.106 is Asterisk address >> Via: SIP/2.0/UDP 82.187.X.X;branch=z9hG4bKfe0f.21364c47.0 Via: SIP/2.0/UDP >> 192.168.40.254:2660;rport=2265;received=82.187.Y.Ybranch=z9hG4bK532058BAC7C544E0961E038CC29B2106 >> >> From: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68> >> >;tag=3189722840 >> To: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68>> >> Contact: "Cfadda" <sip:225@192.168.40.254:2660> >> Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X >> CSeq: 65140 REGISTER >> Expires: 1800 >> Max-Forwards: 69 >> User-Agent: X-PRO release 1105x >> Content-Length: 0 >> >> >> Nov 5 10:37:28 VERBOSE[23848] logger.c: --- (12 headers 0 lines) --- >> Nov 5 10:37:28 VERBOSE[23848] logger.c: Using latest REGISTER request as >> basis request >> Nov 5 10:37:28 VERBOSE[23848] logger.c: Sending to 82.187.X.X : 5060 >> (non-NAT) >> Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to >> 192.168.40.68:5060: >> SIP/2.0 100 Trying >> Via: SIP/2.0/UDP 82.187.X.X ;branch=z9hG4bKfe0f.21364c47.0;received= >> 192.168.40.68 >> Via: SIP/2.0/UDP 192.168.40.254:2660;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 >> >> From: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68> >> >;tag=3189722840 >> To: Cfadda <sip:225@82.187.X.X > >> Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X >> CSeq: 65140 REGISTER >> User-Agent: Asterisk PBX >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY >> Contact: <sip:225@192.168.12.106 <sip%3A225(a)192.168.12.106>> >> Content-Length: 0 >> >> >> --- >> Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to >> 192.168.40.68:5060: >> SIP/2.0 401 Unauthorized >> Via: SIP/2.0/UDP 82.187.X.X ;branch=z9hG4bKfe0f.21364c47.0;received= >> 192.168.40.68 >> Via: SIP/2.0/UDP 192.168.40.254:2660;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 >> >> From: Cfadda <sip:225@82.187.X.X >;tag=3189722840 >> To: Cfadda <sip:225@82.187.X.X >;tag=as4c420a53 >> Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X >> CSeq: 65140 REGISTER >> User-Agent: Asterisk PBX >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY >> WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="05f14a3e" >> Content-Length: 0 >> >> So asterisk sends response to the wrong interface. >> >> How can I solve this? >> >> > > Probably the right answer you will get on the asterisk mailing lists. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > >

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