Subject: [Sip] Question on RFC 3263

From: Sanjay Sinha <[email-masked]>
Date: Mon, 28 Apr 2003 18:09:37 -0400

Hi,

Please refer to the following statement in Sec. 4.2 of RFC 3263.

<snip>

If the TARGET was not a numeric IP address, but a port is present in
the URI, the client performs an A or AAAA record lookup of the domain
name.  The result will be a list of IP addresses, each of which can
be contacted at the specific port from the URI and transport protocol
determined previously.  The client SHOULD try the first record.  If
an attempt should fail, based on the definition of failure in Section
4.3, the next SHOULD be tried, and if that should fail, the next
SHOULD be tried, and so on.

Definition of failure according to Sec. 4.3 is:

For SIP requests, failure occurs if the transaction layer reports a
503 error response or a transport failure of some sort (generally,
due to fatal ICMP errors in UDP or connection failures in TCP).
Failure also occurs if the transaction layer times out without ever
having received any response, provisional or final (i.e., timer B or
timer F in RFC 3261 [1] fires).

I have following questions:

1) Since ACK for 200 response indicates a new transaction and follows 
rules of sec. 4.2 to find out the ip address of next hop element to send 
ACK to, how does the client transaction detect failure for ACK and move 
to next record in the list if used with UDP and the next hop does not 
generate transport errors.

2) For PRACK, if the client transaction layer times out waiting for 200 
OK to PRACK before moving to the next record, the server transaction may 
run out of 18x retries waiting for PRACK and disconnect the call, if the 
next record happens to be the one that sent 18x.

TIA,
Sanjay.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Apr 2003 17:42:37 +0300

Hi,

> generate transport errors.

[CHH] It is true that the remote server will not be able to send eg a 503
response for an ACK, but if the failure occurs on the transport level you
will be notified it the same way as you would for any other request (ICMP
errors etc). These are sent independently on if the remote server generates
SIP responses or not.

> next record happens to be the one that sent 18x.

[CHH] In theory, yes. Normally, however, I would say that PRACKs are sent to
the same IP address as the INVITE, so if you don't get a reply (even if you
get replies to the INVITE) something is probably wrong on the remote side
anway...

Also, I would assume that in most cases the remote party either answers the
call, or the client terminates the call setup, before these timeouts
occur...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Sanjay Sinha <[email-masked]>
Date: Tue, 29 Apr 2003 11:10:27 -0400

Hi Christer,

Thanks for the response, pl. see inline.

Sanjay.

Christer Holmberg wrote:

>>If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name.  The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously.  The client SHOULD try the first record.  If an attempt should fail, based on the definition of failure in Section 4.3, the next SHOULD be tried, and if that should fail, the next SHOULD be tried, and so on.
>>
>>to next record in the list if used with UDP and the next hop does not generate transport errors.
>>    
>>
>
>[CHH] It is true that the remote server will not be able to send eg a 503 response for an ACK, but if the failure occurs on the transport level you will be notified it the same way as you would for any other request (ICMP errors etc). These are sent independently on if the remote server generates SIP responses or not.
>
[SS] But the client transport layer will not get ICMP errors if the 
first record from the list has crashed or has it's interface shutdown.

>[CHH] In theory, yes. Normally, however, I would say that PRACKs are sent to the same IP address as the INVITE, so if you don't get a reply (even if you get replies to the INVITE) something is probably wrong on the remote side anway...
>
[SS] I do not think that's true. If the proxy in-between did  not 
record-route, PRACK will be sent to Contact of 18x and not where the 
Invite was sent.

>
>Also, I would assume that in most cases the remote party either answers the call, or the client terminates the call setup, before these timeouts occur...
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>  
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Apr 2003 13:20:26 +0300

Hi,

> >[CHH] It is true that the remote server will not be able to send eg a 503 response for an ACK, but if the failure occurs on the transport level you will be notified >it the same way as you would for any other request (ICMP errors etc). These are sent independently on if the remote server generates SIP responses or not.
> >

[CHH] Well, if the ACK doesn't reach the server you will get retransmits of the 200 OK (unless they are supposed to be sent from the same interface which has crashed, of course)..

> >[CHH] In theory, yes. Normally, however, I would say that PRACKs are sent to the same IP address as the INVITE, so if you don't get a reply (even if you get >replies to the INVITE) something is probably wrong on the remote side anway...
> >

[CHH] True, but what I meant is that the remote UAS (ie the one generating and sending the 18x messages, and that will eventually receive the PRACK) is the same.

UAC             PROXY             UAS

--- INVITE --->   --->INVITE--->
<--18x----------  <---18x----------
----PRACK----------------------->

Regards,

Christer Holmberg
Ericsson Finland

---

From: Sanjay Sinha <[email-masked]>
Date: Wed, 30 Apr 2003 10:03:09 -0400

Hi Christer,

Pl. see inline.

thanks,
Sanjay.

>[CHH] Well, if the ACK doesn't reach the server you will get retransmits of the 200 OK (unless they are supposed to be sent from the same interface which has crashed, of course)..
[SS] Right, but how does the client's transaction figure out that 200  
retransmissions are because of Ack going to the wrong interface from the 
list  vs. Ack being lost in the network/network delay and whether it 
should cycle to the next record or not.

>----PRACK----------------------->
[SS] Not neccesarily, if the UAS has dual interface (for redundancy 
etc.) and uses fqdn in contact of 18x with one interface having higher 
priority than the other one and the high priority interface down for 
some reason. UAC, after dns resolution of contact's fqdn, will use it 
for sending Prack and will keep  retransmitting till it gets 200 OK and 
will cycle to the next record when it runs out of retries. But the UAS 
is also retransmitting 18x waiting for Prack since the interface it's 
getting Prack on is down and when it runs out of retries will disconnect 
the call.