Sorry, I hit send when I meant to hit save while I pulled some info. The trace below though shows the start of the loop of ACKs. The ACKs are getting sent to 75.101.136.125, when then should be going to the endpoint. It would appear the transaction is not being identified. I'm still looking at why, hence not wanting to send this yet...but any early ideas would be great ;)
-dg On Wed, Oct 14, 2009 at 4:20 PM, Daniel Goepp <[email protected]> wrote: > I'm sure that Raul had a good point that I'm crazy for doing this, but > right now unfortunately I do not have a lot of options, and believe with > some solid logic in the config can resolve this issue. Right now I appear > to be having an ACK come back from a 200 that turns into an endless loop. > I'm using > > advertised_address="75.101.136.125" > > > > U 10.250.7.164:5060 -> 76.102.118.209:3724 > SIP/2.0 200 OK. > Via: SIP/2.0/UDP 192.168.1.102:3724 > ;received=76.102.118.209;branch=z9hG4bK-d8754z-ff34ad60b13c376a-1---d8754z-;rport=3724. > Call-ID: NTU3NTE3NmZiNjVkNGYzNWEzYWVhZWQ4MjhhYjczN2E.. > CSeq: 2 INVITE. > Contact: <sip:[email protected]:11386>. > From: "Daniel Goepp" <sip:[email protected] <sip%[email protected]> > >;tag=ac7fa632. > To: "2001" <sip:[email protected] <sip%[email protected]> > >;tag=8f7b7e78f8cb0eca. > Record-Route: <sip:75.101.136.125;lr=on>. > Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY. > Server: TANDBERG/257 (TE2.0.0.191892). > Supported: > replaces,100rel,timer,gruu,path,outbound,com.tandberg.sdp.extensions.v1. > Session-Expires: 500; refresher=uas. > Min-SE: 90. > Content-Type: application/sdp. > Content-Length: 217. > . > v=0. > o=tandberg 103 1 IN IP4 192.168.1.101. > s=-. > c=IN IP4 192.168.1.101. > b=CT:64. > t=0 0. > m=audio 2330 RTP/AVP 0 101. > b=TIAS:64000. > a=rtpmap:0 PCMU/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > a=sendrecv. > > > U 76.102.118.209:3724 -> 10.250.7.164:5060 > ACK sip:[email protected]:11386 SIP/2.0. > Via: SIP/2.0/UDP 192.168.1.102:3724 > ;branch=z9hG4bK-d8754z-6d520059c54f5b74-1---d8754z-;rport. > Max-Forwards: 70. > Route: <sip:75.101.136.125;lr>. > Contact: <sip:[email protected]:3724>. > To: "2001"<sip:[email protected] <sip%[email protected]> > >;tag=8f7b7e78f8cb0eca. > From: "Daniel Goepp"<sip:[email protected] <sip%[email protected]> > >;tag=ac7fa632. > Call-ID: NTU3NTE3NmZiNjVkNGYzNWEzYWVhZWQ4MjhhYjczN2E.. > CSeq: 2 ACK. > Proxy-Authorization: Digest username="1001",realm="vidtel.com > ",nonce="4ad65ba02105a03bfdc0e3839160a42b5e1d90ac",uri=" > sip:[email protected] <sip%[email protected]> > ",response="0eea648b121320214ab8ec908eb97446",algorithm=MD5. > User-Agent: eyeBeam release 1104g stamp 54685. > Content-Length: 0. > . > > > U 10.250.7.164:5060 -> 75.101.136.125:5060 > ACK sip:[email protected]:11386 SIP/2.0. > Via: SIP/2.0/UDP 75.101.136.125;branch=z9hG4bK3128.7db9df05.2. > Via: SIP/2.0/UDP 192.168.1.102:3724 > ;received=76.102.118.209;branch=z9hG4bK-d8754z-6d520059c54f5b74-1---d8754z-;rport=3724. > Max-Forwards: 69. > Route: <sip:75.101.136.125;lr>. > Contact: <sip:[email protected]:3724>. > To: "2001"<sip:[email protected] <sip%[email protected]> > >;tag=8f7b7e78f8cb0eca. > From: "Daniel Goepp"<sip:[email protected] <sip%[email protected]> > >;tag=ac7fa632. > Call-ID: NTU3NTE3NmZiNjVkNGYzNWEzYWVhZWQ4MjhhYjczN2E.. > CSeq: 2 ACK. > Proxy-Authorization: Digest username="1001",realm="vidtel.com > ",nonce="4ad65ba02105a03bfdc0e3839160a42b5e1d90ac",uri=" > sip:[email protected] <sip%[email protected]> > ",response="0eea648b121320214ab8ec908eb97446",algorithm=MD5. > User-Agent: eyeBeam release 1104g stamp 54685. > Content-Length: 0. > . > > -dg > > > > On Wed, Oct 7, 2009 at 11:20 PM, Bogdan-Andrei Iancu < > [email protected]> wrote: > >> Hi Daniel, >> >> Try using set_advertised_address() before sending the call out. >> http://www.opensips.org/Resources/DocsCoreFcn#toc125 >> >> or use the record_route_preset() function : >> http://www.opensips.org/html/docs/modules/devel/rr.html#id228590 >> >> Regards, >> Bogdan >> >> Daniel Goepp wrote: >> > After further investigation, this only updating the Via header, but >> > the RR is remaining untouched: >> > >> > Record-Route: <sip:10.250.7.164;lr=on> >> > >> > Ideas about how I might get this field updated correctly? >> > >> > Thanks >> > >> > -dg >> > >> > On Wed, Oct 7, 2009 at 2:10 PM, Bogdan-Andrei Iancu >> > <[email protected]> wrote: >> > >> >> Hi Daniel, >> >> >> >> try using the advertise_address and advertise_port to force opensips in >> >> using the public IPs of the NAT: >> >> http://www.opensips.org/Resources/DocsCoreFcn#toc24 >> >> >> >> Regards, >> >> Bogdan >> >> >> >> Daniel Goepp wrote: >> >> >> >>> I am trying to setup OpenSIPs to run behind a firewall, and not >> >>> finding much information regarding how to get OpenSIPs to be aware of >> >>> the public IP for it's signaling. The firewall is setup with a 1 to 1 >> >>> NAT for the public and private IPs, and right now all udp and tcp >> >>> traffic is being passed directly through. Has anyone successfully >> >>> gotten OpenSIPs setup like this? If so, can you please provide any >> >>> information on how it was setup. >> >>> >> >>> TIA >> >>> >> >>> -dg >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> >> >> > >> > _______________________________________________ >> > 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 >> > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
