Amazing!!! Will do that instead. Thanks Bogdan! Ciao,
Nick. On 3/25/13, Bogdan-Andrei Iancu <[email protected]> wrote: > Hi Nick, > > In a similar way you can use the set_advertised_address() function > (http://www.opensips.org/Resources/DocsCoreFcn18#toc145) only for calls > that really go outside your net (on public side) ; this is instead of > global option of advertise_address. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > On 03/20/2013 06:04 PM, Nick Khamis wrote: >> Hello Bogdan, >> >> The think is with advertise_address is that I find local traffic >> behind the same NAT goes outside of the network and back into the >> network. If I can insert record_route_preset in the correct spots >> within our configuration and (1) differentiate between internet and >> intranet src, and (2) form a RR that suffice, it would be a smoother >> approach? >> >> I will post my solution for others to see. >> >> N. >> >> On 3/20/13, Bogdan-Andrei Iancu<[email protected]> wrote: >>> HI Nick, >>> >>> Using the advertise_address will also do the trick for you, no need to >>> do the record_route_preset(). >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> >>> On 03/19/2013 05:52 PM, Nick Khamis wrote: >>>> Hello Bogdan, >>>> >>>> Thank you so much for your response. We did have an RR problem that >>>> did not allow for an "ACK" to our "200 OK". Our solution was to change >>>> "advertised_address" to use the public IP instead of the local net, >>>> which seemed to get the RR problem solved. The server related global >>>> parameters we are using are as follow: >>>> >>>> alias=<public ip> >>>> auto_aliases=no >>>> disable_dns_failover=yes >>>> sip_warning=no >>>> >>>> port=5060 >>>> listen=udp:192.168.2.5:5060 >>>> advertised_address=<public ip> >>>> >>>> This got the external ACK responses to our 200, but only one way audio >>>> (probably RTP proxy related, and started a new message for that >>>> issue). >>>> >>>> The question is, Should I change "advertised_address" back to private >>>> IP, and use "record_route_preset" instead? In the meanwhile, I will >>>> try it. >>>> >>>> Nick. >>>> >>>> On 3/19/13, Bogdan-Andrei Iancu<[email protected]> wrote: >>>>> Hi Nick, >>>>> >>>>> As I suspect that your opensips is not an end-point in the call (but >>>>> simply a proxy), I guess the right approach is to reflect the network >>>>> changing in the RR headers, and not in Contact (contact reflects the >>>>> end >>>>> points in dialog). >>>>> >>>>> I suggest using the record_route_preset() and pushing all the time the >>>>> public IP of opensips in the RR header. >>>>> >>>>> Regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> >>>>> >>>>> On 03/19/2013 04:43 PM, Nick Khamis wrote: >>>>>> Hello Muhammad, thanks again for your response. On our test >>>>>> environment, our opensips+rtpproxy server is behind NAT, and the >>>>>> reason we are modifying the contact header is to point to >>>>>> 1001@<opensips-public-ip> instead of 1001@<opensips-private-ip>. >>>>>> UA >>>>>> 1001 is also behind the same NAT. >>>>>> >>>>>> My first question, do I need to modify the contact header? Or should >>>>>> I >>>>>> be paying closer attention to the SDP payload. Making sure c=, and o= >>>>>> are pointing to the right locations? >>>>>> >>>>>> Your help is greatly appreciated. >>>>>> >>>>>> Nick. >>>>>> >>>>>> On 3/19/13, Muhammad Shahzad<[email protected]> wrote: >>>>>>> Yup, that's expected to happen. ACK is sent to Contact header of 200 >>>>>>> OK. >>>>>>> So, if you mess up with it, then unexpected results will happen, as >>>>>>> in >>>>>>> your >>>>>>> case you are perhaps setting Contact address of 200 OK pointing to >>>>>>> opensips >>>>>>> itself, instead of destination party, so ACK will obviously loop as >>>>>>> expected. >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 18, 2013 at 5:55 PM, Nick Khamis<[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello Everyone, >>>>>>>> >>>>>>>> We are changing the "Contact" header in the on_reply to a public ip >>>>>>>> address using: >>>>>>>> >>>>>>>> onreply_route[1] { >>>>>>>> xlog("incoming reply\n"); >>>>>>>> if (has_body("application/sdp")) { >>>>>>>> remove_hf("Contact"); >>>>>>>> append_hf("Contact: >>>>>>>> <sip:[email protected]>\r\n"); >>>>>>>> append_hf("P-hint: Onreply-route >>>>>>>> - >>>>>>>> fixcontact \r\n"); >>>>>>>> >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> When doing so, ACK is going into a loop: >>>>>>>> >>>>>>>> U 2013/03/18 13:42:11.021017 75.15.201.2:5060 -> >>>>>>>> 192.168.2.5:5060 >>>>>>>> ACK sip:75.15.201.2;lr;did=b03.4af9f8f3 SIP/2.0. >>>>>>>> Call-ID: [email protected]. >>>>>>>> CSeq: 102 ACK. >>>>>>>> From: "15178334003"<sip:[email protected]>;tag=91641. >>>>>>>> To:<sip:[email protected]>;tag=2643FD58-346926A7. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2. >>>>>>>> Via: SIP/2.0/UDP 7 >>>>>>>> >>>>>>>> >>>>>>>> Your help is greatly appreciated, >>>>>>>> >>>>>>>> Nick. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>>> -- >>>>>>> Mit freundlichen Grüßen >>>>>>> Muhammad Shahzad >>>>>>> ----------------------------------- >>>>>>> CISCO Rich Media Communication Specialist (CRMCS) >>>>>>> CISCO Certified Network Associate (CCNA) >>>>>>> Cell: +49 176 99 83 10 85 >>>>>>> MSN: [email protected] >>>>>>> Email: [email protected] >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> [email protected] >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
