Subject: Re: [Sip] Question on RFC 3263

From: Christer Holmberg <[email-masked]>
Date: Thu, 01 May 2003 21:22:51 +0300

Hi,

> >>>>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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>[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] 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.

[CHH] I guess you will have to use logic based on local policy to decide when to "switch" from one address to another, if the 200 responses don't stop coming, even if you send ACK...

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

[CHH] Well, if one interface, which is to be used to send messages to, is not working, I think disconnecting the call is the only thing you can do...

These kind of scenarios have been discussed on the list before. It is possible to come up with an infinite number of them, and the spec can't cover them all, so it's pretty much an implementation issue. In general I would say: if something in the call setup fails you terminate the call setup.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 May 2003 04:23:15 -0400

Christer Holmberg wrote:
> Hi,
> 
> 
>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> [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] 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.
> 
> 
> [CHH] I guess you will have to use logic based on local policy to
> decide when to "switch" from one address to another, if the 200
> responses don't stop coming, even if you send ACK...

I think that this is a bad idea. I believe the answer is simpler - 
there is no timeout-based mechanism for detecting failure for ACK. 
Only ICMP or TCP connection problems will work. Thats just a 
limitation of the way ACK works. Relying on e2e messaging (like the 
200 OK) to infer problems at a specific hop is not going to work.

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

Actually, before that even happens the client transaction will simply 
terminate at the UAC. See:

http://www.ietf.org/internet-drafts/draft-sparks-sip-noninvite-00.txt

but in any case, the UAS shouldnt terminate the call just because the 
18x never got a PRACK.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com