Subject: RE: [Sipping] SIP Status code for communicating about UA in minimalstate- Post active dialog

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 12 Apr 2006 09:40:16 -0400

You are using B2BUAs are you not? 
 
They should have the intelligence to not involve dialog1 when something
bad happens to the dialog with phone2.  They are separate dialogs, are
they not?  I assume you are intending to restore the dialog with phone 2
at some point.
 
I don't see the need to do anything new with dialog1.
 
Mike

________________________________

	From: Rajeev Narang (ranarang) 
	Sent: Wednesday, April 12, 2006 2:44 AM
	To: [email-masked]
	Subject: [Sipping] SIP Status code for communicating about UA in
minimalstate- Post active dialog

	Hi,
	 
	Say we have the following scenario:-
	 
	 phone1-----B2BUA1----dialog1 (active) ----B2BUA2----phone2
	 
	There is a session timers active on the dialog1. Say UA1 is the
refresher.
	 
	An event occurs which results in B2BUA2 loosing network with
phone2. 
	For our requirement we still want to allow dialog1 to be active
with no interupption to the periodic session refresh. The B2BUA2 must
keep on responding to the session refresh.
	 
	The requirement is that we want to communicate to B2BUA1 about
this recent situation with B2BUA2 in response to the session refresh.
The B2BUA1 must be allowed to take some specific action based on the
state of the B2BUA2. Also Proxy server between the UA's mustn't tear
down the call.
	 
	Basically the response code should be such that the session
refresh procedure must go "on" but remote (refresher) must come to know
about this situation.
	 
	From the available SIP status codes the following are choices:-
	1) 200 OK:- Using this status code would indicate a normal
situation, so doesn't seem appropriate.
	2) 488 Not Acceptable Here:- Not sure if this will make sense
for mid call.
	3) 480 Temporarily Unavailable:- Not sure if this will make
sense for mid call.
	 
	Any suggestions on the SIP Status code so that we can handle it
in a standard way.
	 
	How about creating a new SIP Status code.
	Say:- "450 Call in Minimal/Preserved State"
	 
	Thanks much,
	Rajeev

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

---

From: "Rajeev Narang \(ranarang\)" <[email-masked]>
Date: Wed, 12 Apr 2006 19:43:47 +0530

Right, these are B2BUAs.
 
Actually we need to keep B2BUA1 in knowledge of this specific state at
B2BUA2 (as mentioned in scenario below). In case network link from
B2BUA1 to B2BUA2 is also lost, we need to do some action at B2BUA1. And
action at UA1 will be dependent on whether B2BUA2 was fully active or
got into some minimal state due to its network issues with phone2. 
So was thinking if we can use some standard SIP Status code from B2BUA2
to B2BUA1.
 
Thanks,
Rajeev

From: Michael Hammer (mhammer) 
Sent: Wednesday, April 12, 2006 7:10 PM
To: Rajeev Narang (ranarang); [email-masked]
Subject: RE: [Sipping] SIP Status code for communicating about UA in
minimalstate- Post active dialog

 
 
Mike

	Hi,

	 

	 

	 
	 
	Thanks much,
	Rajeev

---

From: "Rajeev Narang \(ranarang\)" <[email-masked]>
Date: Wed, 12 Apr 2006 20:00:31 +0530

Agree. But B2BUA2 has got into such state that it cannot handle any
features etc, basically is just left with UA2 (no longer b2bua as other
side is stopped due to n/w issue). So session refresh from UA1 may be
responded with this whole situation at B2BUA2. 200 OK will not help to
infer something.
 
Otherwise choice left is to use something proprietary between B2BUA's,
either in the Reason Header (proprietary Q.850 cause) or 488 with
proprietary "warning text".
It will be good to use some SIP status code which could closely reflect
this.
 
Thanks,
Rajeev

From: Michael Hammer (mhammer) 
Sent: Wednesday, April 12, 2006 7:49 PM
To: Rajeev Narang (ranarang); [email-masked]'
Subject: RE: [Sipping] SIP Status code for communicating about UA in
minimalstate- Post active dialog

My concern is that the SIP status code is status about the dialog
transaction, which is not experiencing any difficulty.  What you are
reporting status on is something outside that dialog, which seems
inappropriate.
 
Mike

	From: Rajeev Narang (ranarang) 
	Sent: Wednesday, April 12, 2006 10:14 AM
	To: Michael Hammer (mhammer); [email-masked]'
	Subject: RE: [Sipping] SIP Status code for communicating about
UA in minimalstate- Post active dialog

	Right, these are B2BUAs.
	 
	Actually we need to keep B2BUA1 in knowledge of this specific
state at B2BUA2 (as mentioned in scenario below). In case network link
from B2BUA1 to B2BUA2 is also lost, we need to do some action at B2BUA1.
And action at UA1 will be dependent on whether B2BUA2 was fully active
or got into some minimal state due to its network issues with phone2. 
	So was thinking if we can use some standard SIP Status code from
B2BUA2 to B2BUA1.
	 
	Thanks,
	Rajeev

	From: Michael Hammer (mhammer) 
	Sent: Wednesday, April 12, 2006 7:10 PM
	To: Rajeev Narang (ranarang); [email-masked]
	Subject: RE: [Sipping] SIP Status code for communicating about
