|
Posted by Stephen Sprunk on June 9, 2006, 6:37 pm
If you were Registered and logged in, you could reply and use other advanced thread options > Some practicle questions:
> 1/ Concider a scenario where both clients are registered at two different
> SIP-providers and I make a call from one to the other.
>
> 1a/ Say both clients are directly connected to the internet, I guess the
> SIP signaling session will go via the registers of the SIP-providers, but
> the voice call itself will go directly between the two SIP-clients.
>
> Right?
If the caller has an outbound proxy configured, which is normal, they will
send the INVITE to their proxy server, which will forward it to the callee's
registrar server, which will forward it to the callee.
If the caller doesn't have an outbound proxy configured, the caller will
send the INVITE directly to the callee's registrar server.
In either case, the resulting RTP streams should be directly between the
caller and the callee.
> 1b/ Concider the clients that initiates the call is behind a one-to-many
> NAT-router (Port Restricted Cone NAT), the kind of routers you find a lot
> at homes these days.
>
> So, in theory, it should be possible for the client behind the NAT-box to
> set up the voice-call to the client directly connected to the net; and the
> traffic will return as "return traffic" on that outgoing UDP-stream. (I'm
> talking about the voice-traffic itself, not the SIP signaling traffic).
>
> Correct?
That is generally correct. Note that the caller must know/discover the
public address of their NAT device so they can put valid SDP in their
INVITE.
Typically in such a scenario, the first few RTP packets coming _into_ the
NAT device will be rejected until an RTP packet has been sent _out_, thus
creating a translation. The same issue applies to non-NATing firewalls.
> 1c/ Concider the call is initiated by the other side (the one on the
> internet) and the called party is behind a NAT-box.
> Again concerning the voice-traffic, what happens?
>
> Is the called party ordered to set up the outgoing UDP-stream to the
> calling-party? (controlled via the SIP signaling information)?
Roughly the same problem as 1b. The INVITE will be addressed to the
callee's registrar server, and that server can forward it on to the callee
because a translation was created in the NAT device when the callee sent a
REGISTER to that server.
In regards to the RTP streams, the problems are identical to case 1b.
> 1d/ Concider both clients are behind NAT? What happens then?
Combine the problems in 1b and 1c.
> Question 2: Port-forwarding:
>
> Concider I have a SIP-box at home and I want to make it "directly
> reachable" from the internet (so it can be reached via
> SIP:user@host.dyndns.org)
>
>
> If it directly connected on the net, that is not a problem. (I actually
> have this set up at home), but say I would want to connect it behind a
> NAT-router and use port-forwarding.
>
> I only have a single SIP-box and it has a fix IP-address on my local LAN.
> I could set up port-forwarding to forward port 5060 UDP to that box;
> giving the impression that this directly connected on the net?
> Correct?
Correct.
> But how do I port-forwarding for voice-traffic? It does not have a
> reserved range of UDP-ports, has it?
Typically one sets aside a range of ports for RTP traffic (pick a dozen at
random, starting on an even port) and forwards them to your inside box.
Make sure you configure the correct ports and address on your SIP
application.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com
| 
NewsGroups 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map