SIP wrote:
Your biggest issue, bar none, is using the loopback address for anything externally-facing. 127.0.0.1 is called a loopback address for a reason -- it never leaves the host itself. Just how do you expect the SIP phones to be able to contact a 127.0.0.1 address when that address is, in essence, themselves?
There's something inherently flawed in your design.
Let's back up and explain, in detail, what it is exactly you're trying to do, and why you feel the 127.0.0.1 address should be part of this equation? Perhaps we can suggest something if we know what you're trying to do.
There's a very simple reason. Asterisk and SER are on the same machine. So the traffic from SER to asterisk doesn't need to leave the box. This is why I'm using the loopback interface - there's no need to use the real world one.
Your problems seems to be concerned to the RTP part of the comunication... as SIP pointed, where should the clients send the RTP traffic? To 127.0.0.1 (Your Asterisk IP)? I don't think so... ;)
So, from what I see and understand from Your explanation, You have two choices: 1- bind Asterisk to an external IP like SER (can be the same IP), but in another port; 2- try to include in Your design a RTP-Proxy application (rtproxy or mediaproxy are good choices).
Edson.
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers- bounces@lists.iptel.org] On Behalf Of John Breen Sent: quinta-feira, 24 de maio de 2007 00:15 To: SIP Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Ser + Asterisk on the same box??
SIP wrote:
Your biggest issue, bar none, is using the loopback address for anything externally-facing. 127.0.0.1 is called a loopback address for a reason -- it never leaves the host itself. Just how do you expect the SIP phones to be able to contact a 127.0.0.1 address when that address is, in essence, themselves?
There's something inherently flawed in your design.
Let's back up and explain, in detail, what it is exactly you're trying to do, and why you feel the 127.0.0.1 address should be part of this equation? Perhaps we can suggest something if we know what you're trying to do.
There's a very simple reason. Asterisk and SER are on the same machine. So the traffic from SER to asterisk doesn't need to leave the box. This is why I'm using the loopback interface - there's no need to use the real world one.
-- Regards, John Breen
HGA IT&T Solutions Tel: 08 63113000 Fax: 08 63113144 http://www.hgait.net.au Level 9, 256 Adelaide Terrace, Perth, WA 6000 Postal PO Box 3133 Perth, Adelaide Tce WA 6832
The information in this E-mail is confidential. If you are not the named & intended recipient, you must not read, use, copy, disclose or disseminate this E-mail, any attachments or the information contained in this E-mail and must immediately notify the sender & delete this E-mail immediately. Although HGA IT&T Solutions believes that this E-mail and any attachments are free of any virus or other defect which may affect a computer, it is the responsibility of the recipient to ensure that it is virus free. HGA IT&T Solutions does not accept any responsibility for any loss or damage arising in any way from the use of this E-mail or any attachments.
IMPORTANT INFORMATION
This is not a SPAM. The SPAM Act 2003 commenced on the 10th April 2004 and requires consent to the sending of most commercial electronic messages. If you wish to continue receiving electronic communications from HGA IT&T Solutions, you do not need to take any action.
If you DO NOT wish to continue receiving electronic communications from HGA IT&T Solutions please advise us at admin@hgait.net.au and we will update our records accordingly.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Edson wrote:
Your problems seems to be concerned to the RTP part of the comunication... as SIP pointed, where should the clients send the RTP traffic? To 127.0.0.1 (Your Asterisk IP)? I don't think so... ;)
So, from what I see and understand from Your explanation, You have two choices: 1- bind Asterisk to an external IP like SER (can be the same IP), but in another port; 2- try to include in Your design a RTP-Proxy application (rtproxy or mediaproxy are good choices).
Edson.
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers- bounces@lists.iptel.org] On Behalf Of John Breen Sent: quinta-feira, 24 de maio de 2007 00:15 To: SIP Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Ser + Asterisk on the same box??
SIP wrote:
Your biggest issue, bar none, is using the loopback address for anything externally-facing. 127.0.0.1 is called a loopback address for a reason -- it never leaves the host itself. Just how do you expect the SIP phones to be able to contact a 127.0.0.1 address when that address is, in essence, themselves?
There's something inherently flawed in your design.
Let's back up and explain, in detail, what it is exactly you're trying to do, and why you feel the 127.0.0.1 address should be part of this equation? Perhaps we can suggest something if we know what you're trying to do.
There's a very simple reason. Asterisk and SER are on the same machine. So the traffic from SER to asterisk doesn't need to leave the box. This is why I'm using the loopback interface - there's no need to use the real world one.
Ok, we are already using MediaProxy which is listening on the external interface because we do have real-world clients.
I will try moving asterisk to listen on the external interface, though I don't understand how that's going to change things?
John Breen wrote:
SIP wrote:
Your biggest issue, bar none, is using the loopback address for anything externally-facing. 127.0.0.1 is called a loopback address for a reason -- it never leaves the host itself. Just how do you expect the SIP phones to be able to contact a 127.0.0.1 address when that address is, in essence, themselves?
There's something inherently flawed in your design.
Let's back up and explain, in detail, what it is exactly you're trying to do, and why you feel the 127.0.0.1 address should be part of this equation? Perhaps we can suggest something if we know what you're trying to do.
There's a very simple reason. Asterisk and SER are on the same machine. So the traffic from SER to asterisk doesn't need to leave the box. This is why I'm using the loopback interface - there's no need to use the real world one.
127.0.0.1 is a special address. If MY machine, for instance, tries to connect to 127.0.0.1, it's connecting to itself. If Bob's machine tries to connect to 127.0.0.1, he's connecting to Bob's machine. While, technically, you COULD accomplish having Asterisk on an internal IP address on the local machine, in order for it to actually work, you'd need to turn the computer into a router (start doing RIP or some such), which would immeasurably complicate things.
Remember, a SIP call has two parts. One is the signaling portion (the actual SIP portion of the call) and one is the media portion (RTP -- the voice stuff). SER handles the SIP portion but doesn't do anything with the RTP portion. It can't, itself, 'proxy' that voice portion from the outside world to an internal-only IP on your box, so you won't ever get any audio to your Asterisk server that way. What happens in that scenario is that your softphone calls the SER box. SER tells the softphone that it needs to connect its RTP/audio portion of the call to the IP of the asterisk server directly. If the IP of the asterisk server is internal (or the loopback IP), then the softphone has no way to know how to get to it, so it can't connect the audio properly.
If you were running mediaproxy or RTPproxy on the SAME box, IT could proxy the audio portion from the outside world to the Asterisk server running on the same machine with an internal IP. However, then you're creating an incredibly complex scenario and using even more resources for each call.
Your best bet if you need both servers to run on the same box is simply to run Asterisk on the same external IP as SER but with a different port. That way, the outside world can connect its audio to the Asterisk server and you won't get some of the weird issues you're getting now.
N.
-
Edson -
John Breen -
John Breen -
SIP