Scott Lawrence | 1 Jan 13:14 2010

Re: config problem or sipxbridge problem?

On Thu, 2009-12-31 at 17:42 -0500, Tony Graziano wrote:
> After thinking about this... If you only have one sbc and it is sipxbridge,
> this should not be not-choosable by your superadmin. I think if it breaks
> remote users it should be discussed, especially if you need to choose it
> with another SBC.

I don't believe that it does break remote users and would want very
careful documentation of how it does before we open an issue on it.

Help text can always be improved - feel free to suggest text.

Scott Lawrence | 1 Jan 13:26 2010

Re: tips needed for debugging silent calls from site to site


On Dec 30, 2009, at 12:49 PM, Tony Graziano wrote:

> > You need to state whether these networks are listed on the
> > System>Internet Calling under "Intranet Subnets" or not. 

On Wed, 2009-12-30 at 12:55 -0800, steven warner wrote: 
> Yes, Both are as in *.domain.com.

Looking at your traces, it appears that these systems are _not_ doing
NAT compensation for each other - which won't work. 

Each system needs to list the subnet that it is on as a local network on
the Internet Calling screen, and _not_ list the network that the other
is on. 

Recheck all the steps in 

http://sipx-wiki.calivia.com/index.php/Configuring_remote_workers_cheatsheet

Picher, Michael | 1 Jan 13:29 2010

Re: config problem or sipxbridge problem?

The 'Enable Internet Calling' setting does break remote users if
sipXbridge is used as the SBC.

If you enable the 'Enable Internet Calling' setting remote users show as
not being behind NAT.  If you disable that setting the NAT works
properly and the remote users are correctly identified as being behind a
NAT'd device.

If enabled the remote user can register and make calls but can not
receive calls (call goes directly to voicemail).  The line I pointed out
earlier in the sipXbridge logs also complains about an invalid ITSP.
Disabling 'Enable Internet Calling' resolves this issue.

Mike

-----Original Message-----
From: Scott Lawrence [mailto:scottlawrenc <at> avaya.com] 
Sent: Friday, January 01, 2010 7:14 AM
To: Tony Graziano
Cc: Picher, Michael; Scott Lawrence; sipx-users <at> list.sipfoundry.org
Subject: Re: [sipx-users] config problem or sipxbridge problem?

On Thu, 2009-12-31 at 17:42 -0500, Tony Graziano wrote:
> After thinking about this... If you only have one sbc and it is
sipxbridge,
> this should not be not-choosable by your superadmin. I think if it
breaks
> remote users it should be discussed, especially if you need to choose
it
> with another SBC.
(Continue reading)

Picher, Michael | 1 Jan 13:30 2010

Re: tips needed for debugging silent calls from site to site

I also just adjusted step 3 in that Wiki page with my findings.

Mike

-----Original Message-----
From: sipx-users-bounces <at> list.sipfoundry.org
[mailto:sipx-users-bounces <at> list.sipfoundry.org] On Behalf Of Scott
Lawrence
Sent: Friday, January 01, 2010 7:26 AM
To: steven warner
Cc: sipx-users <at> list.sipfoundry.org
Subject: Re: [sipx-users] tips needed for debugging silent calls from
site to site

On Dec 30, 2009, at 12:49 PM, Tony Graziano wrote:

> > You need to state whether these networks are listed on the
> > System>Internet Calling under "Intranet Subnets" or not. 

On Wed, 2009-12-30 at 12:55 -0800, steven warner wrote: 
> Yes, Both are as in *.domain.com.

Looking at your traces, it appears that these systems are _not_ doing
NAT compensation for each other - which won't work. 

Each system needs to list the subnet that it is on as a local network on
the Internet Calling screen, and _not_ list the network that the other
is on. 

Recheck all the steps in 
(Continue reading)

Dale Worley | 1 Jan 18:43 2010

Re: tips needed for debugging silent calls from site to site

On Thu, 2009-12-31 at 09:45 -0800, steven warner wrote:

