You are not the only service provider who makes this kind of changes. I also encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally think that instead of complaining SIP proxy violation, I would rather complain the interoperatibility of this sip engine.
regards/Linda
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header.
regards, klaus
Java Rockx wrote:
It is the same. Their IAD successfully registers the first time, but loses its registration because re-REGISTER messages are claimed to be in voliation of RFC3261.
Here is exactly what their engineers are telling me:
Paul, Here is the my findings regarding the contact field in the REGISTER message...
We suspect the registration fails because the Contact of 200OK does not match the Contact of REGISTER:
From the capture, Our network toplogy is like:
TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch 64.84.242.120
Packet 4 REGISTER: Contact: sip:3212514276@192.168.0.180;user=phone;expires=200
Packet 6 200OK: Contact: sip:3212514276@65.77.37.2:36323;user=phone;expires=200, sip:3212514276@65.77.37.2:36235;user=phone;expires=3
In RFC3261, it says: The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the
expiration
time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.
So obviously the contact addresses in 200OK don't match the one in REGISTER.
On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev vitaly@voipsonic.com wrote:
Is contact field that SER sends to UAS is same for all requests ?
If not probably you are not doing fix natted contact in some cases
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, March 02, 2005 11:17 AM To: serusers@lists.iptel.org Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
I just spoke with an enginee from a manufacturer of the WorldAccxx telephone adapter and he told me that my SIP proxy was in voliation of RFC3261.
Below is a SIP registration against my ser-0.9 proxy. I'm using media proxy for NAT traversal and he says that my 200 OK is not valid and therefore their IAD disregards the 200 OK response.
The problem he claims is with the Contact: header in the 200 OK. SER has rewritten the contact becase his IAD is NATed. Should I not be doing this?
The actual problem is that when their IAD is NATed the device looses its registration with ser because (they claim) that the REGISTER message they send has a <Contact> header iwith a different IP than what ser sends back in the 200 OK message.
They referenced section 10.2.4 and 19.1.4 in RFC3261.
Can anyone confirm or reject their claims?
Please help. Paul
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .bdad From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER WWW-Authenticate: Digest realm="sip.mycompany.com", nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" Content-Length: 0
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE Authorization:Digest response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip .mycom pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:si
p.myco
mpany.com:5060" User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .5e63 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: sip:1000@65.77.37.2:36323;user=phone;expires=200, sip:1000@65.77.37.2:36235;user=phone;expires=3 Content-Length: 0
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
I do not agree... Contact should be same in the dialog.
_____
From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Linda Xiao Sent: Wednesday, March 02, 2005 1:16 PM To: Java Rockx Cc: serusers@lists.iptel.org Subject: RE: [Serusers] Claims of ser-0.9 RFC3261 Violation
You are not the only service provider who makes this kind of changes. I also encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally think that instead of complaining SIP proxy violation, I would rather complain the interoperatibility of this sip engine.
regards/Linda
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header.
regards, klaus
Java Rockx wrote:
It is the same. Their IAD successfully registers the first time, but loses its registration because re-REGISTER messages are claimed to be in voliation of RFC3261.
Here is exactly what their engineers are telling me:
Paul, Here is the my findings regarding the contact field in the REGISTER message...
We suspect the registration fails because the Contact of 200OK does not match the Contact of REGISTER:
From the capture, Our network toplogy is like:
TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch 64.84.242.120
Packet 4 REGISTER: Contact: sip:3212514276@192.168.0.180;user=phone;expires=200
Packet 6 200OK: Contact: sip:3212514276@65.77.37.2:36323;user=phone;expires=200, sip:3212514276@65.77.37.2:36235;user=phone;expires=3
In RFC3261, it says: The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.
So obviously the contact addresses in 200OK don't match the one in REGISTER.
On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev vitaly@voipsonic.com wrote:
Is contact field that SER sends to UAS is same for all requests ?
If not probably you are not doing fix natted contact in some cases
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, March 02, 2005 11:17 AM To: serusers@lists.iptel.org Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
I just spoke with an enginee from a manufacturer of the WorldAccxx telephone adapter and he told me that my SIP proxy was in voliation of RFC3261.
Below is a SIP registration against my ser-0.9 proxy. I'm using media proxy for NAT traversal and he says that my 200 OK is not valid and therefore their IAD disregards the 200 OK response.
The problem he claims is with the Contact: header in the 200 OK. SER has rewritten the contact becase his IAD is NATed. Should I not be doing this?
The actual problem is that when their IAD is NATed the device looses its registration with ser because (they claim) that the REGISTER message they send has a <Contact> header iwith a different IP than what ser sends back in the 200 OK message.
They referenced section 10.2.4 and 19.1.4 in RFC3261.
Can anyone confirm or reject their claims?
Please help. Paul
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .bdad From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER WWW-Authenticate: Digest realm="sip.mycompany.com", nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" Content-Length: 0
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE Authorization:Digest response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip .mycom pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:sip.my
co
mpany.com:5060" User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .5e63 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: sip:1000@65.77.37.2:36323;user=phone;expires=200, sip:1000@65.77.37.2:36235;user=phone;expires=3 Content-Length: 0
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
Hi All.
Thanks to Vitaly for the answer to the question. I didn't even realize there was a fix_nated_contact() function.
So for anyone else with this problem, I'm now calling force_rport() and fix_nated_contact() before save("location") when processing REGISTER messages.
I'm still using fix_nated_contact() in the reply route and before relaying INVITE messages.
Many thanks Vitaly.
Paul
On Wed, 2 Mar 2005 10:16:08 -0800, Linda Xiao linda.xiao@arkonnetworks.com wrote:
You are not the only service provider who makes this kind of changes. I also encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally think that instead of complaining SIP proxy violation, I would rather complain the interoperatibility of this sip engine.
regards/Linda
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header.
regards, klaus
Java Rockx wrote:
It is the same. Their IAD successfully registers the first time, but loses its registration because re-REGISTER messages are claimed to be in voliation of RFC3261.
Here is exactly what their engineers are telling me:
Paul, Here is the my findings regarding the contact field in the REGISTER message...
We suspect the registration fails because the Contact of 200OK does not match the Contact of REGISTER:
From the capture, Our network toplogy is like:
TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch 64.84.242.120
Packet 4 REGISTER: Contact: sip:3212514276@192.168.0.180;user=phone;expires=200
Packet 6 200OK: Contact: sip:3212514276@65.77.37.2:36323;user=phone;expires=200, sip:3212514276@65.77.37.2:36235;user=phone;expires=3
In RFC3261, it says: The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.
So obviously the contact addresses in 200OK don't match the one in REGISTER.
On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev vitaly@voipsonic.com wrote:
Is contact field that SER sends to UAS is same for all requests ?
If not probably you are not doing fix natted contact in some cases
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, March 02, 2005 11:17 AM To: serusers@lists.iptel.org Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
I just spoke with an enginee from a manufacturer of the WorldAccxx telephone adapter and he told me that my SIP proxy was in voliation of RFC3261.
Below is a SIP registration against my ser-0.9 proxy. I'm using media proxy for NAT traversal and he says that my 200 OK is not valid and therefore their IAD disregards the 200 OK response.
The problem he claims is with the Contact: header in the 200 OK. SER has rewritten the contact becase his IAD is NATed. Should I not be doing this?
The actual problem is that when their IAD is NATed the device looses its registration with ser because (they claim) that the REGISTER message they send has a <Contact> header iwith a different IP than what ser sends back in the 200 OK message.
They referenced section 10.2.4 and 19.1.4 in RFC3261.
Can anyone confirm or reject their claims?
Please help. Paul
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .bdad From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER WWW-Authenticate: Digest realm="sip.mycompany.com", nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" Content-Length: 0
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE Authorization:Digest response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip .mycom pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:sip.myco mpany.com:5060" User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .5e63 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: sip:1000@65.77.37.2:36323;user=phone;expires=200, sip:1000@65.77.37.2:36235;user=phone;expires=3 Content-Length: 0
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
Perhaps I jumped the gun here. My WorldAccxx IAD now keeps its registration updated, but now since I've called fix_nated_register() rather than fix_nated_contact() in my REGISTER message handler I cannot call phones that are NATed on different networks.
I see in the location table in MySQL that the Contact column has the value that came in with the REGISTER message and the Received column has the NATed public IP and port number.
So what is the trick to fixing NATed contacts when handling INVITE messages?
Right now I'm calling force_rport() and fix_contact() prior to lookup("location")
Regards, Paul
On Wed, 2 Mar 2005 13:44:19 -0500, Java Rockx javarockx@gmail.com wrote:
Hi All.
Thanks to Vitaly for the answer to the question. I didn't even realize there was a fix_nated_contact() function.
So for anyone else with this problem, I'm now calling force_rport() and fix_nated_contact() before save("location") when processing REGISTER messages.
I'm still using fix_nated_contact() in the reply route and before relaying INVITE messages.
Many thanks Vitaly.
Paul
On Wed, 2 Mar 2005 10:16:08 -0800, Linda Xiao linda.xiao@arkonnetworks.com wrote:
You are not the only service provider who makes this kind of changes. I also encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally think that instead of complaining SIP proxy violation, I would rather complain the interoperatibility of this sip engine.
regards/Linda
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header.
regards, klaus
Java Rockx wrote:
It is the same. Their IAD successfully registers the first time, but loses its registration because re-REGISTER messages are claimed to be in voliation of RFC3261.
Here is exactly what their engineers are telling me:
Paul, Here is the my findings regarding the contact field in the REGISTER message...
We suspect the registration fails because the Contact of 200OK does not match the Contact of REGISTER:
From the capture, Our network toplogy is like:
TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch 64.84.242.120
Packet 4 REGISTER: Contact: sip:3212514276@192.168.0.180;user=phone;expires=200
Packet 6 200OK: Contact: sip:3212514276@65.77.37.2:36323;user=phone;expires=200, sip:3212514276@65.77.37.2:36235;user=phone;expires=3
In RFC3261, it says: The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.
So obviously the contact addresses in 200OK don't match the one in REGISTER.
On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev vitaly@voipsonic.com wrote:
Is contact field that SER sends to UAS is same for all requests ?
If not probably you are not doing fix natted contact in some cases
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, March 02, 2005 11:17 AM To: serusers@lists.iptel.org Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
I just spoke with an enginee from a manufacturer of the WorldAccxx telephone adapter and he told me that my SIP proxy was in voliation of RFC3261.
Below is a SIP registration against my ser-0.9 proxy. I'm using media proxy for NAT traversal and he says that my 200 OK is not valid and therefore their IAD disregards the 200 OK response.
The problem he claims is with the Contact: header in the 200 OK. SER has rewritten the contact becase his IAD is NATed. Should I not be doing this?
The actual problem is that when their IAD is NATed the device looses its registration with ser because (they claim) that the REGISTER message they send has a <Contact> header iwith a different IP than what ser sends back in the 200 OK message.
They referenced section 10.2.4 and 19.1.4 in RFC3261.
Can anyone confirm or reject their claims?
Please help. Paul
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .bdad From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER WWW-Authenticate: Digest realm="sip.mycompany.com", nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" Content-Length: 0
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE Authorization:Digest response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip .mycom pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:sip.myco mpany.com:5060" User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .5e63 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: sip:1000@65.77.37.2:36323;user=phone;expires=200, sip:1000@65.77.37.2:36235;user=phone;expires=3 Content-Length: 0
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
Here's one more update.
I don't know why things are this way, but when I use the fix_contact() function in the mediaproxy.so module, it does not appear to properly fix the contact header.
So I changed all fix_contact() references to fix_nated_contact() from the nathelper.so module and now everything seems to work.
So what exactly does fix_contact() in mediaproxy.so do?
Regards, Paul
On Wed, 2 Mar 2005 14:01:12 -0500, Java Rockx javarockx@gmail.com wrote:
Perhaps I jumped the gun here. My WorldAccxx IAD now keeps its registration updated, but now since I've called fix_nated_register() rather than fix_nated_contact() in my REGISTER message handler I cannot call phones that are NATed on different networks.
I see in the location table in MySQL that the Contact column has the value that came in with the REGISTER message and the Received column has the NATed public IP and port number.
So what is the trick to fixing NATed contacts when handling INVITE messages?
Right now I'm calling force_rport() and fix_contact() prior to lookup("location")
Regards, Paul
On Wed, 2 Mar 2005 13:44:19 -0500, Java Rockx javarockx@gmail.com wrote:
Hi All.
Thanks to Vitaly for the answer to the question. I didn't even realize there was a fix_nated_contact() function.
So for anyone else with this problem, I'm now calling force_rport() and fix_nated_contact() before save("location") when processing REGISTER messages.
I'm still using fix_nated_contact() in the reply route and before relaying INVITE messages.
Many thanks Vitaly.
Paul
On Wed, 2 Mar 2005 10:16:08 -0800, Linda Xiao linda.xiao@arkonnetworks.com wrote:
You are not the only service provider who makes this kind of changes. I also encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally think that instead of complaining SIP proxy violation, I would rather complain the interoperatibility of this sip engine.
regards/Linda
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header.
regards, klaus
Java Rockx wrote:
It is the same. Their IAD successfully registers the first time, but loses its registration because re-REGISTER messages are claimed to be in voliation of RFC3261.
Here is exactly what their engineers are telling me:
Paul, Here is the my findings regarding the contact field in the REGISTER message...
We suspect the registration fails because the Contact of 200OK does not match the Contact of REGISTER:
From the capture, Our network toplogy is like:
TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch 64.84.242.120
Packet 4 REGISTER: Contact: sip:3212514276@192.168.0.180;user=phone;expires=200
Packet 6 200OK: Contact: sip:3212514276@65.77.37.2:36323;user=phone;expires=200, sip:3212514276@65.77.37.2:36235;user=phone;expires=3
In RFC3261, it says: The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.
So obviously the contact addresses in 200OK don't match the one in REGISTER.
On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev vitaly@voipsonic.com wrote:
Is contact field that SER sends to UAS is same for all requests ?
If not probably you are not doing fix natted contact in some cases
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, March 02, 2005 11:17 AM To: serusers@lists.iptel.org Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
I just spoke with an enginee from a manufacturer of the WorldAccxx telephone adapter and he told me that my SIP proxy was in voliation of RFC3261.
Below is a SIP registration against my ser-0.9 proxy. I'm using media proxy for NAT traversal and he says that my 200 OK is not valid and therefore their IAD disregards the 200 OK response.
The problem he claims is with the Contact: header in the 200 OK. SER has rewritten the contact becase his IAD is NATed. Should I not be doing this?
The actual problem is that when their IAD is NATed the device looses its registration with ser because (they claim) that the REGISTER message they send has a <Contact> header iwith a different IP than what ser sends back in the 200 OK message.
They referenced section 10.2.4 and 19.1.4 in RFC3261.
Can anyone confirm or reject their claims?
Please help. Paul
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .bdad From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER WWW-Authenticate: Digest realm="sip.mycompany.com", nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" Content-Length: 0
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE Authorization:Digest response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip .mycom pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:sip.myco mpany.com:5060" User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .5e63 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: sip:1000@65.77.37.2:36323;user=phone;expires=200, sip:1000@65.77.37.2:36235;user=phone;expires=3 Content-Length: 0
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
That what I do to all requests:
if (nat_uac_test("4")) { setflag(4); force_rport(); }; if (nat_uac_test("1")) { setflag(4); fix_nated_contact(); };
Then for INVITE:
t_on_reply("1");
/* Handle re-INVITEs */ if (force_rtp_proxy("l")) { t_on_reply("2"); } else { if (isflagset(4)) if (force_rtp_proxy("")) t_on_reply("2"); };
And
onreply_route[1] { if (!(status=~"183" || status=~"200")) break; if (nat_uac_test("1")) fix_nated_contact(); if (nat_uac_test("8")) fix_nated_sdp("3"); }
onreply_route[2] { if (!(status=~"183" || status=~"200")) break; if (nat_uac_test("1")) fix_nated_contact(); force_rtp_proxy(""); }
Never used it with mediaproxy
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, March 02, 2005 2:01 PM To: serusers@lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
Perhaps I jumped the gun here. My WorldAccxx IAD now keeps its registration updated, but now since I've called fix_nated_register() rather than fix_nated_contact() in my REGISTER message handler I cannot call phones that are NATed on different networks.
I see in the location table in MySQL that the Contact column has the value that came in with the REGISTER message and the Received column has the NATed public IP and port number.
So what is the trick to fixing NATed contacts when handling INVITE messages?
Right now I'm calling force_rport() and fix_contact() prior to lookup("location")
Regards, Paul
On Wed, 2 Mar 2005 13:44:19 -0500, Java Rockx javarockx@gmail.com wrote:
Hi All.
Thanks to Vitaly for the answer to the question. I didn't even realize there was a fix_nated_contact() function.
So for anyone else with this problem, I'm now calling force_rport() and fix_nated_contact() before save("location") when processing REGISTER messages.
I'm still using fix_nated_contact() in the reply route and before relaying INVITE messages.
Many thanks Vitaly.
Paul
On Wed, 2 Mar 2005 10:16:08 -0800, Linda Xiao linda.xiao@arkonnetworks.com wrote:
You are not the only service provider who makes this kind of changes. I
also
encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally
think
that instead of complaining SIP proxy violation, I would rather complain
the
interoperatibility of this sip engine.
regards/Linda
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header.
regards, klaus
Java Rockx wrote:
It is the same. Their IAD successfully registers the first time, but loses its registration because re-REGISTER messages are claimed to be in voliation of RFC3261.
Here is exactly what their engineers are telling me:
Paul, Here is the my findings regarding the contact field in the REGISTER message...
We suspect the registration fails because the Contact of 200OK does not match the Contact of REGISTER:
From the capture, Our network toplogy is like:
TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch 64.84.242.120
Packet 4 REGISTER: Contact: sip:3212514276@192.168.0.180;user=phone;expires=200
Packet 6 200OK: Contact: sip:3212514276@65.77.37.2:36323;user=phone;expires=200, sip:3212514276@65.77.37.2:36235;user=phone;expires=3
In RFC3261, it says: The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the
expiration
time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.
So obviously the contact addresses in 200OK don't match the one in REGISTER.
On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev vitaly@voipsonic.com wrote:
Is contact field that SER sends to UAS is same for all requests ?
If not probably you are not doing fix natted contact in some cases
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, March 02, 2005 11:17 AM To: serusers@lists.iptel.org Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
I just spoke with an enginee from a manufacturer of the WorldAccxx telephone adapter and he told me that my SIP proxy was in voliation of RFC3261.
Below is a SIP registration against my ser-0.9 proxy. I'm using media proxy for NAT traversal and he says that my 200 OK is not valid and therefore their IAD disregards the 200 OK response.
The problem he claims is with the Contact: header in the 200 OK. SER has rewritten the contact becase his IAD is NATed. Should I not be doing this?
The actual problem is that when their IAD is NATed the device looses its registration with ser because (they claim) that the REGISTER message they send has a <Contact> header iwith a different IP than what ser sends back in the 200 OK message.
They referenced section 10.2.4 and 19.1.4 in RFC3261.
Can anyone confirm or reject their claims?
Please help. Paul
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .bdad From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER WWW-Authenticate: Digest realm="sip.mycompany.com", nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" Content-Length: 0
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE Authorization:Digest response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip .mycom
pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:sip.my
co
mpany.com:5060" User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .5e63 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: sip:1000@65.77.37.2:36323;user=phone;expires=200, sip:1000@65.77.37.2:36235;user=phone;expires=3 Content-Length: 0
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
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 02-03 14:01, Java Rockx wrote:
Perhaps I jumped the gun here. My WorldAccxx IAD now keeps its registration updated, but now since I've called fix_nated_register() rather than fix_nated_contact() in my REGISTER message handler I cannot call phones that are NATed on different networks.
I see in the location table in MySQL that the Contact column has the value that came in with the REGISTER message and the Received column has the NATed public IP and port number.
So what is the trick to fixing NATed contacts when handling INVITE messages?
The trick is that SER will put the original (unmodified) contact into the Request-URI, but will forward to the request to the IP and port in received column (in the case the hostname in the request-uri will not match the real destination of the packet).
Right now I'm calling force_rport() and fix_contact() prior to lookup("location")
Even if you call fix_nated_register for contacts, you still need to call fix_nated_contact for INVITE and other messages, because you need to rewrite the Contact in INVITE messages as well to make sure that subsequent messages within the dialog created by the INVITE will make it through the NAT. SER does not use the user location database when forwarding BYE and thus it has no way of knowing that it should forward the request to the public IP of the NAT, unless this information is stored in the contact.
Jan.
Regards, Paul
On Wed, 2 Mar 2005 13:44:19 -0500, Java Rockx javarockx@gmail.com wrote:
Hi All.
Thanks to Vitaly for the answer to the question. I didn't even realize there was a fix_nated_contact() function.
So for anyone else with this problem, I'm now calling force_rport() and fix_nated_contact() before save("location") when processing REGISTER messages.
I'm still using fix_nated_contact() in the reply route and before relaying INVITE messages.
Many thanks Vitaly.
Paul
On Wed, 2 Mar 2005 10:16:08 -0800, Linda Xiao linda.xiao@arkonnetworks.com wrote:
You are not the only service provider who makes this kind of changes. I also encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally think that instead of complaining SIP proxy violation, I would rather complain the interoperatibility of this sip engine.
regards/Linda
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header.
regards, klaus
Java Rockx wrote:
It is the same. Their IAD successfully registers the first time, but loses its registration because re-REGISTER messages are claimed to be in voliation of RFC3261.
Here is exactly what their engineers are telling me:
Paul, Here is the my findings regarding the contact field in the REGISTER message...
We suspect the registration fails because the Contact of 200OK does not match the Contact of REGISTER:
From the capture, Our network toplogy is like:
TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch 64.84.242.120
Packet 4 REGISTER: Contact: sip:3212514276@192.168.0.180;user=phone;expires=200
Packet 6 200OK: Contact: sip:3212514276@65.77.37.2:36323;user=phone;expires=200, sip:3212514276@65.77.37.2:36235;user=phone;expires=3
In RFC3261, it says: The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.
So obviously the contact addresses in 200OK don't match the one in REGISTER.
On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev vitaly@voipsonic.com wrote:
Is contact field that SER sends to UAS is same for all requests ?
If not probably you are not doing fix natted contact in some cases
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, March 02, 2005 11:17 AM To: serusers@lists.iptel.org Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
I just spoke with an enginee from a manufacturer of the WorldAccxx telephone adapter and he told me that my SIP proxy was in voliation of RFC3261.
Below is a SIP registration against my ser-0.9 proxy. I'm using media proxy for NAT traversal and he says that my 200 OK is not valid and therefore their IAD disregards the 200 OK response.
The problem he claims is with the Contact: header in the 200 OK. SER has rewritten the contact becase his IAD is NATed. Should I not be doing this?
The actual problem is that when their IAD is NATed the device looses its registration with ser because (they claim) that the REGISTER message they send has a <Contact> header iwith a different IP than what ser sends back in the 200 OK message.
They referenced section 10.2.4 and 19.1.4 in RFC3261.
Can anyone confirm or reject their claims?
Please help. Paul
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .bdad From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547129 REGISTER WWW-Authenticate: Digest realm="sip.mycompany.com", nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" Content-Length: 0
REGISTER sip:sip.mycompany.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 Max-Forwards: 70 Content-Length: 0 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: Accxx sip:1000@192.168.0.180;user=phone;expires=200 Allow: NOTIFY Allow: REFER Allow: OPTIONS Allow: INVITE Allow: ACK Allow: CANCEL Allow: BYE Authorization:Digest response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip .mycom pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:sip.myco mpany.com:5060" User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 To: Accxx sip:1000@sip.mycompany.com:5060;tag=bf952ed189d8425c881b09485aa0b6f1 .5e63 From: Accxx sip:1000@sip.mycompany.com:5060;tag=1eb7db0b344ac92 Call-ID: bd4da0ebfe98297597243a92b1b0f868@192.168.0.180 CSeq: 392547130 REGISTER Contact: sip:1000@65.77.37.2:36323;user=phone;expires=200, sip:1000@65.77.37.2:36235;user=phone;expires=3 Content-Length: 0
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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Jan Janak -
Java Rockx -
Linda Xiao -
Vitaly Nikolaev