Hi all,
Has anyone tried to implement SER using the getting started document on onsip.org? I tried it but calling NAT users wasn't possible until I replaced fix_nated_register() with fix_nated_contact(), since otherwise, SER would store RFC1918 IP of the end user in location table.
Another issue is that when a user behind NAT tries to call someone with public IP address, only first few seconds of the conversation is heard by the caller, later on, although callee can hear the caller's voice the reverse isn't working. I'm using SER with rtpproxy again from the onsip.org site.
Thanks in advance for any help.
Dipole,
It is a violation of RFC3261 10.3 to alter the <Contact> header in a REGISTER message response. The reason is that processing REGISTER messages involves transaction matching as specified in Section 19.1.4. The SIP UA should use the contact header returned in the 200OK response for transaction matching.
fix_nated_register() will append fields to the contact header, but it will not alter the contact URI - which is the proper way to handle NATed client registrations.
You should also see in the MySQL location table that the "received" column will have the actual NATed IP (ie, the public IP) of the SIP UA while the contact column will have the actual RFC1918 URI. The recieved column is used in subsequent calls to lookup("location"). Non-NATed REGISTER messages will not have a "recieved" value in the location table.
Perhaps some call logs can help identify your problems.
Regards, Paul
On Apr 4, 2005 7:24 PM, Dipole Moment dipole.moment@gmail.com wrote:
Hi all,
Has anyone tried to implement SER using the getting started document on onsip.org? I tried it but calling NAT users wasn't possible until I replaced fix_nated_register() with fix_nated_contact(), since otherwise, SER would store RFC1918 IP of the end user in location table.
Another issue is that when a user behind NAT tries to call someone with public IP address, only first few seconds of the conversation is heard by the caller, later on, although callee can hear the caller's voice the reverse isn't working. I'm using SER with rtpproxy again from the onsip.org site.
Thanks in advance for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Dipole, Java:
Sorry, I am a newbie for sip. But I wanna know what it looks like about RFC1918's IP and RFC3261's IP? Can you give me some explains?
On Apr 5, 2005 8:19 AM, Java Rockx javarockx@gmail.com wrote:
Dipole,
It is a violation of RFC3261 10.3 to alter the <Contact> header in a REGISTER message response. The reason is that processing REGISTER messages involves transaction matching as specified in Section 19.1.4. The SIP UA should use the contact header returned in the 200OK response for transaction matching.
fix_nated_register() will append fields to the contact header, but it will not alter the contact URI - which is the proper way to handle NATed client registrations.
You should also see in the MySQL location table that the "received" column will have the actual NATed IP (ie, the public IP) of the SIP UA while the contact column will have the actual RFC1918 URI. The recieved column is used in subsequent calls to lookup("location"). Non-NATed REGISTER messages will not have a "recieved" value in the location table.
Perhaps some call logs can help identify your problems.
Regards, Paul
On Apr 4, 2005 7:24 PM, Dipole Moment dipole.moment@gmail.com wrote:
Hi all,
Has anyone tried to implement SER using the getting started document on onsip.org? I tried it but calling NAT users wasn't possible until I replaced fix_nated_register() with fix_nated_contact(), since otherwise, SER would store RFC1918 IP of the end user in location table.
Another issue is that when a user behind NAT tries to call someone with public IP address, only first few seconds of the conversation is heard by the caller, later on, although callee can hear the caller's voice the reverse isn't working. I'm using SER with rtpproxy again from the onsip.org site.
Thanks in advance for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Charles,
You can get any RFC from http://www.ietf.org/
RFC1918 specifies "private IP" addresses. RFC3261 is the most recent SIP specification. Both documents are quite long. So grab a cup of coffee and enjoy some rather dry reading.
Regards, Paul
On Apr 5, 2005 11:30 AM, Charles Wang lazy.charles@gmail.com wrote:
Dipole, Java:
Sorry, I am a newbie for sip. But I wanna know what it looks like about RFC1918's IP and RFC3261's IP? Can you give me some explains?
On Apr 5, 2005 8:19 AM, Java Rockx javarockx@gmail.com wrote:
Dipole,
It is a violation of RFC3261 10.3 to alter the <Contact> header in a REGISTER message response. The reason is that processing REGISTER messages involves transaction matching as specified in Section 19.1.4. The SIP UA should use the contact header returned in the 200OK response for transaction matching.
fix_nated_register() will append fields to the contact header, but it will not alter the contact URI - which is the proper way to handle NATed client registrations.
You should also see in the MySQL location table that the "received" column will have the actual NATed IP (ie, the public IP) of the SIP UA while the contact column will have the actual RFC1918 URI. The recieved column is used in subsequent calls to lookup("location"). Non-NATed REGISTER messages will not have a "recieved" value in the location table.
Perhaps some call logs can help identify your problems.
Regards, Paul
On Apr 4, 2005 7:24 PM, Dipole Moment dipole.moment@gmail.com wrote:
Hi all,
Has anyone tried to implement SER using the getting started document on onsip.org? I tried it but calling NAT users wasn't possible until I replaced fix_nated_register() with fix_nated_contact(), since otherwise, SER would store RFC1918 IP of the end user in location table.
Another issue is that when a user behind NAT tries to call someone with public IP address, only first few seconds of the conversation is heard by the caller, later on, although callee can hear the caller's voice the reverse isn't working. I'm using SER with rtpproxy again from the onsip.org site.
Thanks in advance for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--
Best Regards Charles
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) rfc1918
where the othe rfc deals with SIP
Iqbal
Charles Wang wrote:
Dipole, Java:
Sorry, I am a newbie for sip. But I wanna know what it looks like about RFC1918's IP and RFC3261's IP? Can you give me some explains?
On Apr 5, 2005 8:19 AM, Java Rockx javarockx@gmail.com wrote:
Dipole,
It is a violation of RFC3261 10.3 to alter the <Contact> header in a REGISTER message response. The reason is that processing REGISTER messages involves transaction matching as specified in Section 19.1.4. The SIP UA should use the contact header returned in the 200OK response for transaction matching.
fix_nated_register() will append fields to the contact header, but it will not alter the contact URI - which is the proper way to handle NATed client registrations.
You should also see in the MySQL location table that the "received" column will have the actual NATed IP (ie, the public IP) of the SIP UA while the contact column will have the actual RFC1918 URI. The recieved column is used in subsequent calls to lookup("location"). Non-NATed REGISTER messages will not have a "recieved" value in the location table.
Perhaps some call logs can help identify your problems.
Regards, Paul
On Apr 4, 2005 7:24 PM, Dipole Moment dipole.moment@gmail.com wrote:
Hi all,
Has anyone tried to implement SER using the getting started document on onsip.org? I tried it but calling NAT users wasn't possible until I replaced fix_nated_register() with fix_nated_contact(), since otherwise, SER would store RFC1918 IP of the end user in location table.
Another issue is that when a user behind NAT tries to call someone with public IP address, only first few seconds of the conversation is heard by the caller, later on, although callee can hear the caller's voice the reverse isn't working. I'm using SER with rtpproxy again from the onsip.org site.
Thanks in advance for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
You can find all RFC and (and drafts for things like diversion, rpid, etc) on http://www.ietf.org/
The SIP working group found at is http://www.ietf.org/html.charters/sip-charter.html
Regards, Paul
On Apr 5, 2005 11:44 AM, Iqbal iqbal@gigo.co.uk wrote:
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) rfc1918
where the othe rfc deals with SIP
Iqbal
Charles Wang wrote:
Dipole, Java:
Sorry, I am a newbie for sip. But I wanna know what it looks like about RFC1918's IP and RFC3261's IP? Can you give me some explains?
On Apr 5, 2005 8:19 AM, Java Rockx javarockx@gmail.com wrote:
Dipole,
It is a violation of RFC3261 10.3 to alter the <Contact> header in a REGISTER message response. The reason is that processing REGISTER messages involves transaction matching as specified in Section 19.1.4. The SIP UA should use the contact header returned in the 200OK response for transaction matching.
fix_nated_register() will append fields to the contact header, but it will not alter the contact URI - which is the proper way to handle NATed client registrations.
You should also see in the MySQL location table that the "received" column will have the actual NATed IP (ie, the public IP) of the SIP UA while the contact column will have the actual RFC1918 URI. The recieved column is used in subsequent calls to lookup("location"). Non-NATed REGISTER messages will not have a "recieved" value in the location table.
Perhaps some call logs can help identify your problems.
Regards, Paul
On Apr 4, 2005 7:24 PM, Dipole Moment dipole.moment@gmail.com wrote:
Hi all,
Has anyone tried to implement SER using the getting started document on onsip.org? I tried it but calling NAT users wasn't possible until I replaced fix_nated_register() with fix_nated_contact(), since otherwise, SER would store RFC1918 IP of the end user in location table.
Another issue is that when a user behind NAT tries to call someone with public IP address, only first few seconds of the conversation is heard by the caller, later on, although callee can hear the caller's voice the reverse isn't working. I'm using SER with rtpproxy again from the onsip.org site.
Thanks in advance for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
what I meant isntead of the mangled "
where the othe rfc deals with SIP" was
where the other rfc deals with SIP :-)
...damn keyboards
Iqbal
Java Rockx wrote:
You can find all RFC and (and drafts for things like diversion, rpid, etc) on http://www.ietf.org/
The SIP working group found at is http://www.ietf.org/html.charters/sip-charter.html
Regards, Paul
On Apr 5, 2005 11:44 AM, Iqbal iqbal@gigo.co.uk wrote:
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) rfc1918
where the othe rfc deals with SIP
Iqbal
Charles Wang wrote:
Dipole, Java:
Sorry, I am a newbie for sip. But I wanna know what it looks like about RFC1918's IP and RFC3261's IP? Can you give me some explains?
On Apr 5, 2005 8:19 AM, Java Rockx javarockx@gmail.com wrote:
Dipole,
It is a violation of RFC3261 10.3 to alter the <Contact> header in a REGISTER message response. The reason is that processing REGISTER messages involves transaction matching as specified in Section 19.1.4. The SIP UA should use the contact header returned in the 200OK response for transaction matching.
fix_nated_register() will append fields to the contact header, but it will not alter the contact URI - which is the proper way to handle NATed client registrations.
You should also see in the MySQL location table that the "received" column will have the actual NATed IP (ie, the public IP) of the SIP UA while the contact column will have the actual RFC1918 URI. The recieved column is used in subsequent calls to lookup("location"). Non-NATed REGISTER messages will not have a "recieved" value in the location table.
Perhaps some call logs can help identify your problems.
Regards, Paul
On Apr 4, 2005 7:24 PM, Dipole Moment dipole.moment@gmail.com wrote:
Hi all,
Has anyone tried to implement SER using the getting started document on onsip.org? I tried it but calling NAT users wasn't possible until I replaced fix_nated_register() with fix_nated_contact(), since otherwise, SER would store RFC1918 IP of the end user in location table.
Another issue is that when a user behind NAT tries to call someone with public IP address, only first few seconds of the conversation is heard by the caller, later on, although callee can hear the caller's voice the reverse isn't working. I'm using SER with rtpproxy again
from the onsip.org site.
Thanks in advance for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.
-
Charles Wang -
Dipole Moment -
Iqbal -
Java Rockx