<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This is exactly what I told the carrier engineer about the problem. The contact in the 200 OK is my Asterisk PBX the RURI in the ACK (returning from the carrier) is my OpenSER. I informed the carrier that according to my interpretation of the RFC 3261 the RURI in the ACK MUST match the contact in the 200 OK with SDP.<div><br></div><div>The carrier interop engineer sent me the following remark after I notified them of the issue, and began pressing them on the way their ACK was created.</div><div><div><br></div><div>== BEGIN ==</div></div><div><div>The Request URI field is used for routing of initial dialog messages. If state is not kept in [Open]SER by using the tm module, the SIP message can be routed based on the VIA or contact header, or worst case follow the same routing rules based on the original Request URIs, just like the original INVITE message did.</div><div><div>== END ==</div></div><div><br></div><div>After some subsequent communication where I again questioned the way in which their system creates the ACK. I received the below from them.</div><div><br></div><div>== BEGIN ==</div><div>All I was saying is that based on the way your system handles messages we send to it, your statement about changing the Request-URIs of ACKs based on values from the SDP of the 200 OK is not the case. I believe that some systems do however update the ACK’s Request-URI based on the Contact header field from the 200 response, but most system’s don’t route the ACK based on its Request-URI when keeping state. </div><div><br></div><div>I have another question based on our use of SER internally. When we send the initial INVITE, the Request-URI is set as the number at (@) the address of your [Open]SER proxy. SER will then re-write the request URI of the INVITE based on the logic in the local ser.cfg file and any local location/alias database entries used in that logic and forward the message to the destination, in this case the PBX, while adding a Record-Route header with LR set to ensure SER stays in the dialog in terms of signaling as well as adding a VIA header with a branch tag used to mark the dialog for stateful processing (when the TM module is used). In the case of stateful processing, these values are used to maintain the same signaling path for subsequent messages within the same dialog.</div><div> </div><div>When stateless routing is used via the SL module, all new requests (including an ACK to a 200 response) should follow the same routing logic as the initial request. Therefore, when the ACK arrives at your SER proxy, the same routing logic should be applied to the ACK as was the original INVITE, and it should be forwarded on to the correct destination. If this is not the case, then either there must be some kind of state being tracked or the logic has been written to handle ACKs differently on purpose as this would be the only way that the handling and routing (especially the computation of the final request-uri) would be different for an ACK from an INVITE.</div><div>== END ==</div></div><div><font class="Apple-style-span" color="#1F497D" face="Calibri" size="4"><span class="Apple-style-span" style="font-size: 15px;"><br></span></font></div><div>At this point I am ready to address any issue with my OpenSER configuration that can be identified, but if the problem is actually due to the ACK not being constructed correctly, I have to take off the technical hat, and put on the business hat, and try to get them to look at their systems, and push their vendors for support in this issue.</div><div><br></div><div>Thank You</div><div>Stagg Shelton</div><div><br></div><div><br></div><div><br></div><div><br></div><div>On Aug 25, 2008, at 9:52 AM, Klaus Darilion wrote:</div><div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi!<br><br>AFAIS the client is buggy (or is there a NAT ALG/Firewall between client and SIP proxy?). Compare the Contact header in the 200 OK and the request URI in the ACK. They MUST be the same!!!<br><br>regards<br>klaus<br><br><br>U +0.000315 8.17.32.184:5060 -> 63.209.207.135:5060<br>SIP/2.0 200 OK*<br>Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8921-48b022df-dcaa3e6a-2f5ec169*<br>Record-Route: <<a href="sip:8.17.32.184;lr=on;did=952.4d684275">sip:8.17.32.184;lr=on;did=952.4d684275</a>>*<br>From: Anonymous <<a href="sip:restricted@63.209.207.135">sip:restricted@63.209.207.135</a>>;tag=88cfd13f-13c4-48b022df-dcaa3e6a-b4657f0*<br>To: <<a href="sip:+16783832765@8.17.32.184:5060">sip:+16783832765@8.17.32.184:5060</a>>;tag=as40da5b97*<br>Call-ID: <a href="mailto:ATLMGC0720080823144655027771@209.244.63.15">ATLMGC0720080823144655027771@209.244.63.15</a>*<br>CSeq: 1 INVITE*<br>User-Agent: Asterisk PBX*<br>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY*<br>Supported: replaces*<br>Contact: <<a href="sip:+16783832765@8.17.32.19">sip:+16783832765@8.17.32.19</a>>*<br>Content-Type: application/sdp*<br>Content-Length: 180*<br><br><br><br>U +0.072541 63.209.207.135:5060 -> 8.17.32.184:5060<br>ACK <a href="sip:+16783832765@8.17.32.184">sip:+16783832765@8.17.32.184</a> SIP/2.0*<br>From: Anonymous <<a href="sip:restricted@63.209.207.135">sip:restricted@63.209.207.135</a>>;tag=88cfd13f-13c4-48b022df-dcaa3e6a-b4657f0*<br>To: <<a href="sip:+16783832765@8.17.32.184:5060">sip:+16783832765@8.17.32.184:5060</a>>;tag=as40da5b97*<br>Call-ID: <a href="mailto:ATLMGC0720080823144655027771@209.244.63.15">ATLMGC0720080823144655027771@209.244.63.15</a>*<br>CSeq: 1 ACK*<br>Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8922-48b022e5-dcaa5757-3884948f*<br>Max-Forwards: 15*<br>Contact: <<a href="sip:restricted@63.209.207.135:5060;transport=udp">sip:restricted@63.209.207.135:5060;transport=udp</a>>*<br>Route: <<a href="sip:8.17.32.184;lr;did=952.4d684275">sip:8.17.32.184;lr;did=952.4d684275</a>>*<br>Content-Length: 0*<br><br><br><br><br>Stagg Shelton schrieb:<br><blockquote type="cite">Thanks again Iñaki. I am attaching siptrace.txt file. I can see that there appears to be something odd with the ACKs in that they appear to be sent from my openser back to my openser in a loop until the max forwards is reached.<br></blockquote><blockquote type="cite">------------------------------------------------------------------------<br></blockquote><blockquote type="cite">Thank you for your help.<br></blockquote><blockquote type="cite">Stagg Shelton.<br></blockquote><blockquote type="cite">On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Iñaki,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thank you for your response. I have enabled the siptrace module in<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">openser. The data in the mysql table only shows the trace between the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">carrier and openser. Can I submit a pcap file that shows all of the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">SIP communication that occured during the call.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Hi, you don't need to enable siptrace. Just install "ngrep" and do:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> ngrep -d any -P '*' -W byline -T port 5060<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-- <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Iñaki Baz Castillo<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Users mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:Users@lists.kamailio.org">Users@lists.kamailio.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.kamailio.org/cgi-bin/mailman/listinfo/users">http://lists.kamailio.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></blockquote><blockquote type="cite">------------------------------------------------------------------------<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Users mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Users@lists.kamailio.org">Users@lists.kamailio.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.kamailio.org/cgi-bin/mailman/listinfo/users">http://lists.kamailio.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></div></blockquote></div><br></div></body></html>