Hi
I have been using fix_nated_register/fix_nated_contact for NAT traversal and all worked fine. I've come across add_contact_alias and handle_ruri_alias: http://sip-router.org/wiki/tutorials/alias-example where it says:
"The benefits of using add_contact_alias() and handle_ruri_alias() functions instead of conventional NAT traversal solutions are:
* Request-URI in requests to UAs behind NATs is always what UAs expect * Re-use of tcp/tls sessions between proxy and UAs
" I assumed the 'conventional NAT traversal solution' here means fix_nated_contact?
I understand the first point, in that the R-URI always contains what the client puts in the contact hf.
But for the second point, about tcp/tls reuse, does fix_nated_contact do the same trick, or does add_contact_alias and handle_ruri_alias give you more benefit over fix_nated_contact? So far I feel they achieve the same thing but would like this confirmed/corrected.
Thank you very much!
Yufei
On 16.03.2012 17:14, yufei.tao wrote:
Hi
I have been using fix_nated_register/fix_nated_contact for NAT traversal and all worked fine. I've come across add_contact_alias and handle_ruri_alias: http://sip-router.org/wiki/tutorials/alias-example where it says:
"The benefits of using add_contact_alias() and handle_ruri_alias() functions instead of conventional NAT traversal solutions are:
- Request-URI in requests to UAs behind NATs is always what UAs expect
- Re-use of tcp/tls sessions between proxy and UAs
" I assumed the 'conventional NAT traversal solution' here means fix_nated_contact?
yes
I understand the first point, in that the R-URI always contains what the client puts in the contact hf.
yes
But for the second point, about tcp/tls reuse, does fix_nated_contact do the same trick, or does add_contact_alias and handle_ruri_alias give you more benefit over fix_nated_contact? So far I feel they achieve the same thing but would like this confirmed/corrected.
They achieve both the same. I don't remember the problems anymore which caused add_contact_alias() to be implemented. IIRC I think it was that some clients did not put "transport=tcp" into the Contact header and thus the fix_anted_contact missed the transport - add_contact_alias always adds the transport protocol. But that is just a guess, I may be wrong.
klaus
Klaus Darilion writes:
They achieve both the same. I don't remember the problems anymore which caused add_contact_alias() to be implemented. IIRC I think it was that some clients did not put "transport=tcp" into the Contact header and thus the fix_anted_contact missed the transport - add_contact_alias always adds the transport protocol. But that is just a guess, I may be wrong.
the main reason why i implemented those two functions was to assure that request uri in in-dialog requests is always correct. regarding tcp connection reuse, i don't remember why i wrote about that in the tutorial. perhaps i was just mislead by the name of fix_nated_contact() function that is incorrect. i just checked and the function has nothing to do with nated contacts.
-- juha
Hi
Thanks very much for the replies! I'm clear now :)
Yufei
On 17/03/12 10:56, Juha Heinanen wrote:
Klaus Darilion writes:
They achieve both the same. I don't remember the problems anymore which caused add_contact_alias() to be implemented. IIRC I think it was that some clients did not put "transport=tcp" into the Contact header and thus the fix_anted_contact missed the transport - add_contact_alias always adds the transport protocol. But that is just a guess, I may be wrong.
the main reason why i implemented those two functions was to assure that request uri in in-dialog requests is always correct. regarding tcp connection reuse, i don't remember why i wrote about that in the tutorial. perhaps i was just mislead by the name of fix_nated_contact() function that is incorrect. i just checked and the function has nothing to do with nated contacts.
-- juha
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
-
Juha Heinanen -
Klaus Darilion -
Yufei Tao -
yufei.tao