> Wireshark of lost RTP packets:
> http://files.me.com/swixo/rev6rx

You might want to re-do that one:  It's a JPEG image of Wireshark's
display of some packets, not the PCAP file that contains the packets.

Dale

Tony Graziano | 1 Jan 19:10 2010
Picon

Re: tips needed for debugging silent calls from site to site

It would help to know:


Are these two different sip domains?
If so, can they resolve each other properly?

How are they connected? Via NAT over the Internet or by VPN?

If you are using sipxbridge as your SBC and natively passing over the Internet, make sure "Internet Calling" is disabled.

Can you post the pcap file instead of the image? The image simply shows RTP retries. The question is "why"

On Wed, Dec 30, 2009 at 3:55 PM, steven warner <stevenwarner <at> gmail.com> wrote:

Yes, Both are as in *.domain.com.

s

On Dec 30, 2009, at 12:49 PM, Tony Graziano wrote:

You need to state whether these networks are listed on the System>Internet Calling under "Intranet Subnets" or not.

On Wed, Dec 30, 2009 at 3:36 PM, steven warner <stevenwarner <at> gmail.com> wrote:

(Sorry folks - my posts were too big before!)

For the experts.  I have wiresharked my site<>site calling problem,
and need to know if my supposition has any merit.

Below is a link to snipplet of the RDP conversation from my end only.

By comparing this to a successful call, it seems to me that the problem
here is that the Destination address is not routable.  Since both
systems are behind NATs, shouldn't the Dest (packets from me) be
the public IP address of the other system?  BTW, 10.1.10.213 is the
NATted IP address of the destination Polycom Phone.  192.168.1.66
is the NATted IP address of MY phone.

My question: Is this Wireshark showing me that the Dest IP address the Phone
is generating is wrong?
How would this happen?

The merged.xml:

Wireshark of lost RTP packets:

(Stun is off in the phones, and server for this test).
(Polycom firmware downgraded 3.1.3C on both sides)

Thanks for any help.

s

Begin forwarded message:

From: "Scott Lawrence" <scottlawrenc <at> avaya.com>
Date: December 30, 2009 11:28:49 AM PST
To: steven warner <stevenwarner <at> gmail.com>
Subject: Re: [sipx-users] tips needed for debugging silent calls from site to site

On Wed, 2009-12-30 at 10:08 -0800, steven warner wrote:
Scott - my list posts aren't going out anymore.

No - they are blocked because they're too big.  There is a 60K limit on
posts to the list.

 So - I have
attached a trace.  This is a failed call to the remote.  The call
"completes" and is answered - but no audio flows.

Do you see anything here?

I also attached the wireshark of the RTP.  My comment here is that the
destination address is not reachable, it is behind a nat.  The rtp capture
and the trace are not the same call -- but the same scenario happened.

    1. Downgrade your Polycom phones to 3.1.3 (this has been posted to
       the lists many times)
    2. Turn _off_ STUN support on the phones
    3. It's better if you can configure the addresses so that the
       servers don't use STUN either.
    4. Take new traces from _both_ systems for the same call.  Filter
       and compress them so that they fit in the 60K limit, or make
       them available some way other than the list and post a pointer
       to them.




_______________________________________________
sipx-users mailing list sipx-users <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/



--
======================
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.984.8431

Email: tgraziano <at> myitdepartment.net

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

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

Why do mathematicians always confuse Halloween and Christmas?
Because 31 Oct = 25 Dec.





--
======================
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.984.8431

Email: tgraziano <at> myitdepartment.net

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

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

Why do mathematicians always confuse Halloween and Christmas?
Because 31 Oct = 25 Dec.

