Hi,
As I'm a newbie on this subject, I'm wondering how two SIP devices with ICE compatibility will interact with a (open)SER+Mediaproxy implementation since ICE implementation could permit to avoid RTP flow on the (open)SER server.
Is there any update to do on the conf file on the (open)SER ? Since they are ICE compatible, the SIP flow (signalization) will be analysed by this two devices in order to create a direct RTP flow ? Or is it because i know on the (open)SER side that this devices are ICE compatible I send a special SIP message ? In fact I want to know if a server update is necessary or if it's "free" to have this great feature. :)
Thanks, Christophe
Hi Chris,
if you have phones with ICE capability, you do not need anything extra in your cfg (no rtpproxy, no mediaproxy). Form openser point of view, the clients will be seen as clients with public IPs.
So, nothing to be done.....it just works
regards, bogdan
Christophe Irles wrote:
Hi,
As I'm a newbie on this subject, I'm wondering how two SIP devices with ICE compatibility will interact with a (open)SER+Mediaproxy implementation since ICE implementation could permit to avoid RTP flow on the (open)SER server.
Is there any update to do on the conf file on the (open)SER ? Since they are ICE compatible, the SIP flow (signalization) will be analysed by this two devices in order to create a direct RTP flow ? Or is it because i know on the (open)SER side that this devices are ICE compatible I send a special SIP message ? In fact I want to know if a server update is necessary or if it's "free" to have this great feature. :)
Thanks, Christophe
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi,
short version: you do not need to change or update anything on the server side to get ICE support working.
In more details: First of all ICE is still a draft, and no end in sight yet. Secondly, good luck in finding two interoperable UA with ICE support! :-) UA's with ICE support will advertise all their possible IP addresses in the SDP. As long as the proxies do not change theses additional addresses, but only the address in the m-line everything works fine and transparent. And I think (and hope) that the current nathelper modules only touch the m-line and no other IP addresses in the SDP. When the other UA sees the additional addresses in SDP, it will probe these addresses. The address which answers first will be used for media. And normally a local address should always be faster then any address which goes through the Internet or even relayed (like with an RTP proxy). What you are probably thinking of is, that an UA with ICE support could also advertise its IP address and port of the RTP proxy, but this is then called TURN. And I think that is even more far away from becoming a standard, besides that their are AFAIK no UA's or TURN servers available yet.
Hope this helps Nils
On Wednesday 30 November 2005 16:36, Christophe Irles wrote:
Hi,
As I'm a newbie on this subject, I'm wondering how two SIP devices with ICE compatibility will interact with a (open)SER+Mediaproxy implementation since ICE implementation could permit to avoid RTP flow on the (open)SER server.
Is there any update to do on the conf file on the (open)SER ? Since they are ICE compatible, the SIP flow (signalization) will be analysed by this two devices in order to create a direct RTP flow ? Or is it because i know on the (open)SER side that this devices are ICE compatible I send a special SIP message ? In fact I want to know if a server update is necessary or if it's "free" to have this great feature. :)
Thanks, Christophe
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 11/30/05, Nils Ohlmeier lists@ohlmeier.org wrote:
What you are probably thinking of is, that an UA with ICE support could also advertise its IP address and port of the RTP proxy, but this is then called TURN. And I think that is even more far away from becoming a standard, besides that their are AFAIK no UA's or TURN servers available yet.
Hope this helps Nils
I think that the MiniSIP project is developing one client and server... www.minisip.org, in the "branches" of the SVN repository. No idea how far is it from being usable at all.
Cesc
Couterpath (www.counterpath.com) (formerly known as Xten) has this Xtunnel ( www.xtunnels.org) which sort of solves the NAT traversal problem. I haven't used it but I think it does. Correct me if I'm wrong. Btw... does anyone have experience using Xtunnel in their system?
Of course only clients supporting this are their own.. x-lite & eyebeam, but they aren't the worst clients around. Eyebeam has even sort of "ICE support". Meaning no TURN protocol, but STUN and Xtunnel.
- Teemu
2005/12/1, Cesc cesc.santa@gmail.com:
On 11/30/05, Nils Ohlmeier lists@ohlmeier.org wrote:
What you are probably thinking of is, that an UA with ICE support could
also
advertise its IP address and port of the RTP proxy, but this is then
called
TURN. And I think that is even more far away from becoming a standard, besides that their are AFAIK no UA's or TURN servers available yet.
Hope this helps Nils
I think that the MiniSIP project is developing one client and server... www.minisip.org, in the "branches" of the SVN repository. No idea how far is it from being usable at all.
Cesc
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Teemu Harju http://www.teemuharju.net
On Thursday 01 December 2005 11:50, Teemu Harju wrote:
Couterpath (www.counterpath.com) (formerly known as Xten) has this Xtunnel ( www.xtunnels.org) which sort of solves the NAT traversal problem. I haven't used it but I think it does. Correct me if I'm wrong. Btw... does anyone have experience using Xtunnel in their system?
Of course only clients supporting this are their own.. x-lite & eyebeam, but they aren't the worst clients around. Eyebeam has even sort of "ICE support". Meaning no TURN protocol, but STUN and Xtunnel.
Yes Eyebeam has ICE support. But as I said, as ICE is still a moving target I'm not aware of any interoperable ICE implementation.
And to avoid confusion: ICE with Xtunnel makes IMHO no sence. ICE is for media path optimisation. TURN is for NAT traversal. These are almost counterparts.
Regards Nils
- Teemu
2005/12/1, Cesc cesc.santa@gmail.com:
On 11/30/05, Nils Ohlmeier lists@ohlmeier.org wrote:
What you are probably thinking of is, that an UA with ICE support could
also
advertise its IP address and port of the RTP proxy, but this is then
called
TURN. And I think that is even more far away from becoming a standard, besides that their are AFAIK no UA's or TURN servers available yet.
Hope this helps Nils
I think that the MiniSIP project is developing one client and server... www.minisip.org, in the "branches" of the SVN repository. No idea how far is it from being usable at all.
Cesc
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Teemu Harju http://www.teemuharju.net
I have tested LCR routing and it is working as I had expected. My question is if I only want to send traffic to this one certain gateway for prefix "1207" Maine, USA it will try the gateway 3 times then it will load the next gateway even if it is in another group. In some instances I would not like it to rollover to any other gateway.
Is there a way to tell SER to just send 500 No more gateways for specific group? I know it sounds odd but if I route some wholesale traffic at a certain rate I dont want it dumping to another gateway that has a poor 1207 rate. This would only be used in certain cases not for retail customers
Oh!! One other question has anyone tested to see if %@192.168.1.1 in the from_uri of the LCR table will work?? Basically Company A's gateway IP is 192.168.1.1 and sending traffic to me can I use LCR from_uri to route the traffic??
Eric
As I can talk to experts here: The SNOM 200 also allows my to configure ICE support, but using it I do not see any difference in the SDP than without ICE support. And of course it does not work with eyebeam's ICE version.
Is the SNOM's ICE version known to not work?
klaus
Nils Ohlmeier wrote:
On Thursday 01 December 2005 11:50, Teemu Harju wrote:
Couterpath (www.counterpath.com) (formerly known as Xten) has this Xtunnel ( www.xtunnels.org) which sort of solves the NAT traversal problem. I haven't used it but I think it does. Correct me if I'm wrong. Btw... does anyone have experience using Xtunnel in their system?
Of course only clients supporting this are their own.. x-lite & eyebeam, but they aren't the worst clients around. Eyebeam has even sort of "ICE support". Meaning no TURN protocol, but STUN and Xtunnel.
Yes Eyebeam has ICE support. But as I said, as ICE is still a moving target I'm not aware of any interoperable ICE implementation.
And to avoid confusion: ICE with Xtunnel makes IMHO no sence. ICE is for media path optimisation. TURN is for NAT traversal. These are almost counterparts.
Regards Nils
- Teemu
2005/12/1, Cesc cesc.santa@gmail.com:
On 11/30/05, Nils Ohlmeier lists@ohlmeier.org wrote:
What you are probably thinking of is, that an UA with ICE support could
also
advertise its IP address and port of the RTP proxy, but this is then
called
TURN. And I think that is even more far away from becoming a standard, besides that their are AFAIK no UA's or TURN servers available yet.
Hope this helps Nils
I think that the MiniSIP project is developing one client and server... www.minisip.org, in the "branches" of the SVN repository. No idea how far is it from being usable at all.
Cesc
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Teemu Harju http://www.teemuharju.net
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Bogdan-Andrei Iancu -
Cesc -
Christophe Irles -
Eric Haskins -
Klaus Darilion -
Nils Ohlmeier -
Teemu Harju