2 Mar
2005
2 Mar
'05
7:38 p.m.
I'm new to this mailing list. This seems like an interesting question,
so thought would put my 2 cents in:
It seems like this is incorrect behavior on SER's part. SER is entitled
to maintain the public IP addresses for the Contact in it's location
service. But, the 200 OK that goes out on the wire to the end-point
should contain the same Contact IP addresses that came in the REGISTER.
_____
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Vitaly Nikolaev
Sent: Wednesday, March 02, 2005 1:25 PM
To: 'Linda Xiao'; 'Java Rockx'
Cc: serusers(a)lists.iptel.org
Subject: RE: [Serusers] Claims of ser-0.9 RFC3261 Violation
I do not agree... Contact should be same in the dialog...
_____
From: serusers-bounces(a)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(a)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(a)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(a)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:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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:
expiration
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 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(a)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(a)iptel.org [mailto:serusers-bounces@lists.iptel.org]
>On Behalf Of Java Rockx
>Sent: Wednesday, March 02, 2005 11:17 AM
>To: serusers(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
8 Mar
8 Mar
2:36 p.m.
New subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
If you use fix_nated_register then ser would never rewrite Contact in
REGISTER and associated 200 OK. It would store the IP and port of the
NAT separately in the user location databasee.
Also if SER receives an INVITE for that contact, user location lookup
will rewrite the Request-URI with the original (unmodified) Contact
value, but the message will be sent to the IP and port of the NAT.
This is the correct behavior, because it allows user agents to match the
contact they registered in 200 OK comming from the server and yet SIP
messages will make it through NATs.
Jan.
On 02-03 13:38, Jain, Rajnish wrote:
I'm new to this mailing list. This seems like an
interesting question,
so thought would put my 2 cents in:
It seems like this is incorrect behavior on SER's part. SER is entitled
to maintain the public IP addresses for the Contact in it's location
service. But, the 200 OK that goes out on the wire to the end-point
should contain the same Contact IP addresses that came in the REGISTER.
_____
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Vitaly Nikolaev
Sent: Wednesday, March 02, 2005 1:25 PM
To: 'Linda Xiao'; 'Java Rockx'
Cc: serusers(a)lists.iptel.org
Subject: RE: [Serusers] Claims of ser-0.9 RFC3261 Violation
I do not agree... Contact should be same in the dialog...
_____
From: serusers-bounces(a)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(a)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(a)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(a)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:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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:
expiration
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 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(a)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(a)iptel.org [mailto:serusers-bounces@lists.iptel.org]
>On Behalf Of Java Rockx
>Sent: Wednesday, March 02, 2005 11:17 AM
>To: serusers(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7209
days inactive
7215
days old
1 comments
2 participants
participants (2)
-
Jain, Rajnish -
Jan Janak