If you want to make things robust, perhaps you could:
UAS side:
- make sure ICMP port unreachable is sent when the host is up but its SIP
stack isn't (for UDP)
- make sure routers towards the UAS allow these ICMP messages to pass
through
- make sure UAS can recognise (e.g. by the to tags it generates) their own
ACKs, and send BYE immediately when the to-tag was generated by another
machine (with special termination reasoncode?)
- or have it take over the call if possible. You may need to worry about the
original UAS sending BYE though, maybe retransmission state could be shared
to avoid that. But that may get more complex than the issue you're solving
is worth
UAC side:
- keep track of failed IPs, and maybe PING them (or other reachability
detection method) before or in parallel using UDP (especially when you know
it was down before)
- use TCP or SCTP
JvB
----- Original Message -----
From: "Jeroen van Bemmel" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, June 16, 2005 8:16 PM
Subject: Re: [Sip-implementors] Resolving in ACK request
I think several different cases are now being discussed here:
1) UAC sends the INVITE to a second UAS of a pair from which the first is
down (original poster)
2) UAC sends the INVITE via a proxy that goes down (or was down for the
first INVITE and gets the ACK)
Case (2) is not nescessarily a problem, since the alternative proxy should
happily forward the ACK (it is a new separate transaction)
For case (1) I don't think you can depend on receiving an ICMP error, the
OS may have a policy not to send such messages, or some router in between
could block them / fail to generate them. When a TCP or SCTP transport is
used the error would be detected, such that the ACK would also get sent to
the second UAS.
So if you want to avoid this failure scenario, don't use UDP
Regards,
Jeroen
----- Original Message -----
From: "Venkatesh" <[EMAIL PROTECTED]>
To: "Isaac Dudy" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Thursday, June 16, 2005 7:15 PM
Subject: Re: [Sip-implementors] Resolving in ACK request
Actually, on second thoughts, you should get an ICMP error when you
attempt
to send the ACK to the IP/port that was down. This should result in you
resending the ACK to another IP/port from the DNS list?
Venkatesh
On 6/16/05, Isaac Dudy <[EMAIL PROTECTED]> wrote:
What will happen if the UA works with outbound proxy farm, so the UA
sends the INVITE to a FQDN which resolved to all the proxies in the
farm. The first proxy is down so the INVITE transaction is done through
the second proxy. Now the UA wants to send the ACK so it has the same
FQDN as the INVITE and the ACK will go to the first proxy again. My
assumption here is that UA that works with outbound proxy always sends
all transaction to the outbound proxy regardless of other routing
information that arrives in the 2xx on the INVITE, maybe my assumption
is wrong, please advise.
Thanks in advance,
David Isaac.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dale
Worley
Sent: Thursday, June 16, 2005 7:01 PM
To: [email protected]
Subject: RE: [Sip-implementors] Resolving in ACK request
That's true, it could happend. But if you don't put IP addresses in as
the hosts in Record-Route's, you should use names that preferentially
resolve to the IP address of the host adding the Record-Route. Section
6 of RFC 3263 discusses a clever way to accomplish this. If done right,
the chances of an attempt being made to send to a down server are
greatly reduced.
Dale
-----Original Message-----
From: Venkatesh [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 16, 2005 11:33 AM
To: Dale Worley
Cc: [email protected]
Subject: Re: [Sip-implementors] Resolving in ACK request
I think this scenario happens if all the RR headers that got added by
proxies were FQDN's that resolved to multiple IP addresses (per section
16.6 of 3261 this is possible, as the RR header MUST resolve to the IP
address/port of this element that or a suitable stand in). On receipt of
the 200 OK, the UA constructs the route set which is a set of FQDN's. It
builds the ACK. It uses the Route set to send the ACK. This results in
the UA having to do a DNS lookup. The response returned by DNS could
result in the UA choosing an IP address/port of a proxy that is down.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
______________________________________________________________________
This email message has been scanned by PineApp Mail-Secure and has
been found clean.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
