Yes, I saw that. I have NO IDEA why the port is different. As mentioned, all devices are on the same subnet (i.e. no NAT involved). I don't even have 5060 or 30000-31000 forwarded by my FW, though I DO have Sipx itself configured for NAT (in preparation for the next step which is remote workers).
Which device "chooses" the each of those two ports? I suspect one is chosen by Bria (UA) and the other by sipX (Proxy or Registrar?). If that is the case, why would sipX choose a different port? Is there a setting I can use to avoid this (e.g. disable NAT in sipX) or should I be looking at a setting in Bria to trick it into thinking it is behind NAT? Keith ____________________________________________________________ _ If you check the REGISTER from Bria, it has port 49487 in the Via and 49486 in the Contact-URI. For NAT to be traversed, UA should make sure that the transport they used to send the REGISTER is the same transport they would use for INVITE. Since its clearly different, this simply wouldn't work from behind NAT. REGISTER sip:laidlaw.private SIP/2.0 Via: SIP/2.0/TCP 192.168.7.131:49487;rport;branch=z9hG4bKPjzZnBwF3yd8fNPtG0QE szLP72vl12faa1;alias Max-Forwards: 70 From: "Brooke iPod" < sip:[email protected]>;tag=D.ujLLC78Fe0FLw3YQKnNf35VKEsVpMi To: "Brooke iPod" <sip:[email protected]> Call-ID: DzvrhVhBFmSZW3I.0RLiy6r8jhtwDSRf CSeq: 49097 REGISTER User-Agent: Bria iOS 2.0.0 Contact: "Brooke iPod" <sip:[email protected]:49486;transport=TCP> Expires: 600 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 On 01/12/2012 08:51 AM, Keith Laidlaw wrote: > > Attached are the registration siptrace and the call siptrace > (unedited). If attachment doesn't work, let me know how to send. > > On the Counterpath forum, they pointed out the following: > > "For connection based transports, the SIP server should reuse the TCP > connection initiated by Bria. In most deployments for mobile services, > there will be a NAT or firewall between Bria and the SIP server. NAT > and firewall will prevent the SIP server to connect to Bria's listen > TCP socket anyways. > > Most SIP servers already reuse the TCP connection initiated by Bra. > Unfortunately this best practice was not defined in the SIP 2.0 RFC > 3261 spec. > > However RFC 5626 spec does define behavior for user agents behind NAT > and firewalls in reusing TCP and TLS connections. From the introduction: > > There are many environments for SIP [RFC3261] deployments in which > the User Agent (UA) can form a connection to a registrar or proxy but > in which connections in the reverse direction to the UA are not > possible. This can happen for several reasons, but the most likely > is a NAT or a firewall in between the SIP UA and the proxy. Many > such devices will only allow outgoing connections. This > specification allows a SIP User Agent behind such a firewall or NAT > to receive inbound traffic associated with registrations or dialogs > that it initiates." > > There is no FW between the three devices (sipx, phone1 and Bria > iPhone), but maybe the "reuse of TCP connection" is the problem? > > Keith > > ____________________________________________________________ _ > > a siptrace from sipx with the proxy logging set to debug would help a bit. > > I would assume it is not able to ack the call, or using tcp doesnt > handle larger headers as well. > > Try the same thing on 3cx for iphone and see if it behaves the same way. > > On Wed, Jan 11, 2012 at 8:37 AM, Keith Laidlaw <[email protected] > <mailto:[email protected]>> wrote: > > I configured a Bria iPhone 2.0.0 (Jan 11,2012) and got it working > perfectly > > using UDP to sipX 4.4.0 on a local LAN (not remote worker). I can connect > > to/from local phones and can connect to/from PSTN. It is quite a simple > > setup (no stun or ice on the phone since it is local). I'm using SRV. > > > > > > > > The only change I make is to use TCP (very important for battery > > conservation). When I make this change on the Bria, I continue to be able > > to make calls but all received calls go to VM. Note that the phone is > > registered (according to sipX AND the phone) but calls still go to > VM. If I > > try the same thing with x-lite, it works perfectly on both TCP and UDP. > > > > > > > > I have not given a lot of info here for brevity, but I can provide > whatever > > may be helpful. My guess is that someone out there has seen this > before and > > knows what is wrong. If so, I'd be so grateful. If not, please let me > know > > what captures would be useful and what other info you would need to > help me. > > > > > > > > TIA, > > > > Keith > > > > > > _______________________________________________ > > sipx-users mailing list > > [email protected] <mailto:[email protected]> > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > <mailto:[email protected]> > Fax: 434.465.6833 > > Email: [email protected] <mailto:[email protected]> > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > <mailto:[email protected]> > > Helpdesk Customers: http://myhelp.myitdepartment.net > Blog: http://blog.myitdepartment.net > > Linked-In Profile: > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > < http://forum.sipfoundry.org/%20http:/www.linkedin.com/pub/to ny-graziano/14/4a6/7a4 <http://forum.sipfoundry.org/%20http:/www.linkedin.com/pub/tony-graziano /14/4a6/7a4> > > Ask about our Internet Fax services! > _______________________________________________ > sipx-users mailing list > [email protected] <mailto:[email protected]> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > ------------------------------------------------------------ ------------ > > ===================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > <mailto:[email protected]>[/email][/email] > Fax: 434.984.8431 > > Email: [email protected] > <mailto:[email protected]>[/email][/email] > > > > _______________________________________________ > 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/
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