UA in minimalstate- Post active dialog

	They should have the intelligence to not involve dialog1 when
something bad happens to the dialog with phone2.  They are separate
dialogs, are they not?  I assume you are intending to restore the dialog
with phone 2 at some point.

	Mike

		From: Rajeev Narang (ranarang) 
		Sent: Wednesday, April 12, 2006 2:44 AM
		To: [email-masked]
		Subject: [Sipping] SIP Status code for communicating
about UA in minimalstate- Post active dialog

		Hi,

		 phone1-----B2BUA1----dialog1 (active)
----B2BUA2----phone2
		 
		There is a session timers active on the dialog1. Say UA1
is the refresher.
		 
		An event occurs which results in B2BUA2 loosing network
with phone2. 
		For our requirement we still want to allow dialog1 to be
active with no interupption to the periodic session refresh. The B2BUA2
must keep on responding to the session refresh.
		 
		The requirement is that we want to communicate to B2BUA1
about this recent situation with B2BUA2 in response to the session
refresh. The B2BUA1 must be allowed to take some specific action based
on the state of the B2BUA2. Also Proxy server between the UA's mustn't
tear down the call.
		 
		Basically the response code should be such that the
session refresh procedure must go "on" but remote (refresher) must come
to know about this situation.
		 
		From the available SIP status codes the following are
choices:-
		1) 200 OK:- Using this status code would indicate a
normal situation, so doesn't seem appropriate.
		2) 488 Not Acceptable Here:- Not sure if this will make
sense for mid call.
		3) 480 Temporarily Unavailable:- Not sure if this will
make sense for mid call.
		 
		Any suggestions on the SIP Status code so that we can
handle it in a standard way.

		Thanks much,
		Rajeev

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 12 Apr 2006 10:39:50 -0400

Is there some timer that would expire on B2BUA2?  The way you describe
it, B2BUA2 is the one with the knowledge, but not smart enough to know
what to do with it.
 
I would think that if the connection to phone 2 can not be recovered,
B2BUA2 needs release dialog1 with a BYE with a Reason header to indicate
why.  Would that work?
 
Mike

	Sent: Wednesday, April 12, 2006 10:31 AM

	Agree. But B2BUA2 has got into such state that it cannot handle
any features etc, basically is just left with UA2 (no longer b2bua as
other side is stopped due to n/w issue). So session refresh from UA1 may
be responded with this whole situation at B2BUA2. 200 OK will not help
to infer something.
	 
	Otherwise choice left is to use something proprietary between
B2BUA's, either in the Reason Header (proprietary Q.850 cause) or 488
with proprietary "warning text".
	It will be good to use some SIP status code which could closely
reflect this.
	 
	Thanks,
	Rajeev

	My concern is that the SIP status code is status about the
dialog transaction, which is not experiencing any difficulty.  What you
are reporting status on is something outside that dialog, which seems
inappropriate.
	 
	Mike

		Subject: RE: [Sipping] SIP Status code for communicating

		Right, these are B2BUAs.
		 
		Actually we need to keep B2BUA1 in knowledge of this
specific state at B2BUA2 (as mentioned in scenario below). In case
network link from B2BUA1 to B2BUA2 is also lost, we need to do some
action at B2BUA1. And action at UA1 will be dependent on whether B2BUA2
was fully active or got into some minimal state due to its network
issues with phone2. 
		So was thinking if we can use some standard SIP Status
code from B2BUA2 to B2BUA1.
		 
		Thanks,
		Rajeev

		Subject: RE: [Sipping] SIP Status code for communicating

		They should have the intelligence to not involve dialog1
when something bad happens to the dialog with phone2.  They are separate
dialogs, are they not?  I assume you are intending to restore the dialog
with phone 2 at some point.

		Mike

			From: Rajeev Narang (ranarang) 
			Sent: Wednesday, April 12, 2006 2:44 AM
			To: [email-masked]
			Subject: [Sipping] SIP Status code for
communicating about UA in minimalstate- Post active dialog

			Hi,

			 
			There is a session timers active on the dialog1.
Say UA1 is the refresher.
			 
			An event occurs which results in B2BUA2 loosing
network with phone2. 
			For our requirement we still want to allow
dialog1 to be active with no interupption to the periodic session
refresh. The B2BUA2 must keep on responding to the session refresh.
			 
			The requirement is that we want to communicate
to B2BUA1 about this recent situation with B2BUA2 in response to the
session refresh. The B2BUA1 must be allowed to take some specific action
based on the state of the B2BUA2. Also Proxy server between the UA's
mustn't tear down the call.
			 
			Basically the response code should be such that
the session refresh procedure must go "on" but remote (refresher) must
come to know about this situation.
			 
			From the available SIP status codes the
following are choices:-
			1) 200 OK:- Using this status code would
indicate a normal situation, so doesn't seem appropriate.
			2) 488 Not Acceptable Here:- Not sure if this
will make sense for mid call.
			3) 480 Temporarily Unavailable:- Not sure if
this will make sense for mid call.
			 
			Any suggestions on the SIP Status code so that
we can handle it in a standard way.

			Thanks much,
			Rajeev