Untitled Document Hello all ....
I'm having a problem with our server or customers. Most of our clients access the server using the combination ATA and ADSL Modem, but when the ADSL drops and returns in a few minutes, the ATA can no longer make the register on SIP server. Sometimes passing through the modem or the requests of the ATA. I identified that this happens a lot with the D-Link modems DSL-500B and siemens SpeedStream 4200. If someone went through this I would your help ...
thanks
--------------------------------------------------------------------------
Alcindo Schleder Sistema Processa Acessoria e Comunicações Ltda.
a.. MSN: a_schleder@hotmail.com b.. Skipe: alcindo_schleder Demétrio P. dos Santos, 705 - 95670-000 - Gramado-RS-Brasil Celular + 55 54 9966 7591 alcindo@processa.org Fone +55 54 3286-1738 comercial@processa.org
I have used the ser_stun.c/.h files to add STUN support on the socket of kamalio.
I have modified the XOR-MAPPED-ADDRESS results because wireshark is not analysing it the same way although I'm not very sure who is right on this: wireshark versus ser.
I hope you guys can work on merging and testing. Coming from ser, I guess the code is pretty good!
http://sip.antisip.com/kamailio/
Modifications: * 2 new files * 10 lines of modification in udp_server.c
compared to ser code, I also hardcoded removal of fingerprint but that should come back when a configuration option will be there to enable/disable it.
Keep me informed, tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
2009/1/2 Aymeric Moizard jack@atosc.org:
I have used the ser_stun.c/.h files to add STUN support on the socket of kamalio.
I have modified the XOR-MAPPED-ADDRESS results because wireshark is not analysing it the same way although I'm not very sure who is right on this: wireshark versus ser.
I hope you guys can work on merging and testing. Coming from ser, I guess the code is pretty good!
Let me a question. What is the purpose/advantage of having a STUN server running in the SIP proxy/registrar port? AFAIK this is just valid for a single purpose: allowing STUN *just for SIP signalling* when the device is located behind symmetric NAT (in which "normal" STUN doesn't work since the public mapping the router assigns depends also on the destination ip:port, and not just on the private source ip:port).
This is: having a STUN server running in port 5060 in the same host where our SIP proxy/registrar runs is just valid for a UA behind symmetric NAT because it can set the "Contact" header with the mapped public ip:port, so it will be able to receive in-dialog requests (without NAT solution at SIP level in the proxy), but it will never be valid for RTP, since the destination of the RTP will never be PROXY_IP:5060, so the mapping our symmetric NAT router will do for the RTP is completely unknown.
So, what is the advantage of a STUN server in port 5060? Thanks.
On Fri, 2 Jan 2009, Iñaki Baz Castillo wrote:
2009/1/2 Aymeric Moizard jack@atosc.org:
I have used the ser_stun.c/.h files to add STUN support on the socket of kamalio.
I have modified the XOR-MAPPED-ADDRESS results because wireshark is not analysing it the same way although I'm not very sure who is right on this: wireshark versus ser.
I hope you guys can work on merging and testing. Coming from ser, I guess the code is pretty good!
Let me a question. What is the purpose/advantage of having a STUN server running in the SIP proxy/registrar port? AFAIK this is just valid for a single purpose: allowing STUN *just for SIP signalling* when the device is located behind symmetric NAT (in which "normal" STUN doesn't work since the public mapping the router assigns depends also on the destination ip:port, and not just on the private source ip:port).
This is: having a STUN server running in port 5060 in the same host where our SIP proxy/registrar runs is just valid for a UA behind symmetric NAT because it can set the "Contact" header with the mapped public ip:port, so it will be able to receive in-dialog requests (without NAT solution at SIP level in the proxy), but it will never be valid for RTP, since the destination of the RTP will never be PROXY_IP:5060, so the mapping our symmetric NAT router will do for the RTP is completely unknown.
So, what is the advantage of a STUN server in port 5060? Thanks.
This specification draft-ietf-sip-outbound-16 ios only about SIP: http://tools.ietf.org/html/draft-ietf-sip-outbound-16
So for 100% of UA, STUN is usable for keeping alive and detecting IP changes on the SIP connection.
Don't you want kamailio to be standard?
For RTP? Even if you put a STUN server on another port, that would not be of any help at all... because only part of the 100% can use the STUN discovered address in their RTP and such solution would not work 100%. Instead for RTP, ICE and TURN are required. That's just a different server that has to be installed: NOT THE SAME as the one running on the SIP server which is ONLY doing STUN binding request.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
2009/1/3 Aymeric Moizard jack@atosc.org:
This specification draft-ietf-sip-outbound-16 ios only about SIP: http://tools.ietf.org/html/draft-ietf-sip-outbound-16
True, I didn't read it. Thanks.
So for 100% of UA, STUN is usable for keeping alive and detecting IP changes on the SIP connection.
Don't you want kamailio to be standard?
Why do you thing so? Of course I want it. I was just asking a question, no more. ;)
For RTP? Even if you put a STUN server on another port, that would not be of any help at all... because only part of the 100% can use the STUN discovered address in their RTP and such solution would not work 100%.
Which is the reason for it? do you mean those routers that "sometimes" behave as symmetric NAT router and other times not? Or perhaps you mean that even in a normal and correct router (not symmetric NAT) STUN would not work on 100% of cases?
Instead for RTP, ICE and TURN are required. That's just a different server that has to be installed: NOT THE SAME as the one running on the SIP server which is ONLY doing STUN binding request.
Well, AFAIK ICE is very far from being interoperable, isn't it? And TURN requires RTP through a media proxy, that is not a very scalable solution :(
Thanks for your reply and thanks for your work :)
On Sat, 3 Jan 2009, Iñaki Baz Castillo wrote:
2009/1/3 Aymeric Moizard jack@atosc.org:
This specification draft-ietf-sip-outbound-16 ios only about SIP: http://tools.ietf.org/html/draft-ietf-sip-outbound-16
True, I didn't read it. Thanks.
You're welcome.
So for 100% of UA, STUN is usable for keeping alive and detecting IP changes on the SIP connection.
Don't you want kamailio to be standard?
Why do you thing so? Of course I want it. I was just asking a question, no more. ;)
It though you were aware of the draft! This draft looks important to me as a first step, because it's important, for compliance that the contact header is not changed in INVITEs by proxies... This is a first step towards message integrity... (Second step is about ICE discussion below!)
For RTP? Even if you put a STUN server on another port, that would not be of any help at all... because only part of the 100% can use the STUN discovered address in their RTP and such solution would not work 100%.
Which is the reason for it? do you mean those routers that "sometimes" behave as symmetric NAT router and other times not? Or perhaps you mean that even in a normal and correct router (not symmetric NAT) STUN would not work on 100% of cases?
Yes. Quoting the new rfc5389 that deprecated old STUN rfc3489:
"STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution."
So, what I meant is that STUN is not a global solution for RTP: as you know, if you open a hole in your NAT using STUN, you cannot be sure you can receive RTP through this hole. Also, the above new rfc, clearly states that it's impossible to predict a NAT behavior even if you have made some test and determined that it was a symmetric NAT for example.
However, the STUN *usage* (wording of ietf rfc5389) described in "draft-ietf-sip-outbound-16" is a global solution for SIP connection to "outbound" proxy.
Instead for RTP, ICE and TURN are required. That's just a different server that has to be installed: NOT THE SAME as the one running on the SIP server which is ONLY doing STUN binding request.
Well, AFAIK ICE is very far from being interoperable, isn't it?
You are right, but I do not think the draft is guilty there: the specification is very interoperable and there is no reason which should prevent application developper to implement it correctly.
I'm using an ICE version of draft-13 in my products and I'm not interoperable with anyone (never tested any in fact...) but the solution does work properly in closed environment. No doubt to me.
And TURN requires RTP through a media proxy, that is not a very scalable solution :(
ICE is a scalable solutions:
* SRV records do the balancing over several TURN server. * TURN is used ONLY when 2 peers cannot connect together, this means that it's much better than always offering RTP relay which is the solution today. * ICE allow to certify that you are sending the RTP data to your correspondant (ther is an ICE password in SDP) * ICE will allow 100% of direct connection and will never use TURN in a BEHAVE compliant environment: rfc4787. (no symmetric NAT any more...)
In the future, ICE is supposed to never use TURN at all because all direct connection will be possible. 0% relay is PLANNED by ietf and ICE ;)
Isn't it great news for the future? and peer to peer UDP exchange using a SIP network?
Thanks for your reply and thanks for your work :)
I thank you all for yours and wish the best for the next "sip router project"...
I also want to inform people that are not aware that a nice turnserver is available there:
http://turnserver.sourceforge.net/
That will surely help people to become compliant to ICE! I'm currently working with it for testing purpose and I will try to connect it to my kamailio sql database...
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
Aymeric Moizard writes:
- TURN is used ONLY when 2 peers cannot connect together, this means that it's much better than always offering RTP relay which is the solution today.
kamailio tools allow you to choose when to use rtp relay and when not. it is not used always in my configuration.
- ICE allow to certify that you are sending the RTP data to your correspondant (ther is an ICE password in SDP)
there are also other solutions for this, like quite commonly implemented zrtp, which has the additional advantage that rtp is also encrypted.
negative aspect of ice is that the spec is VERY complicated and hard to understand. even the tutorial by rosenberg was too much to me.
-- juha
On Sun, 4 Jan 2009, Juha Heinanen wrote:
Aymeric Moizard writes:
- TURN is used ONLY when 2 peers cannot connect together, this means that it's much better than always offering RTP relay which is the solution today.
kamailio tools allow you to choose when to use rtp relay and when not. it is not used always in my configuration.
My opinion is that no decision can be taken on kamailio. Or any proxy... It's technically not possible. Only the client and ICE could decide wether to use relay or not.
All the tools/way/tricks tha I'm aware of, TRY to guess by looking at IPs for example, or comparing source port and contact or via port: all those tricks are just bad guess for many reasons.
If you have a 100% working trick, I'll be interested to learn it! Very interested!
- ICE allow to certify that you are sending the RTP data to your correspondant (ther is an ICE password in SDP)
there are also other solutions for this, like quite commonly implemented zrtp, which has the additional advantage that rtp is also encrypted.
ICE helps to find direct connection between peers securely: still it doesn't prevent from receiving spoofed data on the discovered connection. zrtp is there to fill the gap: not a conflict at all.
negative aspect of ice is that the spec is VERY complicated and hard to understand. even the tutorial by rosenberg was too much to me.
Well, I'm not saying it's not complicated... I fully agree there. But still this is the best (& only?) way to optimize the SIP udp media path.
Until ICE come, there will never be any success for the internet part of SIP: the only reliable (optimized) calls today are the SIP to PSTN calls and that is very very sad and unusefull.
Of course, non optimized free SIP (telephony..) services can be provided, but this comes at a high cost: you have to provide the relay services, modify contact headers, modify SDP contents, break SIP message integrity, provide low quality voice & video (relay...). Last point but not the least, is there any existing way to make sure you can provide inter-domain SIP calls? (2 RTP relays are inserted in the path or a proxy fix a contact header to the IP/port source of the previous proxy...)
I want ICE to be implemented, no matter the effort. Else, I think there is no value in SIP or VoIP except for commercial usage.
Please help the world and vote for ICE whatever the effort. If not, join the IMS effort to make millions of $ for the next decades. That's a choice! (no flame to anyone here, don't misunderstood me... I just feel sad)
MAIL was a success & free probably because correct deployment is easy. With ICE, SIP could become the same.
I'm done! Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
-- juha
Aymeric Moizard writes:
If you have a 100% working trick, I'll be interested to learn it! Very interested!
no, i don't have 100% working trick, but normal means cover 90+% of the cases. trying to avoid needless use of rtp proxy for the remainder is not worth of the extreme complexity that comes with ice.
Well, I'm not saying it's not complicated... I fully agree there. But still this is the best (& only?) way to optimize the SIP udp media path.
as i said in above, kamailio's nat tools work well enough so that the added complexity of ice cannot be justified.
Until ICE come, there will never be any success for the internet part of SIP: the only reliable (optimized) calls today are the SIP to PSTN calls and that is very very sad and unusefull.
i don't understand what you try to say in above. sip works fine over the internet today.
I want ICE to be implemented, no matter the effort. Else, I think there is no value in SIP or VoIP except for commercial usage.
i don't agree with you regarding the value statement and you are welcome to try to implement ice. i'm just saying that it provides too little value for me taking into account its complexity and lack of implementations in UAs.
-- juha
On Sun, 4 Jan 2009, Juha Heinanen wrote:
Aymeric Moizard writes:
If you have a 100% working trick, I'll be interested to learn it! Very interested!
no, i don't have 100% working trick, but normal means cover 90+% of the cases. trying to avoid needless use of rtp proxy for the remainder is not worth of the extreme complexity that comes with ice.
So the 10% calls are the one that use relay when they should not? right? I'm pretty convinced this is not a true value. Anyway, I don't think this is a problem of number here.
Let's describe a case:
I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm calling somebody (a UA of course) who is able to decrypt it.
Whatever trick you provide, I will not have always voice (except if ICE is supported or if the NAT are kind with me)
Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt their signalling. NEVER encrypt their signalling.
i don't understand what you try to say in above. sip works fine over the internet today.
SIP works today **if**: * no security * no SIP message integrity is used * sip server are well configured (...) * sip server is not compliant (modifying contact and SDP...)
My conclusion is that it's not acceptable. I want my applications to do security and I don't want to be dependant on badly configured servers.
I don't want "SIP works today **if**", I want "SIP works today."
I just need a SIP compliant internet infrastructure.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
-- juha
2009/1/4 Aymeric Moizard jack@atosc.org:
Let's describe a case:
I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm calling somebody (a UA of course) who is able to decrypt it.
Whatever trick you provide, I will not have always voice (except if ICE is supported or if the NAT are kind with me)
Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt their signalling. NEVER encrypt their signalling.
i don't understand what you try to say in above. sip works fine over the internet today.
SIP works today **if**:
- no security
- no SIP message integrity is used
- sip server are well configured (...)
- sip server is not compliant (modifying contact and SDP...)
My conclusion is that it's not acceptable. I want my applications to do security and I don't want to be dependant on badly configured servers.
I just can agree with those true and well explained points. It's 100% true.
For now, in a true SIP environment (this is: SIP calls between Internet endpoints, no PSTN) NAT issue is solved by: - Forcing RTP through a media proxy which involves SDP rewritting by the SIP proxy (so SDP cannot be encrypted). - The only case in which the media proxy can be avoided is that in which both the caller and callee use STUN (no symmetric NAT) or are behind same public IP. - "Contact" header must be rewritten by the SIP proxy in order to allow future in-dialog requests to an UA behind NAT.
All of this is sad. For example: - In case of multipart SIP messages it's possible that the SIP proxy is not capable of rewritting it properly (i.e. RtpProxy cannot handle it for now). - When the proxy rewrittes the private IP:port of the "Contact" header with the received public IP:port, it means that this UA will receive an in-dialog request with a RURI: sip:user@PUBLIC_IP:PUBLIC_PORT. If the UA is 100% SIP stric it will reject this request since the RURI is not itself (RFC 3261 says that the UA MUST inspect the whole RURI to check if it matches itself, not just the RURI username).
I don't want "SIP works today **if**", I want "SIP works today."
I just need a SIP compliant internet infrastructure.
All this thread is encouraging me to check and learn about ICE and try it. :)
Iñaki Baz Castillo writes:
- Forcing RTP through a media proxy which involves SDP rewritting by
the SIP proxy (so SDP cannot be encrypted).
forcing sip through proxies means that headers cannot be encrypted. i fail to see a big difference.
- The only case in which the media proxy can be avoided is that in
which both the caller and callee use STUN (no symmetric NAT) or are behind same public IP.
the above is not true.
-- juha
2009/1/4 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
- Forcing RTP through a media proxy which involves SDP rewritting by
the SIP proxy (so SDP cannot be encrypted).
forcing sip through proxies means that headers cannot be encrypted. i fail to see a big difference.
Well, it shouldn't be required that a SIP proxy inspects the message *body* in order communication to work. Also, just a few headers needs to be readable by proxies. If I remember well, SIP tunnelling with S/MIME usage allows encrypting some headers and the entire body while the proxy still can read the required headers (anyway, I hate concepts as "S/MIME" in SIP even if it appears in lots of RFC's and drafts since it's obvious it doesn't success).
However, what I mean is that rewritting the SDP is something "dirty", don't you agree? Unfortunatelly all of us are used to SIP scenarios in which the proxies rewrite the "Contact" header and the SDP. I consider it as a needed hack, but nothing ellegant. If ICE and Turn can offer here an ellegant and clean solution then they are really welcome.
- The only case in which the media proxy can be avoided is that in
which both the caller and callee use STUN (no symmetric NAT) or are behind same public IP.
the above is not true.
Ok, I simplified too much. Other cases: - One of the endpoints has public IP and supports Comedia mode. - One of the endpoints has public IP and the other is behind non symmetric NAT using STUN.
AFAIK there are no more cases in which the caller and/or callee are behind NAT but a media proxy is not required, are there?
Regards.
On Sun, 4 Jan 2009, Iñaki Baz Castillo wrote:
2009/1/4 Juha Heinanen jh@tutpro.com: Iñaki Baz Castillo writes:
- Forcing RTP through a media proxy which involves SDP rewritting by
the SIP proxy (so SDP cannot be encrypted).
forcing sip through proxies means that headers cannot be encrypted. i fail to see a big difference.
Well, it shouldn't be required that a SIP proxy inspects the message *body* in order communication to work. Also, just a few headers needs to be readable by proxies. If I remember well, SIP tunnelling with S/MIME usage allows encrypting some headers and the entire body while the proxy still can read the required headers (anyway, I hate concepts as "S/MIME" in SIP even if it appears in lots of RFC's and drafts since it's obvious it doesn't success).
My 2 cents to the discussion:
The obvious advantage are that if you have an encrypted copy of SDP and To/From header AND a readable copy of To/From header in the same message: * the target endpoint is the only one to decrypt the SDP * the target endpoint can be sure no proxy have modified the To/From identity of the caller.
I agree S/MIME is not well accepted -same for mail- but this feature will be possible with other technology.
However, what I mean is that rewritting the SDP is something "dirty", don't you agree?
I do! ;) Good to hear that...
Unfortunatelly all of us are used to SIP scenarios in which the proxies rewrite the "Contact" header and the SDP. I consider it as a needed hack, but nothing ellegant. If ICE and Turn can offer here an ellegant and clean solution then they are really welcome.
It will! Elegant & clean and when deployed on behave-compliant IP network, you don't even need TURN... and ICE becomes fairly simple.
- The only case in which the media proxy can be avoided is that in
which both the caller and callee use STUN (no symmetric NAT) or are behind same public IP.
the above is not true.
Ok, I simplified too much. Other cases:
- One of the endpoints has public IP and supports Comedia mode.
- One of the endpoints has public IP and the other is behind non
symmetric NAT using STUN.
AFAIK there are no more cases in which the caller and/or callee are behind NAT but a media proxy is not required, are there?
The problem with this is that the decision about endpoints are not 100% true: * what about redirection? * what about case where you have several proxy? * What if the endpoint is detected as a non-symmetric NAT (most probably, you detect this on SIP signalling port.) but becomes symmetric on the RTP port?
ICE don't need to know where you are on the internet: it just work. It's also capable of doing TCP/TLS connection to the TURN server to tunnel UDP data for NAT configured to block UDP...
Aymeric
Regards.
-- Iñaki Baz Castillo ibc@aliax.net _______________________________________________ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
2009/1/4 Aymeric Moizard jack@atosc.org:
Ok, I simplified too much. Other cases:
- One of the endpoints has public IP and supports Comedia mode.
- One of the endpoints has public IP and the other is behind non
symmetric NAT using STUN.
AFAIK there are no more cases in which the caller and/or callee are behind NAT but a media proxy is not required, are there?
The problem with this is that the decision about endpoints are not 100% true:
- what about redirection?
Do you mean 3XX redirection? No problem at all. 3XX response will generate a new INVITE in the client if the proxy doesn't do recursion. If the proxy does recursion then it generates a new branch to the 3XX "Contact" URI, and for each branch the need of media proxy is computed. No problem at all.
- what about case where you have several proxy?
Yes, good point. But it's really difficult an scenario in which two users behind the same NAT connect to different proxies. In this case the media proxy would be enabled even if not necessary.
- What if the endpoint is detected as a non-symmetric NAT (most
probably, you detect this on SIP signalling port.) but becomes symmetric on the RTP port?
Life is hard XD
ICE don't need to know where you are on the internet: it just work. It's also capable of doing TCP/TLS connection to the TURN server to tunnel UDP data for NAT configured to block UDP...
It sounds really nice. What I really like is the idea of non-replacing the "Contact" header in the proxy (described in "outbound" proxy AFAIK).
Regards.
On Sun, 4 Jan 2009, Iñaki Baz Castillo wrote:
- what about case where you have several proxy?
Yes, good point. But it's really difficult an scenario in which two users behind the same NAT connect to different proxies. In this case the media proxy would be enabled even if not necessary.
Not all relay work if several media proxy are used because some RTP relay wait for RTP data before relaying and RTP is received on the other relay....
- What if the endpoint is detected as a non-symmetric NAT (most
probably, you detect this on SIP signalling port.) but becomes symmetric on the RTP port?
Life is hard XD
so hard...
ICE don't need to know where you are on the internet: it just work. It's also capable of doing TCP/TLS connection to the TURN server to tunnel UDP data for NAT configured to block UDP...
It sounds really nice. What I really like is the idea of non-replacing the "Contact" header in the proxy (described in "outbound" proxy AFAIK).
UA can have correct contact even if not using outbound:
send OPTIONS check received= and rport= parameter in answer. send REGISTER with correct contact binding!
easy....
Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
2009/1/4 Aymeric Moizard jack@atosc.org:
On Sun, 4 Jan 2009, Iñaki Baz Castillo wrote:
- what about case where you have several proxy?
Yes, good point. But it's really difficult an scenario in which two users behind the same NAT connect to different proxies. In this case the media proxy would be enabled even if not necessary.
Not all relay work if several media proxy are used because some RTP relay wait for RTP data before relaying and RTP is received on the other relay....
Yes, but there are some workarounds. For example nathelper module in Kamailio adds a SDP line: "a=nortpproxy" when it enables RtpProxy, so if other proxy in the patch tries to add its own RtpProxy it won't do it due to the presence of that SDP line.
And AFAIK, MediaProxy doesn't suffer of this issue.
What I really like is the idea of non-replacing the "Contact" header in the proxy (described in "outbound" proxy AFAIK).
UA can have correct contact even if not using outbound:
send OPTIONS check received= and rport= parameter in answer. send REGISTER with correct contact binding!
easy....
Yeah, but does some UA implement it? is this technique defined in some RFC/draft?
So what you mean is that, with "outbound" draft, the UA registers the public URI (after discovering it using STUN), is it? (I must re-read the draft XD).
Best regards.
Happy new year everybody!
I'm trying to do some testing of the carrierroute module, but after doing adding some gateways on the carrierroute table and doing some testings I got the following error:
ERROR:carrierroute:cr_do_route: desired routing domain doesn't exist, prefix 12345, carrier 1, domain 2
Can any of you give me some advice about how to tackle this error?
Thanks in advance,
Juan.-
My carrierroute table looks like this:
mysql> select * from carrierroute; +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ | id | carrier | domain | scan_prefix | flags | mask | prob | strip | rewrite_host | rewrite_prefix | rewrite_suffix | description | +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ | 1 | 1 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 2 | 2 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 3 | 3 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 4 | 1 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 5 | 2 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 6 | 3 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 7 | 1 | 2 | 0 | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 8 | 2 | 2 | 1 | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 9 | 3 | 2 | 2 | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ 9 rows in set (0.00 sec)
Juan Asencio wrote:
Happy new year everybody!
I'm trying to do some testing of the carrierroute module, but after doing adding some gateways on the carrierroute table and doing some testings I got the following error:
ERROR:carrierroute:cr_do_route: desired routing domain doesn't exist, prefix 12345, carrier 1, domain 2
Can any of you give me some advice about how to tackle this error?
Thanks in advance,
Juan.-
My carrierroute table looks like this:
mysql> select * from carrierroute; +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ | id | carrier | domain | scan_prefix | flags | mask | prob | strip | rewrite_host | rewrite_prefix | rewrite_suffix | description | +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ | 1 | 1 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 2 | 2 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 3 | 3 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 4 | 1 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 5 | 2 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 6 | 3 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 7 | 1 | 2 | 0 | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 8 | 2 | 2 | 1 | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 9 | 3 | 2 | 2 | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ 9 rows in set (0.00 sec)
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hi list, I found the problem.
Now I'm able to see one of the gateways :)
Cheers,
Juan.-
I respectfully disagree -- the field has clearly shown that working NAT traversal today is more valuable than message integrity and ICE architecture both together. (Whcih happens to be my personal preference too: getting over NATs today is more important to me than any sort of securing free phone calls.) Generally I tend to prefer priorities as articulated by live deployments.
I'm sorry to be so differently opinionated on this, particularly because I like ICE esthetically as the "e2e" solution. However, somehow in the Internet the things that are deployable today always matter. (even if considered evil, such as NATs)
-jiri
Aymeric Moizard wrote:
On Sun, 4 Jan 2009, Juha Heinanen wrote:
Aymeric Moizard writes:
If you have a 100% working trick, I'll be interested to learn it! Very interested!
no, i don't have 100% working trick, but normal means cover 90+% of the cases. trying to avoid needless use of rtp proxy for the remainder is not worth of the extreme complexity that comes with ice.
So the 10% calls are the one that use relay when they should not? right? I'm pretty convinced this is not a true value. Anyway, I don't think this is a problem of number here.
Let's describe a case:
I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm calling somebody (a UA of course) who is able to decrypt it.
Whatever trick you provide, I will not have always voice (except if ICE is supported or if the NAT are kind with me)
Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt their signalling. NEVER encrypt their signalling.
i don't understand what you try to say in above. sip works fine over the internet today.
SIP works today **if**:
- no security
- no SIP message integrity is used
- sip server are well configured (...)
- sip server is not compliant (modifying contact and SDP...)
My conclusion is that it's not acceptable. I want my applications to do security and I don't want to be dependant on badly configured servers.
I don't want "SIP works today **if**", I want "SIP works today."
I just need a SIP compliant internet infrastructure.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
-- juha
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
On Wed, 7 Jan 2009, Jiri Kuthan wrote:
I respectfully disagree -- the field has clearly shown that working NAT traversal today is more valuable than message integrity and ICE architecture both together. (Whcih happens to be my personal preference too: getting over NATs today is more important to me than any sort of securing free phone calls.) Generally I tend to prefer priorities as articulated by live deployments.
I think we both agree on where we want to go.
The difference is probably that current way SIP is used might be enough for you, but as a 10 years SIP endpoint stack builder, I'm just bored about using SIP over non transparent network. Not your fault...
I'm sorry to be so differently opinionated on this, particularly because I like ICE esthetically as the "e2e" solution. However, somehow in the Internet the things that are deployable today always matter. (even if considered evil, such as NATs)
Don't be sorry. My intention for this thread was just to ask ser/kamailio/whatever to make sure the future will not be the same as the 10 past years. My intention was not to say "you are all wrong".
Aymeric
-jiri
Aymeric Moizard wrote:
On Sun, 4 Jan 2009, Juha Heinanen wrote:
Aymeric Moizard writes:
If you have a 100% working trick, I'll be interested to learn it! Very interested!
no, i don't have 100% working trick, but normal means cover 90+% of the cases. trying to avoid needless use of rtp proxy for the remainder is not worth of the extreme complexity that comes with ice.
So the 10% calls are the one that use relay when they should not? right? I'm pretty convinced this is not a true value. Anyway, I don't think this is a problem of number here.
Let's describe a case:
I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm calling somebody (a UA of course) who is able to decrypt it.
Whatever trick you provide, I will not have always voice (except if ICE is supported or if the NAT are kind with me)
Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt their signalling. NEVER encrypt their signalling.
i don't understand what you try to say in above. sip works fine over the internet today.
SIP works today **if**:
- no security
- no SIP message integrity is used
- sip server are well configured (...)
- sip server is not compliant (modifying contact and SDP...)
My conclusion is that it's not acceptable. I want my applications to do security and I don't want to be dependant on badly configured servers.
I don't want "SIP works today **if**", I want "SIP works today."
I just need a SIP compliant internet infrastructure.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
-- juha
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Aymeric Moizard wrote:
On Wed, 7 Jan 2009, Jiri Kuthan wrote:
I respectfully disagree -- the field has clearly shown that working NAT traversal today is more valuable than message integrity and ICE architecture both together. (Whcih happens to be my personal preference too: getting over NATs today is more important to me than any sort of securing free phone calls.) Generally I tend to prefer priorities as articulated by live deployments.
I think we both agree on where we want to go.
The difference is probably that current way SIP is used might be enough for you, but as a 10 years SIP endpoint stack builder, I'm just bored about using SIP over non transparent network. Not your fault...
I'm sorry to be so differently opinionated on this, particularly because I like ICE esthetically as the "e2e" solution. However, somehow in the Internet the things that are deployable today always matter. (even if considered evil, such as NATs)
Don't be sorry. My intention for this thread was just to ask ser/kamailio/whatever to make sure the future will not be the same as the 10 past years. My intention was not to say "you are all wrong".
No problem at all -- it is indeed an uneasy question.
The end-to-end-ness of ice seems appealing like say TCP does. TCP is robust in that whatever happens in the network, smart software (quite complex in fact) in the end-devices can deal with it. So I keep asking myself why ICE is getting so little traction if the same thing works for TCP. One of the reasons could be that it is a sort of backwards-compatibility problem, since in a way it is a layer 3/4 technology and changing IP/transport layer is just painful. One could also argue that it can't be fully e2e since it relies on network via TURN, even though as the last resort.
It is not a clear bet to me -- in fact I fell a bit ashamed I may be giving up on ICE too early. Still I do. Does anyone have a memory of a technology that was "clean", came late and surpassed "internet workarounds"?
-jiri
Aymeric
-jiri
Aymeric Moizard wrote:
On Sun, 4 Jan 2009, Juha Heinanen wrote:
Aymeric Moizard writes:
If you have a 100% working trick, I'll be interested to learn it! Very interested!
no, i don't have 100% working trick, but normal means cover 90+% of the cases. trying to avoid needless use of rtp proxy for the remainder is not worth of the extreme complexity that comes with ice.
So the 10% calls are the one that use relay when they should not? right? I'm pretty convinced this is not a true value. Anyway, I don't think this is a problem of number here.
Let's describe a case:
I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm calling somebody (a UA of course) who is able to decrypt it.
Whatever trick you provide, I will not have always voice (except if ICE is supported or if the NAT are kind with me)
Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt their signalling. NEVER encrypt their signalling.
i don't understand what you try to say in above. sip works fine over the internet today.
SIP works today **if**:
- no security
- no SIP message integrity is used
- sip server are well configured (...)
- sip server is not compliant (modifying contact and SDP...)
My conclusion is that it's not acceptable. I want my applications to do security and I don't want to be dependant on badly configured servers.
I don't want "SIP works today **if**", I want "SIP works today."
I just need a SIP compliant internet infrastructure.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
-- juha
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hello,
On 01/08/2009 09:32 PM, Jiri Kuthan wrote:
Aymeric Moizard wrote:
On Wed, 7 Jan 2009, Jiri Kuthan wrote:
I respectfully disagree -- the field has clearly shown that working NAT traversal today is more valuable than message integrity and ICE architecture both together. (Whcih happens to be my personal preference too: getting over NATs today is more important to me than any sort of securing free phone calls.) Generally I tend to prefer priorities as articulated by live deployments.
I think we both agree on where we want to go.
The difference is probably that current way SIP is used might be enough for you, but as a 10 years SIP endpoint stack builder, I'm just bored about using SIP over non transparent network. Not your fault...
I'm sorry to be so differently opinionated on this, particularly because I like ICE esthetically as the "e2e" solution. However, somehow in the Internet the things that are deployable today always matter. (even if considered evil, such as NATs)
Don't be sorry. My intention for this thread was just to ask ser/kamailio/whatever to make sure the future will not be the same as the 10 past years. My intention was not to say "you are all wrong".
No problem at all -- it is indeed an uneasy question.
The end-to-end-ness of ice seems appealing like say TCP does. TCP is robust in that whatever happens in the network, smart software (quite complex in fact) in the end-devices can deal with it. So I keep asking myself why ICE is getting so little traction if the same thing works for TCP. One of the reasons could be that it is a sort of backwards-compatibility problem, since in a way it is a layer 3/4 technology and changing IP/transport layer is just painful. One could also argue that it can't be fully e2e since it relies on network via TURN, even though as the last resort.
It is not a clear bet to me -- in fact I fell a bit ashamed I may be giving up on ICE too early. Still I do. Does anyone have a memory of a technology that was "clean", came late and surpassed "internet workarounds"?
The question could be the other way around: does anyone remember another technology that needed so many patches and workarounds :-)? Just thinking about the number of RFCs and drafts coming to complete/recommend/give usage guidelines ...
ICE came too late, the are millions of end user devices sold out there, without it. And as "workarounds" are in place, nobody will invest now (crisis :-) ?!?!) to replace them -- only the time will obsolete them. So we still have to stick to the solutions we have now.
Cheers, Daniel
-jiri
Aymeric
-jiri
Aymeric Moizard wrote:
On Sun, 4 Jan 2009, Juha Heinanen wrote:
Aymeric Moizard writes:
If you have a 100% working trick, I'll be interested to learn it! Very interested!
no, i don't have 100% working trick, but normal means cover 90+% of the cases. trying to avoid needless use of rtp proxy for the remainder is not worth of the extreme complexity that comes with ice.
So the 10% calls are the one that use relay when they should not? right? I'm pretty convinced this is not a true value. Anyway, I don't think this is a problem of number here.
Let's describe a case:
I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm calling somebody (a UA of course) who is able to decrypt it.
Whatever trick you provide, I will not have always voice (except if ICE is supported or if the NAT are kind with me)
Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt their signalling. NEVER encrypt their signalling.
i don't understand what you try to say in above. sip works fine over the internet today.
SIP works today **if**:
- no security
- no SIP message integrity is used
- sip server are well configured (...)
- sip server is not compliant (modifying contact and SDP...)
My conclusion is that it's not acceptable. I want my applications to do security and I don't want to be dependant on badly configured servers.
I don't want "SIP works today **if**", I want "SIP works today."
I just need a SIP compliant internet infrastructure.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
-- juha
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
On Fri, Jan 9, 2009 at 11:10 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 01/08/2009 09:32 PM, Jiri Kuthan wrote:
Aymeric Moizard wrote:
On Wed, 7 Jan 2009, Jiri Kuthan wrote:
I respectfully disagree -- the field has clearly shown that working NAT traversal today is more valuable than message integrity and ICE architecture both together. (Whcih happens to be my personal preference too: getting over NATs today is more important to me than any sort of securing free phone calls.) Generally I tend to prefer priorities as articulated by live deployments.
I think we both agree on where we want to go.
The difference is probably that current way SIP is used might be enough for you, but as a 10 years SIP endpoint stack builder, I'm just bored about using SIP over non transparent network. Not your fault...
I'm sorry to be so differently opinionated on this, particularly because I like ICE esthetically as the "e2e" solution. However, somehow in the Internet the things that are deployable today always matter. (even if considered evil, such as NATs)
Don't be sorry. My intention for this thread was just to ask ser/kamailio/whatever to make sure the future will not be the same as the 10 past years. My intention was not to say "you are all wrong".
No problem at all -- it is indeed an uneasy question.
The end-to-end-ness of ice seems appealing like say TCP does. TCP is robust in that whatever happens in the network, smart software (quite complex in fact) in the end-devices can deal with it. So I keep asking myself why ICE is getting so little traction if the same thing works for TCP. One of the reasons could be that it is a sort of backwards-compatibility problem, since in a way it is a layer 3/4 technology and changing IP/transport layer is just painful. One could also argue that it can't be fully e2e since it relies on network via TURN, even though as the last resort.
It is not a clear bet to me -- in fact I fell a bit ashamed I may be giving up on ICE too early. Still I do. Does anyone have a memory of a technology that was "clean", came late and surpassed "internet workarounds"?
The question could be the other way around: does anyone remember another technology that needed so many patches and workarounds :-)? Just thinking about the number of RFCs and drafts coming to complete/recommend/give usage guidelines ...
ICE came too late, the are millions of end user devices sold out there, without it. And as "workarounds" are in place, nobody will invest now (crisis :-) ?!?!) to replace them -- only the time will obsolete them. So we still have to stick to the solutions we have now.
I agree with what Daniel says. However, if we keep stuck to the solutions we have now we'll never obsolete them.
Cheers, -Victor
Cheers, Daniel
-jiri
Aymeric
-jiri
Aymeric Moizard wrote:
On Sun, 4 Jan 2009, Juha Heinanen wrote:
Aymeric Moizard writes:
> If you have a 100% working trick, I'll be interested to learn it! Very > interested! > no, i don't have 100% working trick, but normal means cover 90+% of the cases. trying to avoid needless use of rtp proxy for the remainder is not worth of the extreme complexity that comes with ice.
So the 10% calls are the one that use relay when they should not? right? I'm pretty convinced this is not a true value. Anyway, I don't think this is a problem of number here.
Let's describe a case:
I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm calling somebody (a UA of course) who is able to decrypt it.
Whatever trick you provide, I will not have always voice (except if ICE is supported or if the NAT are kind with me)
Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt their signalling. NEVER encrypt their signalling.
i don't understand what you try to say in above. sip works fine over the internet today.
SIP works today **if**:
- no security
- no SIP message integrity is used
- sip server are well configured (...)
- sip server is not compliant (modifying contact and SDP...)
My conclusion is that it's not acceptable. I want my applications to do security and I don't want to be dependant on badly configured servers.
I don't want "SIP works today **if**", I want "SIP works today."
I just need a SIP compliant internet infrastructure.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
-- juha
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Victor Pascual Ávila wrote:
It is not a clear bet to me -- in fact I fell a bit ashamed I may be giving up on ICE too early. Still I do. Does anyone have a memory of a technology that was "clean", came late and surpassed "internet workarounds"?
The question could be the other way around: does anyone remember another technology that needed so many patches and workarounds :-)? Just thinking about the number of RFCs and drafts coming to complete/recommend/give usage guidelines ...
ICE came too late, the are millions of end user devices sold out there, without it. And as "workarounds" are in place, nobody will invest now (crisis :-) ?!?!) to replace them -- only the time will obsolete them. So we still have to stick to the solutions we have now.
I agree with what Daniel says. However, if we keep stuck to the solutions we have now we'll never obsolete them.
Probably.
-jiri
On 01/09/2009 12:26 PM, Victor Pascual Ávila wrote:
On Fri, Jan 9, 2009 at 11:10 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 01/08/2009 09:32 PM, Jiri Kuthan wrote:
Aymeric Moizard wrote:
On Wed, 7 Jan 2009, Jiri Kuthan wrote:
I respectfully disagree -- the field has clearly shown that working NAT traversal today is more valuable than message integrity and ICE architecture both together. (Whcih happens to be my personal preference too: getting over NATs today is more important to me than any sort of securing free phone calls.) Generally I tend to prefer priorities as articulated by live deployments.
I think we both agree on where we want to go.
The difference is probably that current way SIP is used might be enough for you, but as a 10 years SIP endpoint stack builder, I'm just bored about using SIP over non transparent network. Not your fault...
I'm sorry to be so differently opinionated on this, particularly because I like ICE esthetically as the "e2e" solution. However, somehow in the Internet the things that are deployable today always matter. (even if considered evil, such as NATs)
Don't be sorry. My intention for this thread was just to ask ser/kamailio/whatever to make sure the future will not be the same as the 10 past years. My intention was not to say "you are all wrong".
No problem at all -- it is indeed an uneasy question.
The end-to-end-ness of ice seems appealing like say TCP does. TCP is robust in that whatever happens in the network, smart software (quite complex in fact) in the end-devices can deal with it. So I keep asking myself why ICE is getting so little traction if the same thing works for TCP. One of the reasons could be that it is a sort of backwards-compatibility problem, since in a way it is a layer 3/4 technology and changing IP/transport layer is just painful. One could also argue that it can't be fully e2e since it relies on network via TURN, even though as the last resort.
It is not a clear bet to me -- in fact I fell a bit ashamed I may be giving up on ICE too early. Still I do. Does anyone have a memory of a technology that was "clean", came late and surpassed "internet workarounds"?
The question could be the other way around: does anyone remember another technology that needed so many patches and workarounds :-)? Just thinking about the number of RFCs and drafts coming to complete/recommend/give usage guidelines ...
ICE came too late, the are millions of end user devices sold out there, without it. And as "workarounds" are in place, nobody will invest now (crisis :-) ?!?!) to replace them -- only the time will obsolete them. So we still have to stick to the solutions we have now.
I agree with what Daniel says. However, if we keep stuck to the solutions we have now we'll never obsolete them.
Completely true. It is scary that some technologies even obsolete look like never to be removed ... :-)
And from experience, for SIP, it has to get a new version number or a new name. It will be more attractive to be SIP3.0 compliant than SIP2.0 + RFCxyzw.
SIP 2.0 is so vagues right now with lot of extensions/amendments and what is still must/should/may.
Daniel
2009/1/9 Daniel-Constantin Mierla miconda@gmail.com:
The question could be the other way around: does anyone remember another technology that needed so many patches and workarounds :-)? Just thinking about the number of RFCs and drafts coming to complete/recommend/give usage guidelines ...
I can imagine IETF people writting RFC 3261 in their IPv6 LAN networks:
- IETF man in black 1: "humm, should I consider NAT in this specification?..."
- IETF man in black 2: "mmmmmm, but what is NAT?"
- IETF man in black 1: "AFAIK NAT is what the real world outside uses in their homes and offices, I think not all the world uses IPv6 yet... not sure..."
- IETF man in black 2: "but... if we solve NAT issue in this document... what could be writte in the future? I need to write more and more drafts and RFC, it's an obsession!"
- IETF man in black 1: "Ok, you ar right, let's ignore NAT. Hopefully noobdy will implement this specification..."
- IETF man in black 2: "Cheers"
ICE came too late, the are millions of end user devices sold out there, without it. And as "workarounds" are in place, nobody will invest now (crisis :-) ?!?!) to replace them -- only the time will obsolete them. So we still have to stick to the solutions we have now.
The good point of ICE is that it works end to end, so you can have a proxy that fixes NAT when needed ("Contact" or SDP with private IP). ICE will solve it in client side, as STUN, so proxy doesn't need to solve NAT in that case. Both methods can live together and this is cool since allows ICE implementation.
On Fri, Jan 9, 2009 at 12:06 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2009/1/9 Daniel-Constantin Mierla miconda@gmail.com:
The question could be the other way around: does anyone remember another technology that needed so many patches and workarounds :-)? Just thinking about the number of RFCs and drafts coming to complete/recommend/give usage guidelines ...
I can imagine IETF people writting RFC 3261 in their IPv6 LAN networks:
IETF man in black 1: "humm, should I consider NAT in this specification?..."
IETF man in black 2: "mmmmmm, but what is NAT?"
IETF man in black 1: "AFAIK NAT is what the real world outside uses in their homes and offices, I think not all the world uses IPv6 yet... not sure..."
IETF man in black 2: "but... if we solve NAT issue in this document... what could be writte in the future? I need to write more and more drafts and RFC, it's an obsession!"
IETF man in black 1: "Ok, you ar right, let's ignore NAT. Hopefully noobdy will implement this specification..."
IETF man in black 2: "Cheers"
Too acid to my taste
2009/1/9 Victor Pascual Ávila victor.pascual.avila@gmail.com:
Too acid to my taste
Imagine you must design a VoIP protocol from scratch in 2002. This protocol MUST work. Wouldn't you consider NAT?
2009/1/9 Iñaki Baz Castillo ibc@aliax.net:
2009/1/9 Victor Pascual Ávila victor.pascual.avila@gmail.com:
Too acid to my taste
Imagine you must design a VoIP protocol from scratch in 2002. This protocol MUST work. Wouldn't you consider NAT?
Also, don't worry at all. No member of IETF will read my joke since this is a maillist about a *real* implementation, so no interesting XD
PD: Maybe too acid now? How could I delete this mail?
On Fri, Jan 9, 2009 at 12:16 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2009/1/9 Victor Pascual Ávila victor.pascual.avila@gmail.com:
Too acid to my taste
Imagine you must design a VoIP protocol from scratch in 2002. This protocol MUST work. Wouldn't you consider NAT?
You perfectly know what I think about this issue-- we have had this discussion several times on different mailing lists. Learning from previous mistakes is a good thing :-)
Constructive feedback is most welcome-- repeatedly blaming from an armchair won't help on solving things. You are a knowledgeable guy. So, please join the IETF and help people to make a better Internet.
Don't take it personally,
On 01/09/2009 01:06 PM, Iñaki Baz Castillo wrote:
"but... if we solve NAT issue in this document... what could be writte in the future?
well, on the other hand is not bad. You would have been probably unemployed (or in other business) now if the SIP would have been simple.
I am thinking of SIP as developer's heaven -- never run out of new tasks.
It is an amazing business/money flow environment: - voip/++ services - developing - teaching - conformance testing - rfc writing - and you can still add...
Daniel
ICE came too late, the are millions of end user devices sold out there, without it. And as "workarounds" are in place, nobody will invest now (crisis :-) ?!?!) to replace them -- only the time will obsolete them. So we still have to stick to the solutions we have now.
The good point of ICE is that it works end to end, so you can have a proxy that fixes NAT when needed ("Contact" or SDP with private IP). ICE will solve it in client side, as STUN, so proxy doesn't need to solve NAT in that case. Both methods can live together and this is cool since allows ICE implementation.
Hello,
On 01/04/2009 04:22 PM, Aymeric Moizard wrote:
[...] Let's describe a case:
I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm calling somebody (a UA of course) who is able to decrypt it.
Whatever trick you provide, I will not have always voice (except if ICE is supported or if the NAT are kind with me)
Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt their signalling. NEVER encrypt their signalling.
do you mean end-to-end encryption just for SDP? Going over NAT using TLS is just fine.
Still you can encrypt parts of the SDP, just the signaling coordinates for RTP need to be clear. Some of those details are part of other SIP headers, the content of media stream can be SRTPed.
Cheers, Daniel
Aymeric Moizard schrieb:
On Sun, 4 Jan 2009, Juha Heinanen wrote:
Aymeric Moizard writes:
- TURN is used ONLY when 2 peers cannot connect together, this means that it's much better than always offering RTP relay which is the solution today.
kamailio tools allow you to choose when to use rtp relay and when not. it is not used always in my configuration.
My opinion is that no decision can be taken on kamailio. Or any proxy... It's technically not possible. Only the client and ICE could decide wether to use relay or not.
All the tools/way/tricks tha I'm aware of, TRY to guess by looking at IPs for example, or comparing source port and contact or via port: all those tricks are just bad guess for many reasons.
If you have a 100% working trick, I'll be interested to learn it! Very interested!
Another working trick is to use the media relay in 100% of the calls. Yes, it is not optimal but it works - and support hours do costs more money than bandwidth.
regards klaus
- ICE allow to certify that you are sending the RTP data to your correspondant (ther is an ICE password in SDP)
there are also other solutions for this, like quite commonly implemented zrtp, which has the additional advantage that rtp is also encrypted.
ICE helps to find direct connection between peers securely: still it doesn't prevent from receiving spoofed data on the discovered connection. zrtp is there to fill the gap: not a conflict at all.
negative aspect of ice is that the spec is VERY complicated and hard to understand. even the tutorial by rosenberg was too much to me.
Well, I'm not saying it's not complicated... I fully agree there. But still this is the best (& only?) way to optimize the SIP udp media path.
Until ICE come, there will never be any success for the internet part of SIP: the only reliable (optimized) calls today are the SIP to PSTN calls and that is very very sad and unusefull.
Of course, non optimized free SIP (telephony..) services can be provided, but this comes at a high cost: you have to provide the relay services, modify contact headers, modify SDP contents, break SIP message integrity, provide low quality voice & video (relay...). Last point but not the least, is there any existing way to make sure you can provide inter-domain SIP calls? (2 RTP relays are inserted in the path or a proxy fix a contact header to the IP/port source of the previous proxy...)
I want ICE to be implemented, no matter the effort. Else, I think there is no value in SIP or VoIP except for commercial usage.
Please help the world and vote for ICE whatever the effort. If not, join the IMS effort to make millions of $ for the next decades. That's a choice! (no flame to anyone here, don't misunderstood me... I just feel sad)
MAIL was a success & free probably because correct deployment is easy. With ICE, SIP could become the same.
I'm done! Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
-- juha
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hello,
On 01/02/09 21:02, MagoDaViola wrote:
Hello all ....
I'm having a problem with our server or customers. Most of our clients access the server using the combination ATA and ADSL Modem, but when the ADSL drops and returns in a few minutes, the ATA can no longer make the register on SIP server. Sometimes passing through the modem or the requests of the ATA. I identified that this happens a lot with the D-Link modems DSL-500B and siemens SpeedStream 4200. If someone went through this I would your help ...
you have to troubleshoot what happens inside the home network, one solution is to plug the ata and a computer in a hub and grab the sip traffic. Check if the ata is sending registration and if the server gets it.
Also, set the expiration time to something low, like 5 minutes, so if the address of the dsl router changes, the ata won't be much time offline.
Cheers, Daniel
-
Aymeric Moizard -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Jiri Kuthan -
Juan Asencio -
Klaus Darilion -
MagoDaViola -
Victor Pascual Ávila