[OpenSIPS-Users] Opensips 1.9.1 and NAT

[Ali Pey]

As I said earlier, there is no such a thing as FROM or TO (i.e. direction)
unless it's implemented in your logic. When a SIP request reaches the IP
address of your opensips server, it goes through your routing script in
opensips.cfg and then it's routed out. What you have there, it would apply
to the request message. Put yourself in opensips shoes and follow the logic
- that's how we debugged code while at uni :)

If you have a concept of direction and you need different behavior based on
your concept of direction, you need to implement it in your logic. For
instance you can examine the source IP or subnet to decide if this message
is from internal or external and then apply different logic to it - or
whatever else that is specific to your environment.

What is it that you are trying to do?

Regards,
Ali Pey


On Mon, Nov 25, 2013 at 10:52 PM, dpa <denis7979 at mail.ru> wrote:

> OK, but in the current case another question.
>
> Is nat_bflag appear in transaction when call goes TO uac behind nat (by
> using lookup(), for example), or it appears  in transaction when call goes
> FROM uac behind nat?
>
>
>
> Thank you.
>
>
>
> *From:* users-bounces at lists.opensips.org [mailto:
> users-bounces at lists.opensips.org] *On Behalf Of *Ali Pey
> *Sent:* Monday, November 25, 2013 8:38 PM
>
> *To:* OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] Opensips 1.9.1 and NAT
>
>
>
> You also examining isbflagset(10). Isn't that set?
>
>
>
> Regards,
>
> Ali Pey
>
>
>
> On Mon, Nov 25, 2013 at 3:09 AM, dpa <denis7979 at mail.ru> wrote:
>
> Hello
>
>
>
> I understand but in onreply route I make a test: nat_uac_test("55") and
> only if it successful I make “fix_nated_contact()”.
>
> In my case nat_uac_test("55") must be fail after checking 183 ringing and
> 200 OK.
>
>
>
> *From:* users-bounces at lists.opensips.org [mailto:
> users-bounces at lists.opensips.org] *On Behalf Of *Ali Pey
> *Sent:* Friday, November 22, 2013 5:37 PM
> *To:* OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] Opensips 1.9.1 and NAT
>
>
>
> Hello,
>
>
>
> The question is not quite clear. In your opensips.cfg you call "fix_nated_contact()"
> on both route and reply route. that's why it changes the route.
>
>
>
> There is no such a thing as direction in opensips unless it's implemented
> in your logic. A message goes through your route or reply route scripts
> when it reaches opensips.
>
>
>
> Regards,
>
> Ali
>
>
>
> On Fri, Nov 22, 2013 at 1:10 AM, dpa <denis7979 at mail.ru> wrote:
>
> Hello
>
>
>
> I have a one question about nat processing of Opensips.
>
>
>
> There is such scheme
>
>
>
> UAC1 (softphone behind nat) à Opensips -> UAC2 (another softswitch), i.e.
> UAC1 initiates a call to Opensips and a signaling port = 5068.
>
>
>
> So UAC2 becomes “ringing” by sending 183 message.
>
>
>
> In attachment 183 message from UAC2 and some parts of opensips.cfg
>
>
>
> After 183 processing by Opensips port in Contact header of 183 (and later
> 200 OK) messages become 5060, i.e. Opensips detects NAT and changes Contact
> header.
>
>
>
> So my question is, Why does Opensips changes Contact header?
>
> Once Opensips detects nat transaction (setting setflag(21)) is it check
> all reply messages (and doesn`t matter from which UAC they have been
> received) or Opensips can detect direction and makes decision about nat
> process?
>
>
>
> Thank you  for any help.
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131125/836f6cea/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 906 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20131125/836f6cea/attachment.gif>