Subject: RE: [Sip] INVITE, CANCEL and BYE, re-transitions

From: "Thomas Vasen" <[email-masked]>
Date: Wed, 19 Feb 2003 00:52:38 +0100

Hi, 

From your answer I understand that if a proxy goes down during call
setup SIP is not design to properly handle call tear down. In this case
the phones will be ringing forever. 

Is there any work being done on improving these scenarios?

//Thomas. 

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: onsdag 5 februari 2003 23:53
To: [email-masked]
Subject: RE: [Sip] INVITE, CANCEL and BYE, re-transitions

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

> I would just like to verify my understanding
> regarding 'Backup Routes' with SIP.
>
> Suppose one UA has 2 routes, one primary to
> PROXY1, and one secondary to PROXY2.
>
> Suppose PROXY1 is down.
> When the UA sets up a session, it will
> Send INVITE to Proxy 1
> Timeout
> Eventually send INVITE to Proxy 2, and setup the session.

When advancing to proxy 2, one or more of the
following should change within INVITE to
denote forking:
1) From tag
2) Call-ID
3) Via branch

> Suppose now Proxy 1 and 2 are UP.
> UA send INVITE to Proxy 1
> Proxy sends trying and sets up session.
> Proxy 1 dies.
> UA sends BYE to Proxy 1, though does not receive any response.

The 100 Trying response does not create an early
dialog.  Thus CANCEL must be sent instead of a BYE.

> Shouldn't at this point the UA try to send the
> BYE to the Proxy 2 as well?

The CANCEL should only be sent where the INVITE
was sent.  (This is mainly because the top via entry
is used to help identify the cancelled request.)

If a 101-2xx response was received and the
proxy's Record-Route entry included a hostname
representing both proxies, the BYE could
target advance to proxy 2 when proxy 1 is not
responding.

Please see RFC 3261 sections 9, 12, and 13 for
a more complete description.

_______________________________________________
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
_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Tue, 25 Feb 2003 17:51:44 -0500

> From your answer I understand that if a proxy 
> goes down during call setup SIP is not design 
> to properly handle call tear down. In this case

RFC 3261 section 13.3.1.1 presents the mechanism
to deal with the ring forever problem.  Beyond that,
the UAS needs to deal with knowing if it is
a good idea to ring forever.  Most vendors realize 
that phone users will not likely want their phone 
to power/audibly ring indefinitely; however some 
might think that it is cool new "annoy the neighbors" 
feature. :)

> Is there any work being done on improving these 

RFC 3262, RFC 3263, RFC 3311, and 
draft-ietf-sip-session-timer address many of
the fault tolerant issues.  See the following
two links for currently chartered items
of the sip and sipping working groups.

http://www.ietf.org/html.charters/sip-charter.html

http://www.ietf.org/html.charters/sipping-charter.html