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

["Brett Tate" <brett@broadsoft.com>]

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

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

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


> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com] 
> Sent: onsdag 5 februari 2003 23:53
> To: sip@ietf.org
> Subject: RE: [Sip] INVITE, CANCEL and BYE, re-transitions
> 
> "This list is for NEW development of the core SIP Protocol.
> Use sip-implementors@cs.columbia.edu for questions on current sip.
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip