[OpenSIPS-Users] Fix_nated_sdp
Hi All,
I¹ve got a problem with fix_nated_sdp, whenever I call the method in the
request route it doesn¹t seems to take effect. My INVITE c= o= list the
proxy IP instead of the IP which I¹ve set in the method 2nd argument. The
weird thing, fix_nated_sdp in my reply route seems to work just fine. Below
are part of my scripts:
Route[4] {
if(to_uri=~^sip:([A-Z][a-z])([A-Z][a-z])@*)
{
xlog(L_INFO, DBG: P2P Call [$fu] - [$tu]);
if(!lookup(location))
{
xlog(L_INFO, DBG: P2P Peer not found [$tu] from
[$fu]($si));
sl_send_reply(404, User Offline);
exit;
}
if(isbflagset(6))
{
xlog(L_INFO, DBG: NATed P2P Call [$fu] - [$tu], force
RTP);
fix_nated_sdp(³10², ³$si²);
}
}
}
onreply_route[1]
{
if(client_nat_test(7))
{
fix_contact();
setbflag(6);
}
if(status=~(180)|(183)|2[0-9][0-9])
{
if(search(^Content-Type:[ ]*application/sdp))
{
if(isbflagset(6) (!to_uri=~sip:[+][0-9][0-9][0-9...@*))
{
xlog(L_INFO, DBG: Reply - S=$rs D=$rr F=$fu T=$tu
[$rm], force RTP);
fix_nated_sdp(³10², ³$si²);
exit;
}
}
}
xlog(L_INFO, DBG: Reply - S=$rs D=$rr F=$fu T=$tu [$rm]);
}
E.g:
INVITE
y.y.y.y 202.202.202.202 x.x.x.x(external IP)
A -- Proxy -- B
c=192.168.1.2 c=202.202.202.202
o=192.168.1.2o=202.202.202.202
200 response
x.x.x.x 202.202.202.202 y.y.y.y (external IP)
B -- Proxy -- A
c=192.168.0.2c=x.x.x.x
o=192.168.0.2 o=x.x.x.x
Hope there is some gurus out there able to shade some lights.
---
Regards,
Lawrence Na Chong Guan
---
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fix_nated_sdp
Hi Lawrence,
Are you sure you SIP request is not spiralling on the proxy: A - Proxy
- Proxy - B ?? simply print the $si variable from script (via xlog)
just before the fix_nated_sdp().
Regards,
Bogdan
Lawrence Na (my-...@vyke) wrote:
Hi All,
I’ve got a problem with fix_nated_sdp, whenever I call the method in
the request route it doesn’t seems to take effect. My INVITE c= o=
list the proxy IP instead of the IP which I’ve set in the method 2nd
argument. The weird thing, fix_nated_sdp in my reply route seems to
work just fine. Below are part of my scripts:
Route[4] {
if(to_uri=~^sip:([A-Z][a-z])([A-Z][a-z])@*)
{
xlog(L_INFO, DBG: P2P Call [$fu] - [$tu]);
if(!lookup(location))
{
xlog(L_INFO, DBG: P2P Peer not found [$tu] from [$fu]($si));
sl_send_reply(404, User Offline);
exit;
}
if(isbflagset(6))
{
xlog(L_INFO, DBG: NATed P2P Call [$fu] - [$tu], force RTP);
fix_nated_sdp(“10”, “$si”);
}
}
}
onreply_route[1]
{
if(client_nat_test(7))
{
fix_contact();
setbflag(6);
}
if(status=~(180)|(183)|2[0-9][0-9])
{
if(search(^Content-Type:[ ]*application/sdp))
{
if(isbflagset(6) (!to_uri=~sip:[+][0-9][0-9][0-9...@*))
{
xlog(L_INFO, DBG: Reply - S=$rs D=$rr F=$fu T=$tu [$rm], force RTP);
fix_nated_sdp(“10”, “$si”);
exit;
}
}
}
xlog(L_INFO, DBG: Reply - S=$rs D=$rr F=$fu T=$tu [$rm]);
}
E.g:
INVITE
y.y.y.y 202.202.202.202 x.x.x.x(external IP)
A -- Proxy -- B
c=192.168.1.2 c=202.202.202.202
o=192.168.1.2 o=202.202.202.202
200 response
x.x.x.x 202.202.202.202 y.y.y.y (external IP)
B -- Proxy -- A
c=192.168.0.2 c=x.x.x.x
o=192.168.0.2 o=x.x.x.x
Hope there is some gurus out there able to shade some lights.
---
Regards,
*Lawrence Na Chong Guan
*---
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Re-invite problem - 491 Request Pending
Hello,
I was reading through and I've come to the conclusion the horse just isn't
dead enough. :)
Bogdan referred to fixing this once and for all, and I was wondering if
that had happened in 1.6.
If not, where is the appropriate place to insert the workaround Jeff K. had
come up with? I've tried it in various configurations in loose_route(),
since that's where the packets seem to hit. I have the same result every
time on 1.5.3. It takes 3ms to forward an INVITE but 6ms to forward an ACK.
Since the carrier in my case is sending the two less than 1ms apart, it
doesn't work so well.
Any suggestions would be great.
Thanks,
Jeff
On 10/7/09 2:50 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote:
Hi Jeff,
Some time, simply experiment with some configurations may provide a
quicker solution rather than start digging to the bottom to see what's
happening - of course, this is a good approach only for quick fixes - as
you said, at a point, you really need to understand how it's working.
calling t_check_trans() twice, for any method (except ACK and CANCEL
requests) simply returns the same result as first one (without any
processing). So,if you have an ACK - do not abuse this function as it
will do the matching each time you call it.
Regards,
Bogdan
Jeff Kronlage wrote:
Bogdan,
I apologize for Œbeating a dead horse¹. I get that this is a
frustration we¹re stuck with for various reasons.
I¹ve been writing my Opensips config on a daily basis for going on six
months now, and there¹s still a couple of ³weird² spots in my scripts
that drive me nuts (I literally have a comment above this code that
says ³NEEDS DEBUGGING²).
For anyone interested in the topic, please understand that I wrote
this particular fix Œunder the gun¹, we¹d just launched our product
and a handful of our customers couldn¹t receive calls from a network
we¹re peered with because their proxy server fired off an immediate
reinvite and my system couldn¹t accept it. This went so far as the
peered telco beginning to call me (unsuccessfully, of course! J)
because they were getting tickets from their users unable to contact mine.
Having said that, I was in a hurry, and came up with the code below. I
still to this day don¹t understand why calling t_check_trans() twice
was necessary, but I can say that if I eliminate one of them, the
system breaks down.
Any advice? Like any good IT/Developer type, I¹d like to totally
understand what my script is doing J
Cheers,
Jeff Kronlage
Data102//
*From:* users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Brett Nemeroff
*Sent:* Tuesday, October 06, 2009 7:15 AM
*To:* OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] Re-invite problem - 491 Request Pending
Bogdan,
I presently record the 200 OK ACK in my ACC, but I don't seem to
actually utilize it for anything at present. If I did the fix jeff
mentioned, will I no longer get that ACK in ACC?
so performing the t_check_trans() is faster than tm module's built in
matching? I'm not sure I get why this is faster. I would have thought
that the work t_check_trans does is similar to what the tm module
already does.
BTW ,is this a bug that is planned to be fixed? Or should I just
expect that this scripting fix be a regular part of my scripts (if so,
perhaps it should be in the example scripts?)
Thanks,
Brett
On Tue, Oct 6, 2009 at 8:01 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro wrote:
Hi Brett,
This is an ancient topic that needs to be solved once for all. The
bottom problem is that OpenSIPS / TM does try o match the 200OK ACK
against the INVITE transaction - and it should not do that as 200OK ACK
forms a separate transaction and it matches at dialog level, not
transaction level. Because of this, the 200OK ACK matching is not
reliable (especially if you do spirals on opensips) and it is also time
consuming.
Because of this, the 200OK ACK matching takes longer than processing of
a re-INVITE and here comes the changing in order.
IMO, this artificial / forced matching of 200 OK should be dropped.
But there are 2 modules using this:
ACC - for accounting ACK for 200 OK - not sure how many people do enable
this
OSP - no clue :D.
Regards,
Bogdan
Brett Nemeroff wrote:
Jeff,
Thanks for your reply. Is this in the loose route? or.. ? Does it
break anything else? Bogdan, anyway you can explain what's going on
here? :)
-Brett
On Mon, Oct 5, 2009 at 12:30 PM, Jeff Kronlage j...@data102.com
mailto:j...@data102.com
mailto:j...@data102.com mailto:j...@data102.com wrote:
Brett,
I had this same exact problem. The solution was a little clunky
but sending the ACK out statelessly solves the problem.
My code looks like:
t_check_trans();
if (is_method(ACK) !t_check_trans()) {
if (!forward()) sl_reply_error();
exit;
}
if (!t_relay())
Re: [OpenSIPS-Users] Re-invite problem - 491 Request Pending
Update... INVITEs make it through in 62ms, but ACKs in 95ms. And from the carrier the reINVITE comes in only 5ms after the ACK. - Jeff On 11/19/09 3:21 PM, Jeff Pyle jp...@fidelityvoice.com wrote: Hello, I was reading through and I've come to the conclusion the horse just isn't dead enough. :) Bogdan referred to fixing this once and for all, and I was wondering if that had happened in 1.6. If not, where is the appropriate place to insert the workaround Jeff K. had come up with? I've tried it in various configurations in loose_route(), since that's where the packets seem to hit. I have the same result every time on 1.5.3. It takes 3ms to forward an INVITE but 6ms to forward an ACK. Since the carrier in my case is sending the two less than 1ms apart, it doesn't work so well. Any suggestions would be great. Thanks, Jeff On 10/7/09 2:50 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Jeff, Some time, simply experiment with some configurations may provide a quicker solution rather than start digging to the bottom to see what's happening - of course, this is a good approach only for quick fixes - as you said, at a point, you really need to understand how it's working. calling t_check_trans() twice, for any method (except ACK and CANCEL requests) simply returns the same result as first one (without any processing). So,if you have an ACK - do not abuse this function as it will do the matching each time you call it. Regards, Bogdan Jeff Kronlage wrote: Bogdan, I apologize for Œbeating a dead horse¹. I get that this is a frustration we¹re stuck with for various reasons. I¹ve been writing my Opensips config on a daily basis for going on six months now, and there¹s still a couple of ³weird² spots in my scripts that drive me nuts (I literally have a comment above this code that says ³NEEDS DEBUGGING²). For anyone interested in the topic, please understand that I wrote this particular fix Œunder the gun¹, we¹d just launched our product and a handful of our customers couldn¹t receive calls from a network we¹re peered with because their proxy server fired off an immediate reinvite and my system couldn¹t accept it. This went so far as the peered telco beginning to call me (unsuccessfully, of course! J) because they were getting tickets from their users unable to contact mine. Having said that, I was in a hurry, and came up with the code below. I still to this day don¹t understand why calling t_check_trans() twice was necessary, but I can say that if I eliminate one of them, the system breaks down. Any advice? Like any good IT/Developer type, I¹d like to totally understand what my script is doing J Cheers, Jeff Kronlage Data102// *From:* users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Brett Nemeroff *Sent:* Tuesday, October 06, 2009 7:15 AM *To:* OpenSIPS users mailling list *Subject:* Re: [OpenSIPS-Users] Re-invite problem - 491 Request Pending Bogdan, I presently record the 200 OK ACK in my ACC, but I don't seem to actually utilize it for anything at present. If I did the fix jeff mentioned, will I no longer get that ACK in ACC? so performing the t_check_trans() is faster than tm module's built in matching? I'm not sure I get why this is faster. I would have thought that the work t_check_trans does is similar to what the tm module already does. BTW ,is this a bug that is planned to be fixed? Or should I just expect that this scripting fix be a regular part of my scripts (if so, perhaps it should be in the example scripts?) Thanks, Brett On Tue, Oct 6, 2009 at 8:01 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi Brett, This is an ancient topic that needs to be solved once for all. The bottom problem is that OpenSIPS / TM does try o match the 200OK ACK against the INVITE transaction - and it should not do that as 200OK ACK forms a separate transaction and it matches at dialog level, not transaction level. Because of this, the 200OK ACK matching is not reliable (especially if you do spirals on opensips) and it is also time consuming. Because of this, the 200OK ACK matching takes longer than processing of a re-INVITE and here comes the changing in order. IMO, this artificial / forced matching of 200 OK should be dropped. But there are 2 modules using this: ACC - for accounting ACK for 200 OK - not sure how many people do enable this OSP - no clue :D. Regards, Bogdan Brett Nemeroff wrote: Jeff, Thanks for your reply. Is this in the loose route? or.. ? Does it break anything else? Bogdan, anyway you can explain what's going on here? :) -Brett On Mon, Oct 5, 2009 at 12:30 PM, Jeff Kronlage j...@data102.com mailto:j...@data102.com mailto:j...@data102.com mailto:j...@data102.com wrote: Brett, I had this same exact problem. The solution was a
[OpenSIPS-Users] NAT changes to rtpproxy
We did a little custom work to rtp proxy to support putting it behind NAT. We have been using it for a while in our lab here, and it appears to be working quite well. We would like to contribute our work back to the project (its really not much). Basically all we did was add a parameter that it will use as the advertise address separating it from the bind address. Is anyone interested? Who would I contact with more information on what we have done? Thanks -dg ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] CDRTool/Radius Problem
Hi, I am installing Opensips v 1.6.0, MediaProxy v 2.3.9 and CDRTool v 6.9.9 on a test system. When a call finishes I get an error in the Opensips log: Nov 19 20:37:58 os4 media-dispatcher[9116]: error: failed to send radius accounting record: 'Sip-From-Tag' And Nothing gets added to the CDRTool or Radius Database. In the old versions I got error from /sbin/opensips when radius had trouble not from media-dispatcher. I know Radius is working because I can telnet in to the radius server. I get no errors in the CDRTool/Radius Server log. Does anyone have a suggestion? Thanks, Alberto___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool/Radius Problem
Hi Alberto, 2009/11/19 Alberto Listas lis...@b2br.net Hi, I am installing Opensips v 1.6.0, MediaProxy v 2.3.9 and CDRTool v 6.9.9 on a test system. When a call finishes I get an error in the Opensips log: Nov 19 20:37:58 os4 media-dispatcher[9116]: error: failed to send radius accounting record: 'Sip-From-Tag' And Nothing gets added to the CDRTool or Radius Database. In the old versions I got error from /sbin/opensips when radius had trouble not from media-dispatcher. I know Radius is working because I can telnet in to the radius server. I get no errors in the CDRTool/Radius Server log. Does anyone have a suggestion? Thanks, Alberto http://lists.opensips.org/cgi-bin/mailman/listinfo/users Looks like a problem with the radius dictionaries. -Laszlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] How to force rtpproxy to replace varios c= lines in the SDP
Hi, I receive a wrong SDP from a gateway: v=0 o=Quintum 12062 399792571 IN IP4 88.8.88.146 s=VoipCall c=IN IP4 88.8.88.146 t=0 0 m=audio 10726 RTP/AVP 8 101 c=IN IP4 88.8.88.146 a=rtpmap:8 PCMA/8000/1 a=ptime:20 a=rtpmap:101 telephone-event/8000/1 a=sendrecv As you see c= line appears twice which IMHO is wrong. When I apply RtpProxy for this SDP it replaces the second c= line and but phone takes the first one so I get one-way-audio. Is there any workaroud without using string replaces? Thanks. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] How to force rtpproxy to replace varios c= lines in the SDP
El Jueves, 19 de Noviembre de 2009, Ovidiu Sas escribió: Check the docs: http://www.opensips.org/html/docs/modules/devel/nathelper.html#id271367 - flag 'c'. Two c= lines are ok according to the rfc. Thanks, using c flag is the key :) -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] How to force rtpproxy to replace varios c= lines in the SDP
El Jueves, 19 de Noviembre de 2009, Iñaki Baz Castillo escribió: El Jueves, 19 de Noviembre de 2009, Ovidiu Sas escribió: Check the docs: http://www.opensips.org/html/docs/modules/devel/nathelper.html#id271367 - flag 'c'. Two c= lines are ok according to the rfc. Thanks, using c flag is the key :) Oh my good!!! there was no bug at all, neither in the gateway, OpenSIPS rtpproxy module or client... then problem is my microphone which is broken now! x -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
