>> I've also noticed that the UA did not rearrange the Route >> set in reverse order.
Yes it did. The 200 OK... >> Record-Route: <sip:63.116.xxx.xxx:9000;lr> >> Record-Route: <sip:192.168.10.102:5080;lr> The ACK... >> Route: <sip:192.168.10.102:5080;lr> >> Route: <sip:63.116.xxx.xxx:9000;lr> >> So two questions, should ACK be really sent to the contact >> address instead of 1) Send it to the to the same address, >> port, and transport to which the original request was >> sent? and 2) >> Completely ignore record routes for ACK? I believe it has formulated the ACK message correctly but it should be sent to 192.168.10.102:5080 and then (eventually) to 63.116.xxx.xxx:9000. Regards, Attila Attila Sipos http://www.vegastream.com >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] Behalf >> Of Joegen E. >> Baclor >> Sent: 23 November 2006 06:40 >> To: [email protected] >> Subject: [Sip-implementors] Proper way to send ACK? >> >> >> Hi, >> >> I am using a popular UA to test a multi homed SIP proxy >> deployment to >> bridge a private network to the open Internet. I run into >> some problems >> when X-Ten sends an ACK it receives for the 200 OK. I have >> pasted the >> SIP messages below: >> >> ++++++++++++++++++++ >> SIP/2.0 200 OK >> Via: SIP/2.0/UDP >> 192.168.232.152:12000;branch=z9hG4bK-d87543-d95b446fc3710f48- >> 1--d87543-;rport=12000;received=125.60.243.66 >> Record-Route: <sip:63.116.xxx.xxx:9000;lr> >> Record-Route: <sip:192.168.10.102:5080;lr> >> Contact: <sip:192.168.10.102:5100> >> To: ""100""<sip:[EMAIL PROTECTED]>;tag=1814262005 >> From: ""Joegen""<sip:[EMAIL PROTECTED]>;tag=b5116967 >> Call-ID: Njc2ODg3M2U1YzQ4MTU3NzdjMDI4ODgzYmEzM2RmZTg. >> CSeq: 1 INVITE >> Accept-Language: en >> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY >> Content-Type: application/sdp >> Date: Thu, 23 Nov 2006 04:30:11 GMT >> Supported: sip-cc, sip-cc-01, replaces, replaces >> User-Agent: sipX/3.6.0 sipX/vxml (Linux) >> Content-Length: 200 >> >> +++++++++++++++++++++ >> ACK sip:192.168.10.102:5100 SIP/2.0 >> Via: SIP/2.0/ >> ;branch=z9hG4bK-d87543-1974382aca77376a-1--d87543-;rport >> Max-Forwards: 70 >> Route: <sip:192.168.10.102:5080;lr> >> Route: <sip:63.116.xxx.xxx:9000;lr> >> Contact: <sip:[EMAIL PROTECTED]:12000;addTransport> >> To: ""100""<sip:[EMAIL PROTECTED]>;tag=1814262005 >> From: ""Joegen""<sip:[EMAIL PROTECTED]>;tag=b5116967 >> Call-ID: Njc2ODg3M2U1YzQ4MTU3NzdjMDI4ODgzYmEzM2RmZTg. >> CSeq: 1 ACK >> User-Agent: X-Lite release 1006e stamp 34025 >> Content-Length: 0 >> +++++++++++++++++++++ >> >> >> The problem that arises here is that the ACK gets sent to >> 192.168.10.102:5100 by-passing the SIP proxy >> (63.116.xxx.xxx:9000) that >> is suppose to bridge the signaling between the public and private >> network. Rechecking RFC 3261 I found the following: >> >> The client transaction >> MUST pass the received response up to the TU, and the client >> transaction MUST generate an ACK request, even if the >> transport is >> reliable (guidelines for constructing the ACK from >> the response are >> given in Section 17.1.1.3) and then pass the ACK to >> the transport >> layer for transmission. The ACK MUST be sent to the >> same address, >> port, and transport to which the original request was sent. >> >> I've also noticed that the UA did not rearrange the Route >> set in reverse >> order. So two questions, should ACK be really sent to the contact >> address instead of 1) Send it to the to the same address, >> port, and transport to which the original request was >> sent? and 2) >> Completely ignore record routes for ACK? >> >> Joegen >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
