I think if you didn't have remote users or are able to translate the port
depending on the source ip (if you support remote users), it is a lot less
problematic. I actually prefer trunk calls on a port other than remote users
so I can exert different controls at the firewall.
============================
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.984.8431

Email: [email protected]

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
Fax: 434.984.8427

Helpdesk Contract Customers:
http://www.myitdepartment.net/gethelp/

----- Original Message -----
From: [email protected]
<[email protected]>
To: [email protected] <[email protected]>
Sent: Mon Mar 14 17:10:39 2011
Subject: Re: [sipx-users] tried port 5060 to 5080 forwarding. works

>>> On 3/14/2011 at 04:17 PM, in message <[email protected]>,
>>> Michael
Scheidell <[email protected]> wrote:
>
> I SUSPECT.. that sipxbridge is sending a reinvite with G.722 and the
> ITSP is not  complaining (since its not being sent to the right port/ip
> combination)
>

Investigate your traces a bit more.  SipX does not generate G.722 codec
info.  Freeswitch can if you have modified it's config outside of sipx.

Its your phone that sends the codec preferences.  All sipxbridge can do is
strip out codecs from the header.

So your issue is not due to the port nat per se....but something else.  A
sipx-trace should quickly find the device sending the G.722 in the header.
Note that you don't want to look for the device sending G.722
streams...becuase if you tell sipx to relay a G.722 call it will.
SipXbridge (sipxrelay actually) simply relays the RTP back out.  You want to
find the device sending G.722 in the sip invite.

My point is, for the record of all those that search the archives and find
long threads about whether or not a port nat works without anything special
doing layer 7.....it does work and if nothing else has been verified for
basic call functions (call in, call out, transfer, AA, voicemail) by someone
who was quite convinced it did not work.

-M

_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to