<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1458" name=GENERATOR></HEAD>
<BODY>
<DIV><!-- Converted from text/plain format --><STRONG><EM><FONT 
face="Century Gothic" color=#0000ff size=2>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&nbsp;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&nbsp;complain the interoperatibility of this sip engine. 
</FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face="Century Gothic" color=#0000ff 
size=2></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face="Century Gothic" color=#0000ff 
size=2>regards/Linda</FONT></EM></STRONG></DIV>
<DIV><BR><BR></DIV>
<P><FONT size=2>-----Original Message-----<BR>From: serusers-bounces@lists.iptel.org 
[<A 
href="mailto:serusers-bounces@lists.iptel.org">mailto:serusers-bounces@iptel.org</A>] 
On Behalf Of Klaus Darilion<BR>Sent: Wednesday, March 02, 2005 9:37 AM<BR>To: 
Java Rockx<BR>Cc: serusers@lists.iptel.org<BR>Subject: Re: [Serusers] Claims of 
ser-0.9 RFC3261 Violation<BR><BR><BR>I guess the engineer is right. Thus, I use 
fix_nated_register() instead<BR>of fix_nated_contact which does not rewrite the 
contact header.<BR><BR>regards,<BR>klaus<BR><BR><BR>Java Rockx 
wrote:<BR><BR>&gt; It is the same. Their IAD successfully registers the first 
time, but<BR>&gt; loses its registration because re-REGISTER messages are 
claimed to be<BR>&gt; in voliation of RFC3261.<BR>&gt;<BR>&gt; Here is exactly 
what their engineers are telling me:<BR>&gt;<BR>&gt;<BR>&gt; 
Paul,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Here is the my findings regarding the 
contact field in the<BR>&gt; REGISTER message...<BR>&gt;<BR>&gt; We suspect the 
registration fails because the Contact of 200OK does<BR>&gt; not match the 
Contact of REGISTER:<BR>&gt;<BR>&gt;&gt;From the capture, Our network toplogy is 
like:<BR>&gt; TA: 192.168.0.180 &lt;--------&gt; Router 65.77.37.2 
&lt;----------&gt; Softswitch<BR>&gt; 64.84.242.120<BR>&gt;<BR>&gt; Packet 4 
REGISTER:<BR>&gt; Contact: 
&lt;sip:3212514276@192.168.0.180;user=phone&gt;;expires=200<BR>&gt;<BR>&gt; 
Packet 6 200OK:<BR>&gt; Contact: 
&lt;sip:3212514276@65.77.37.2:36323;user=phone&gt;;expires=200,<BR>&gt; 
&lt;sip:3212514276@65.77.37.2:36235;user=phone&gt;;expires=3<BR>&gt;<BR>&gt; In 
RFC3261, it says:<BR>&gt;&nbsp;&nbsp;&nbsp; The 200 (OK) response from the 
registrar contains a list of Contact<BR>&gt;&nbsp;&nbsp;&nbsp; fields 
enumerating all current bindings. The UA compares each<BR>&gt;&nbsp;&nbsp;&nbsp; 
contact address to see if it created the contact address, 
using<BR>&gt;&nbsp;&nbsp;&nbsp; comparison rules in Section 19.1.4. If so, it 
updates the expiration<BR>&gt;&nbsp;&nbsp;&nbsp; time interval according to the 
expires parameter or, if absent, the<BR>&gt;&nbsp;&nbsp;&nbsp; Expires field 
value. The UA then issues a REGISTER request for each<BR>&gt;&nbsp;&nbsp;&nbsp; 
of its bindings before the expiration interval has elapsed. It 
MAY<BR>&gt;&nbsp;&nbsp;&nbsp; combine several updates into one REGISTER 
request.<BR>&gt;<BR>&gt; So obviously the contact addresses in 200OK don't match 
the one in<BR>&gt; REGISTER.<BR>&gt;<BR>&gt;<BR>&gt; On Wed, 2 Mar 2005 11:28:51 
-0500, Vitaly Nikolaev<BR>&gt; &lt;vitaly@voipsonic.com&gt; 
wrote:<BR>&gt;<BR>&gt;&gt;Is contact field that SER sends to UAS is same for all 
requests ?<BR>&gt;&gt;<BR>&gt;&gt;If not probably you are not doing fix natted 
contact in some cases<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;-----Original 
Message-----<BR>&gt;&gt;From: serusers-bounces@lists.iptel.org [<A 
href="mailto:serusers-bounces@lists.iptel.org">mailto:serusers-bounces@iptel.org</A>]<BR>&gt;&gt;On 
Behalf Of Java Rockx<BR>&gt;&gt;Sent: Wednesday, March 02, 2005 11:17 
AM<BR>&gt;&gt;To: serusers@lists.iptel.org<BR>&gt;&gt;Subject: [Serusers] Claims of 
ser-0.9 RFC3261 Violation<BR>&gt;&gt;<BR>&gt;&gt;I just spoke with an enginee 
from a manufacturer of the WorldAccxx<BR>&gt;&gt;telephone adapter and he told 
me that my SIP proxy was in voliation 
of<BR>&gt;&gt;RFC3261.<BR>&gt;&gt;<BR>&gt;&gt;Below is a SIP registration 
against my ser-0.9 proxy. I'm using media<BR>&gt;&gt;proxy for NAT traversal and 
he says that my 200 OK is not valid and<BR>&gt;&gt;therefore their IAD 
disregards the 200 OK response.<BR>&gt;&gt;<BR>&gt;&gt;The problem he claims is 
with the &lt;Contact:&gt; header in the 200 OK. SER<BR>&gt;&gt;has rewritten the 
contact becase his IAD is NATed. Should I not be<BR>&gt;&gt;doing 
this?<BR>&gt;&gt;<BR>&gt;&gt;The actual problem is that when their IAD is NATed 
the device looses<BR>&gt;&gt;its registration with ser because (they claim) that 
the REGISTER<BR>&gt;&gt;message they send has a &lt;Contact&gt; header iwith a 
different IP than<BR>&gt;&gt;what ser sends back in the 200 OK 
message.<BR>&gt;&gt;<BR>&gt;&gt;They referenced section 10.2.4 and 19.1.4 in 
RFC3261.<BR>&gt;&gt;<BR>&gt;&gt;Can anyone confirm or reject their 
claims?<BR>&gt;&gt;<BR>&gt;&gt;Please 
help.<BR>&gt;&gt;Paul<BR>&gt;&gt;<BR>&gt;&gt;REGISTER sip:sip.mycompany.com:5060 
SIP/2.0<BR>&gt;&gt;Via: SIP/2.0/UDP 
192.168.0.180;branch=z9hG4bKbb013e10d<BR>&gt;&gt;Max-Forwards: 
70<BR>&gt;&gt;Content-Length: 0<BR>&gt;&gt;To: Accxx 
&lt;sip:1000@sip.mycompany.com:5060&gt;<BR>&gt;&gt;From: Accxx 
&lt;sip:1000@sip.mycompany.com:5060&gt;;tag=1eb7db0b344ac92<BR>&gt;&gt;Call-ID: 
bd4da0ebfe98297597243a92b1b0f868@192.168.0.180<BR>&gt;&gt;CSeq: 392547129 
REGISTER<BR>&gt;&gt;Contact: Accxx 
&lt;sip:1000@192.168.0.180;user=phone&gt;;expires=200<BR>&gt;&gt;Allow: 
NOTIFY<BR>&gt;&gt;Allow: REFER<BR>&gt;&gt;Allow: OPTIONS<BR>&gt;&gt;Allow: 
INVITE<BR>&gt;&gt;Allow: ACK<BR>&gt;&gt;Allow: CANCEL<BR>&gt;&gt;Allow: 
BYE<BR>&gt;&gt;User-Agent: WATA200 Callctrl/1.5.1.1 
MxSF/v3.2.6.26<BR>&gt;&gt;<BR>&gt;&gt;SIP/2.0 100 Trying<BR>&gt;&gt;Via: 
SIP/2.0/UDP<BR>&gt;&gt;192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2<BR>&gt;&gt;To: 
Accxx &lt;sip:1000@sip.mycompany.com:5060&gt;<BR>&gt;&gt;From: Accxx 
&lt;sip:1000@sip.mycompany.com:5060&gt;;tag=1eb7db0b344ac92<BR>&gt;&gt;Call-ID: 
bd4da0ebfe98297597243a92b1b0f868@192.168.0.180<BR>&gt;&gt;CSeq: 392547129 
REGISTER<BR>&gt;&gt;Content-Length: 0<BR>&gt;&gt;<BR>&gt;&gt;SIP/2.0 401 
Unauthorized<BR>&gt;&gt;Via: 
SIP/2.0/UDP<BR>&gt;&gt;192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2<BR>&gt;&gt;To: 
Accxx<BR>&gt;&gt;&lt;sip:1000@sip.mycompany.com:5060&gt;;tag=bf952ed189d8425c881b09485aa0b6f1<BR>&gt;&gt;.bdad<BR>&gt;&gt;From: 
Accxx 
&lt;sip:1000@sip.mycompany.com:5060&gt;;tag=1eb7db0b344ac92<BR>&gt;&gt;Call-ID: 
bd4da0ebfe98297597243a92b1b0f868@192.168.0.180<BR>&gt;&gt;CSeq: 392547129 
REGISTER<BR>&gt;&gt;WWW-Authenticate: Digest 
realm="sip.mycompany.com",<BR>&gt;&gt;nonce="42025161902f6f6af11f01f0a93ad2877e606bbc"<BR>&gt;&gt;Content-Length: 
0<BR>&gt;&gt;<BR>&gt;&gt;REGISTER sip:sip.mycompany.com:5060 
SIP/2.0<BR>&gt;&gt;Via: SIP/2.0/UDP 
192.168.0.180;branch=z9hG4bK88fcb4e76<BR>&gt;&gt;Max-Forwards: 
70<BR>&gt;&gt;Content-Length: 0<BR>&gt;&gt;To: Accxx 
&lt;sip:1000@sip.mycompany.com:5060&gt;<BR>&gt;&gt;From: Accxx 
&lt;sip:1000@sip.mycompany.com:5060&gt;;tag=1eb7db0b344ac92<BR>&gt;&gt;Call-ID: 
bd4da0ebfe98297597243a92b1b0f868@192.168.0.180<BR>&gt;&gt;CSeq: 392547130 
REGISTER<BR>&gt;&gt;Contact: Accxx 
&lt;sip:1000@192.168.0.180;user=phone&gt;;expires=200<BR>&gt;&gt;Allow: 
NOTIFY<BR>&gt;&gt;Allow: REFER<BR>&gt;&gt;Allow: OPTIONS<BR>&gt;&gt;Allow: 
INVITE<BR>&gt;&gt;Allow: ACK<BR>&gt;&gt;Allow: CANCEL<BR>&gt;&gt;Allow: 
BYE<BR>&gt;&gt;Authorization:Digest<BR>&gt;&gt;response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip<BR>&gt;&gt;.mycom<BR>&gt;&gt;pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:sip.myco<BR>&gt;&gt;mpany.com:5060"<BR>&gt;&gt;User-Agent: 
WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26<BR>&gt;&gt;<BR>&gt;&gt;SIP/2.0 100 
Trying<BR>&gt;&gt;Via: 
SIP/2.0/UDP<BR>&gt;&gt;192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2<BR>&gt;&gt;To: 
Accxx &lt;sip:1000@sip.mycompany.com:5060&gt;<BR>&gt;&gt;From: Accxx 
&lt;sip:1000@sip.mycompany.com:5060&gt;;tag=1eb7db0b344ac92<BR>&gt;&gt;Call-ID: 
bd4da0ebfe98297597243a92b1b0f868@192.168.0.180<BR>&gt;&gt;CSeq: 392547130 
REGISTER<BR>&gt;&gt;Content-Length: 0<BR>&gt;&gt;<BR>&gt;&gt;SIP/2.0 200 
OK<BR>&gt;&gt;Via: 
SIP/2.0/UDP<BR>&gt;&gt;192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2<BR>&gt;&gt;To: 
Accxx<BR>&gt;&gt;&lt;sip:1000@sip.mycompany.com:5060&gt;;tag=bf952ed189d8425c881b09485aa0b6f1<BR>&gt;&gt;.5e63<BR>&gt;&gt;From: 
Accxx 
&lt;sip:1000@sip.mycompany.com:5060&gt;;tag=1eb7db0b344ac92<BR>&gt;&gt;Call-ID: 
bd4da0ebfe98297597243a92b1b0f868@192.168.0.180<BR>&gt;&gt;CSeq: 392547130 
REGISTER<BR>&gt;&gt;Contact: 
&lt;sip:1000@65.77.37.2:36323;user=phone&gt;;expires=200,<BR>&gt;&gt;&lt;sip:1000@65.77.37.2:36235;user=phone&gt;;expires=3<BR>&gt;&gt;Content-Length: 
0<BR>&gt;&gt;<BR>&gt;&gt;_______________________________________________<BR>&gt;&gt;Serusers 
mailing list<BR>&gt;&gt;serusers@lists.iptel.org <A 
href="http://lists.iptel.org/mailman/listinfo/serusers">http://mail.iptel.org/mailman/listinfo/serusers</A><BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;<BR>&gt;<BR>&gt; 
_______________________________________________<BR>&gt; Serusers mailing 
list<BR>&gt; serusers@lists.iptel.org <A 
href="http://lists.iptel.org/mailman/listinfo/serusers">http://mail.iptel.org/mailman/listinfo/serusers</A><BR>&gt;<BR>&gt;<BR><BR>_______________________________________________<BR>Serusers 
mailing list<BR>serusers@lists.iptel.org <A 
href="http://lists.iptel.org/mailman/listinfo/serusers">http://mail.iptel.org/mailman/listinfo/serusers</A><BR></FONT></P></BODY></HTML>