<div>
<p>It would help to know:</p>
<div><br></div>
<div>Are these two different sip domains?</div>
<div>If so, can they resolve each other properly?</div>
<div><br></div>
<div>How are they connected? Via NAT over the Internet or by VPN?</div>
<div><br></div>
<div>If you are using sipxbridge as your SBC and natively passing over the Internet, make sure "Internet Calling" is disabled.</div>
<div><br></div>
<div>Can you post the pcap file instead of the image? The image simply shows RTP retries. The question is "why"<br><br><div class="gmail_quote">On Wed, Dec 30, 2009 at 3:55 PM, steven warner <span dir="ltr">&lt;<a href="mailto:stevenwarner <at> gmail.com">stevenwarner <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>
<div><br></div>
<div>Yes, Both are as in *.<a href="http://domain.com" target="_blank">domain.com</a>.</div>
<div><br></div>
<div>s</div>
<div>
<div></div>
<div class="h5">
<br><div>
<div>On Dec 30, 2009, at 12:49 PM, Tony Graziano wrote:</div>
<br><blockquote type="cite">You need to state whether these networks are listed on the System&gt;Internet Calling under "Intranet Subnets" or not.<div>
<br>
</div>
<div>
<div class="gmail_quote">On Wed, Dec 30, 2009 at 3:36 PM, steven warner <span dir="ltr">&lt;<a href="mailto:stevenwarner <at> gmail.com" target="_blank">stevenwarner <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>
<div><br></div>(Sorry folks - my posts were too big before!)<div><br></div>
<div>
<div>

For the experts. &nbsp;I have wiresharked my site&lt;&gt;site calling problem,<br>and need to know if my supposition has any merit.<br><br>Below is a link to snipplet of the RDP conversation from my end only.<br>
</div>
<div><br></div>
<div>By comparing this to a successful call, it seems to me that the problem<br>here is that the Destination address is not routable. &nbsp;Since both<br>systems are behind NATs, shouldn't the Dest (packets from me) be<br>

the public IP address of the other system? &nbsp;BTW, 10.1.10.213 is the<br>NATted IP address of the destination Polycom Phone. &nbsp;192.168.1.66<br>is the NATted IP address of MY phone.<br><br>My question: Is this Wireshark showing me that the Dest IP address the Phone<br><span>is generating is wrong?<br>How would this happen?<br><br></span>
</div>
<div><span>The merged.xml:</span></div>
<div><span><a href="http://files.me.com/swixo/hbcvt9" target="_blank"><span>http://files.me.com/swixo/hbcvt9</span></a></span></div>

<div><span><span><br></span></span></div>
<div><span>Wireshark of lost RTP packets:</span></div>

<div><span><a href="http://files.me.com/swixo/rev6rx" target="_blank"><span>http://files.me.com/swixo/rev6rx</span></a></span></div>

</div>
<div><br></div>
<div>(Stun is off in the phones, and server for this test).</div>
<div>(Polycom firmware downgraded 3.1.3C on both sides)</div>
<div><br></div>
<div>Thanks for any help.</div>
<div><br></div>
<div>s<br><div>

<br><div>Begin forwarded message:</div>
<br><blockquote type="cite">
<div>
<span>From: </span><span>"Scott Lawrence" &lt;<a href="mailto:scottlawrenc <at> avaya.com" target="_blank">scottlawrenc <at> avaya.com</a>&gt;<br></span>
</div>
<div>
<span>Date: </span><span>December 30, 2009 11:28:49 AM PST<br></span>
</div>
<div>
<span>To: </span><span>steven warner &lt;<a href="mailto:stevenwarner <at> gmail.com" target="_blank">stevenwarner <at> gmail.com</a>&gt;<br></span>
</div>
<div>
<span>Subject: </span><span>Re: [sipx-users] tips needed for debugging silent calls from site to site<br></span>
</div>
<br><div>On Wed, 2009-12-30 at 10:08 -0800, steven warner wrote:<br><blockquote type="cite">Scott - my list posts aren't going out anymore.<br>
</blockquote>
<br>No - they are blocked because they're too big. &nbsp;There is a 60K limit on<br>

