basic SIP question

Aan alleen die zijn of zullen zijn, onze groet,

Just a basic question about SIP: I've done all kind of searching on the web and found all kind of documents, manuals, howto's, white-papers about SIP, but I still have a basic question:

I'm looking for a document which explains how a SIP-call is routed, both for the signalling-part and the voice-path itself.

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.


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).


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)?

1d/ Concider both clients are behind NAT? What happens then?

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:

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?

But how do I port-forwarding for voice-traffic? It does not have a reserved range of UDP-ports, has it?

I guess these questions have been asked a number of times before but there seams to be so much information about SIP on the net; that it hard "to see the trees in the wood" (as we say in dutch).

Cheerio! Kr. Bonne.

Reply to
Kristoff Bonne
Loading thread data ...

You can try with this book

"Internet communications using SIP" I have forgot the autor name

Reply to

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.

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.

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.

Combine the problems in 1b and 1c.


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.

Reply to
Stephen Sprunk Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.