Re: [Kamailio-Users] Having Problem routing an ACK

As Iñaki said .... and one more - the is no difference if the routing in the SIP proxy is done stateless or stateful. regards klaus Stagg Shelton wrote: > 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. > 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. > == BEGIN == > 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. > == END == > After some subsequent communication where I again questioned the > way in which their system creates the ACK. I received the below > from them. > == BEGIN == > 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. 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. > 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. > == END == > 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. > Thank You > Stagg Shelton > On Aug 25, 2008, at 9:52 AM, Klaus Darilion wrote: >> Hi! >> >> 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!!! >> >> regards >> klaus >> >> >> U +0.000315 8.17.32.184:5060 -> 63.209.207.135:5060 >> SIP/2.0 200 OK* >> Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8921-48b022df- >> dcaa3e6a-2f5ec169* >> Record-Route: <sip:8.17.32.184;lr=on;did=952.4d684275>* >> From: Anonymous >> <sip:restricted@63.209.207.135>;tag=88cfd13f-13c4-48b022df- >> dcaa3e6a-b4657f0* >> To: <sip:+16783832765@8.17.32.184:5060>;tag=as40da5b97* >> Call-ID: ATLMGC0720080823144655027771(a)209.244.63.15 <mailto:ATLMGC0720080823144655027771@209.244.63.15 >>> * >> CSeq: 1 INVITE* >> User-Agent: Asterisk PBX* >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY* >> Supported: replaces* >> Contact: <sip:+16783832765@8.17.32.19>* >> Content-Type: application/sdp* >> Content-Length: 180* >> >> >> >> U +0.072541 63.209.207.135:5060 -> 8.17.32.184:5060 >> ACK sip:+16783832765@8.17.32.184 SIP/2.0* >> From: Anonymous >> <sip:restricted@63.209.207.135>;tag=88cfd13f-13c4-48b022df- >> dcaa3e6a-b4657f0* >> To: <sip:+16783832765@8.17.32.184:5060>;tag=as40da5b97* >> Call-ID: ATLMGC0720080823144655027771(a)209.244.63.15 <mailto:ATLMGC0720080823144655027771@209.244.63.15 >>> * >> CSeq: 1 ACK* >> Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-8922-48b022e5- >> dcaa5757-3884948f* >> Max-Forwards: 15* >> Contact: <sip:restricted@63.209.207.135:5060;transport=udp>* >> Route: <sip:8.17.32.184;lr;did=952.4d684275>* >> Content-Length: 0* >> >> >> >> >> Stagg Shelton schrieb: >>> 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. >>> ------------------------------------------------------------------------ >>> Thank you for your help. >>> Stagg Shelton. >>> On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote: >>>> El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió: >>>>> Iñaki, >>>>> >>>>> Thank you for your response. I have enabled the siptrace >>>>> module in >>>>> openser. The data in the mysql table only shows the trace >>>>> between the >>>>> carrier and openser. Can I submit a pcap file that shows all >>>>> of the >>>>> SIP communication that occured during the call. >>>> Hi, you don't need to enable siptrace. Just install "ngrep" and >>>> do: >>>> >>>> ngrep -d any -P '*' -W byline -T port 5060 >>>> >>>> >>>> -- >>>> Iñaki Baz Castillo >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)lists.kamailio.org <mailto:Users@lists.kamailio.org> >>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.kamailio.org <mailto:Users@lists.kamailio.org> >>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > ------------------------------------------------------------------------ > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users