Pretty clear now... thanks a lot!
Attila Sipos wrote: >>> 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? >>> > > If you look in RFC3261 "4 Overview of Operation", the ACK is not > always sent to the same transprot, IP and port as the original > INVITE... > In this > example, the ACK is sent directly from Alice's softphone to Bob's SIP > phone, bypassing the two proxies. This occurs because the endpoints > have learned each other's address from the Contact header fields > through the INVITE/200 (OK) exchange, which was not known when the > initial INVITE was sent. > > > The bit you pasted from RFC3261 is true > but it does NOT apply to 2xx responses. > > from RFC3261... > For final responses between 300 and > 699, the ACK processing is done in the transaction layer and follows > one set of rules (See Section 17). For 2xx responses, the ACK is > generated by the UAC core. > > So in section 17 (17.1.1.2 Formal Description), it says: > > When in either the "Calling" or "Proceeding" states, reception of a > response with status code from 300-699 MUST cause the client > transaction to transition to "Completed". 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 > > So, it only applies to 300-699 responses. > > Regards, > > Attila > > > >>> -----Original Message----- >>> From: Joegen E. Baclor [mailto:[EMAIL PROTECTED] >>> Sent: 23 November 2006 09:39 >>> To: Attila Sipos >>> Cc: [email protected] >>> Subject: Re: [Sip-implementors] Proper way to send ACK? >>> >>> >>> 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