posts to the list.<br><br><blockquote type="cite"> &nbsp;So - I have<br>
</blockquote>
<blockquote type="cite">attached a trace. &nbsp;This is a failed call to the remote. &nbsp;The call<br>
</blockquote>
<blockquote type="cite">"completes" and is answered - but no audio flows.<br>
</blockquote>
<blockquote type="cite"><br></blockquote>
<blockquote type="cite">Do you see anything here?<br>
</blockquote>
<blockquote type="cite"><br></blockquote>
<blockquote type="cite">I also attached the wireshark of the RTP. &nbsp;My comment here is that the<br>
</blockquote>
<blockquote type="cite">destination address is not reachable, it is behind a nat. &nbsp;The rtp capture<br>
</blockquote>
<blockquote type="cite">and the trace are not the same call -- but the same scenario happened.<br>
</blockquote>
<br> &nbsp;&nbsp;&nbsp;&nbsp;1. Downgrade your Polycom phones to 3.1.3 (this has been posted to<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the lists many times)<br> &nbsp;&nbsp;&nbsp;&nbsp;2. Turn _off_ STUN support on the phones<br> &nbsp;&nbsp;&nbsp;&nbsp;3. It's better if you can configure the addresses so that the<br>

 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;servers don't use STUN either.<br> &nbsp;&nbsp;&nbsp;&nbsp;4. Take new traces from _both_ systems for the same call. &nbsp;Filter<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and compress them so that they fit in the 60K limit, or make<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;them available some way other than the list and post a pointer<br>

 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to them.<br><br><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>_______________________________________________<br>
sipx-users mailing list <a href="mailto:sipx-users <at> list.sipfoundry.org" target="_blank">sipx-users <at> list.sipfoundry.org</a><br>
List Archive: <a href="http://list.sipfoundry.org/archive/sipx-users" target="_blank">http://list.sipfoundry.org/archive/sipx-users</a><br>
Unsubscribe: <a href="http://list.sipfoundry.org/mailman/listinfo/sipx-users" target="_blank">http://list.sipfoundry.org/mailman/listinfo/sipx-users</a><br>
sipXecs IP PBX -- <a href="http://www.sipfoundry.org/" target="_blank">http://www.sipfoundry.org/</a><br>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>======================<br>Tony Graziano, Manager<br>Telephone: 434.984.8430<br>

Fax: 434.984.8431<br><br>Email: <a href="mailto:tgraziano <at> myitdepartment.net" target="_blank">tgraziano <at> myitdepartment.net</a><br><br>LAN/Telephony/Security and Control Systems Helpdesk:<br>Telephone: 434.984.8426<br>Fax: 434.984.8427<br><br>Helpdesk Contract Customers:<br><a href="http://www.myitdepartment.net/gethelp/" target="_blank">http://www.myitdepartment.net/gethelp/</a><br><br>Why do mathematicians always confuse Halloween and Christmas?<br>Because 31 Oct = 25 Dec.<br><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>======================<br>Tony Graziano, Manager<br>Telephone: 434.984.8430<br>Fax: 434.984.8431<br><br>Email: <a href="mailto:tgraziano <at> myitdepartment.net">tgraziano <at> myitdepartment.net</a><br><br>LAN/Telephony/Security and Control Systems Helpdesk:<br>Telephone: 434.984.8426<br>Fax: 434.984.8427<br><br>Helpdesk Contract Customers:<br><a href="http://www.myitdepartment.net/gethelp/">http://www.myitdepartment.net/gethelp/</a><br><br>Why do mathematicians always confuse Halloween and Christmas?<br>Because 31 Oct = 25 Dec.<br><br>
</div>
</div>
Scott Lawrence | 1 Jan 20:11 2010

Re: config problem or sipxbridge problem?

On Fri, 2010-01-01 at 07:29 -0500, Picher, Michael wrote:

> The 'Enable Internet Calling' setting does break remote users if
> sipXbridge is used as the SBC.
> 
> If you enable the 'Enable Internet Calling' setting remote users show as
> not being behind NAT.  If you disable that setting the NAT works
> properly and the remote users are correctly identified as being behind a
> NAT'd device.

I've thought more about this, and worked out for myself what I think the
problem is (replies directed to sipx-dev to carry on the discussion
about what to do about it):

