Force OpenSER to use src_port instead of VIA port.

Hi,

How can I force OpenSER to send all SIP messages to source port of the UA?

That is, the same port as userloc lists in MySQL/openser/location/received column?

For some reason it only sends the Invite message to that port, but then all Info,Ack,Ok messages go to the port found in VIA...which the UA doesn't receive because it's behind NAT.

I've tried force_rport(); without any success, but I must admit that I'm not sure I used it in the right route.

My config is previously posted here

Any ideas?

force_rport() forces any response to the message being processed to go to the ip:port that the message was received from. Its a lightweight function, and you could call it on all messages without significant drop in performance, so try adding it at the top of your main route block.

Thanks for your reply x-console.

I inserted force_rport() in top of my main route and all other routes in my config.
As a result, now OpenSER sends INVITE and OK messages to the correct src port.

But I still have the problem...OpenSER continues to sends ACK messages to the old, wrong port.

I experimented with this stub in my main route:

Quote:

if(is_method("ACK")) { rewriteport("55159"); }

Which temporary solves the problem, ACK packages were sent to port 55159, but port 55159 is of curse a unique port for this UA, so calls to other NATed UA's won't work.

So this raises another question:

For a called URI, is there any way to get the address in the "received" column from the location table into a variable which could then be passed on to rewritehostport()?


or maybe, any other ideas?

ACK's are end-to-end, not hop-by-hop, so they may not even traverse your proxy. Assuming they do, they will be processed under loose_route(), typically, and therefore the preloaded route set will be used to direct them, rather than anything else. Make sure the Route header entries are populated correctly.

Thank you for your reply.

Quote:

ACK's are end-to-end, not hop-by-hop, so they may not even traverse your proxy.

The ngrep capture shows them traversing the proxy.

Quote:

Assuming they do, they will be processed under loose_route(), typically, and therefore the preloaded route set will be used to direct them, rather than anything else

This is how the loose_route section looks like my config:

Code:

if(loose_route())         {                 force_rport();                 if(!has_totag())                 {                         xlog("L_INFO", "Initial loose-routing rejected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");                         sl_send_reply("403", "Initial Loose-Routing Rejected");                         exit;                 }                 if(nat_uac_test("19") || search("^Route:.*;nat=yes"))                 {                         force_rport();                         fix_nated_contact();                         setflag(6);                 }                 route(3);         }

Is there anything that should be different?

Quote:

Make sure the Route header entries are populated correctly

Can you explain to me what you mean by this and how this can be accomplished?

Thanks for your time.
HDE

call force_rport() at the top fo your main route block, rather than multiple times throughout your config.

Quote:

Can you explain to me what you mean by this and how this can be accomplished?

not easily i'm afraid. You need to read RFC3261 for its sections on loose and strict routing, then look at the messages you are sending. Look at the module docs for OpenSER (the RR module which defines loose_route()), and check how it matches messages. Take it from there.