Attila Sipos wrote: >>> 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> >>> > > Ooops... yeah you're right ;-)
> >>> 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. > > Are you saying it should follow the Route Set regardless of where it sent the INVITE ? Doesn't this contradict the quote from RFC 3261 i've pasted below where it states that ACK MUST be sent to the same transport, address and port where the original request was sent? > 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: >>> >>> >>> >>> 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