The Internet Calling checkbox causes a configuration change in
forwardingrules.xml, which configures some early routing decisions in
the proxy.  Specifically, enabling Internet Calling adds routes that
match local addresses and domains and add routes to keep them in the
proxy, and any other address or domain is routed directly to the SBC,
like these:

  <route mappingType='local ip address'>
    <description>Any host address in the local subnets is routed to the auth proxy.</description>
    <routeIPv4subnet>192.168.10.0/16</routeIPv4subnet>
    <routeDnsWildcard>*.home.skrb.org</routeDnsWildcard>
    <routeTo authRequired="true"/>
  </route>

  <route mappingType="external destinations">
    <description>Any foreign domain - route via session border.</description>
    <routeDnsWildcard>*</routeDnsWildcard>
    <routeIPv4subnet>0/0</routeIPv4subnet>
    <routeTo authRequired="true">192.168.10.10:5090</routeTo>
  </route>

The point of those rules is that they allow one to make a call to an
arbitrary SIP URL and route it through the SBC (in the examples above,
that SBC is sipXbridge).  

I think that what's going wrong is that these rules are matching because
NATted addresses are not local, causing them to be routed to the bridge.
That won't work, because the NAT mappings are to the proxy port, not the
bridge port, so those packets don't get through.  Register works because
it only uses a externally initiated request/response and the response
follows the Vias, not any routing rule.  But making a call requires that
requests work in both directions, and any outbound request (including
the ACK for an inbound call) is misrouted.

The reason that the behavior is different with an SBC other than
sipXbridge is that if you're using some other SBC you usually use it
both for remote phones, arbitrary SIP url calling, and ITSP connections.
Since sipXbridge is not used for remote phones, those routing rules
cause a problem.

Now that we have NAT traversal in the sipXproxy, I think that those
rules are no longer needed if NAT traversal is active.  They would still
be needed if an external SBC was being used, but I suspect that there
are no sites that have remote phones using sipXproxy for NAT traversal
and also using some external SBC.

Jordan Turner | 1 Jan 20:50 2010
Picon

Re: config problem or sipxbridge problem?

Can someone refresh us on this issue?  This is the problem I encountered during my initial experience with
sipXecs 4.0.2-4.0.4.  It was 2 weeks of continuous testing and I found what you guys are finding but I just
thought this was "normal" behavior.  Just by ticking the enable Internet Calling, it all stopped working. 
If left unticked, remote workers and internal workers all worked - even SIP dialing works.  I got confused
as to why "Internet Calling" was even required.  I have sipXbridge as the default and NOT default gateway -
multiple permutations but same result with Internet Calling.

So can someone clarify if this is an issue with Internet Calling or other - bug or actual desired result?  I
have my mind set on the working config as discovered - or do I have to re-learn the actual correct proper setting?

>>The 'Enable Internet Calling' setting does break remote users if
>>sipXbridge is used as the SBC.

>>If you enable the 'Enable Internet Calling' setting remote users show as
>>not being behind NAT.  If you disable that setting the NAT works
>>properly and the remote users are correctly identified as being behind a
>>NAT'd device.

>>If enabled the remote user can register and make calls but can not
>>receive calls (call goes directly to voicemail).  The line I pointed out
>>earlier in the sipXbridge logs also complains about an invalid ITSP.
>>Disabling 'Enable Internet Calling' resolves this issue.

>>Mike

      
steven warner | 1 Jan 21:11 2010
Picon

site<>site calling success


Well - I read the guide:

I don't know *how* many times and got to this part:

"* Make sure that 'Enable Internet Calling' check box is DISABLED."

And kept saying - of course it is ON.  Not seeing it wanted it OFF.
Seemed not sensical to have this OFF - so for some reason I didn't notice the state.

So with "Internet calling" disabled, my site to site problems
are gone and it is fully operational.  Thanks everyone for your
help.

