>> 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