Steve
<div>
<div><br></div>
<div>Well - I read the guide:</div>
<div>
<br><a href="http://sipx-wiki.calivia.com/index.php/Configuring_remote_workers_cheatsheet">http://sipx-wiki.calivia.com/index.php/Configuring_remote_workers_cheatsheet</a><br>
</div>
<div><br></div>
<div>I don't know *how* many times and got&nbsp;to this part:</div>
<div><br></div>
<div>
<span class="Apple-style-span"><span class="Apple-tab-span">	</span>"* Make sure that 'Enable Internet Calling' check box is DISABLED."</span><div><br></div>
<div>And kept saying - of course it is ON. &nbsp;Not seeing it wanted it OFF.</div>
<div>Seemed not sensical to have this OFF - so for some reason I didn't notice the state.</div>
<div><br></div>
<div>So with "Internet calling" disabled, my site to site problems</div>
<div>are gone and it is fully operational. &nbsp;Thanks everyone for your</div>
<div>help.</div>
<div><br></div>
<div>Steve</div>
</div>
</div>
Picher, Michael | 1 Jan 22:11 2010

Re: config problem or sipxbridge problem?

Fwiw, if an internal phone attempted to url dial to a phone not
registered on the system it didn't work either.  Don't know if that
helps any in diagnostics or not.

-----Original Message-----
From: Scott Lawrence [mailto:scottlawrenc <at> avaya.com] 
Sent: Friday, January 01, 2010 2:12 PM
To: Picher, Michael
Cc: Scott Lawrence; Tony Graziano; sipx-users <at> list.sipfoundry.org;
sipXecs developers
Subject: RE: config problem or sipxbridge problem?

On Fri, 2010-01-01 at 07:29 -0500, Picher, Michael wrote:

> The 'Enable Internet Calling' setting does break remote users if
> sipXbridge is used as the SBC.
> 
> If you enable the 'Enable Internet Calling' setting remote users show
as
> not being behind NAT.  If you disable that setting the NAT works
> properly and the remote users are correctly identified as being behind
a
> NAT'd device.

I've thought more about this, and worked out for myself what I think the
problem is (replies directed to sipx-dev to carry on the discussion
about what to do about it):

The Internet Calling checkbox causes a configuration change in
forwardingrules.xml, which configures some early routing decisions in
the proxy.  Specifically, enabling Internet Calling adds routes that
match local addresses and domains and add routes to keep them in the
proxy, and any other address or domain is routed directly to the SBC,
like these:

  <route mappingType='local ip address'>
    <description>Any host address in the local subnets is routed to the
auth proxy.</description>
    <routeIPv4subnet>192.168.10.0/16</routeIPv4subnet>
    <routeDnsWildcard>*.home.skrb.org</routeDnsWildcard>
    <routeTo authRequired="true"/>
  </route>

  <route mappingType="external destinations">
    <description>Any foreign domain - route via session
border.</description>
    <routeDnsWildcard>*</routeDnsWildcard>
    <routeIPv4subnet>0/0</routeIPv4subnet>
    <routeTo authRequired="true">192.168.10.10:5090</routeTo>
  </route>

The point of those rules is that they allow one to make a call to an
arbitrary SIP URL and route it through the SBC (in the examples above,
that SBC is sipXbridge).  

I think that what's going wrong is that these rules are matching because
NATted addresses are not local, causing them to be routed to the bridge.
That won't work, because the NAT mappings are to the proxy port, not the
bridge port, so those packets don't get through.  Register works because
it only uses a externally initiated request/response and the response
follows the Vias, not any routing rule.  But making a call requires that
requests work in both directions, and any outbound request (including
the ACK for an inbound call) is misrouted.

The reason that the behavior is different with an SBC other than
sipXbridge is that if you're using some other SBC you usually use it
both for remote phones, arbitrary SIP url calling, and ITSP connections.
Since sipXbridge is not used for remote phones, those routing rules
cause a problem.

Now that we have NAT traversal in the sipXproxy, I think that those
rules are no longer needed if NAT traversal is active.  They would still
be needed if an external SBC was being used, but I suspect that there
are no sites that have remote phones using sipXproxy for NAT traversal
and also using some external SBC.


Gmane