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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 17 Apr 2006 10:07:42 -0400

The existence of proxies depends on which may have record-routed.  If
so, then they would likely not be forking the call again.  But, in any
case a 4xx or 450 would cause the dialog to end.  But, that is the
intent is it not?  
 
My understanding is that the intent is for the corresponding media not
to also be ended.  Perhaps this would also require some type of caller
preferences and some type of new proxy directive.  But, since media is
"supposed to be" end-to-end the main issue is whether the two media
endpoints understand the meaning of this form of "call, but not media"
release.
 
I'll need to read the proposed draft to see how this all works.
 
Mike

________________________________

	From: Rajeev Narang (ranarang) 
	Sent: Monday, April 17, 2006 4:06 AM
	To: Mahesh Govind
	Cc: [email-masked]
	Subject: RE: [Sipping] SIP Status code for communicating about
UA inminimalstate-Post active dialog

	Hi Mahesh,
	 
	It seems the 8.1.3.2 section is for the out of dialog behavior
for initial call setup.
	 
	In our case mainly the usage for 450 response code will be
mid-call (post established dialog) when the link from b2bua to remote
party gets out of order.
	I think if b2bua doesn't understand 450 and treats it as 400,
probably for mid-call 400 handling will be b2bua specific (may not tear
down the call).
	
	The mid-call transactions will probably be directly between
UA's, so probably Proxy may not need to mandatory address the forwarding
of the 450 status code.
	
	So I think semi failure response (4xx) may be fine.
	 
	Thanks much,
	Rajeev
	
________________________________

	From: Mahesh Govind [mailto:[email-masked]] 
	Sent: Sunday, April 16, 2006 1:03 PM
	To: Rajeev Narang (ranarang)
	Cc: [email-masked]
	Subject: Re: [Sipping] SIP Status code for communicating about
UA in minimalstate-Post active dialog

	HI Rajeev,
	 
	I have a small query regarding to the response class  , whether
, we need to convey a  semi successful  response or a semi failure
response state .ie Whether we need to send a 2xx class or  4xx class.
	If B2BUA1 receives a 450  and it doesn't understands 450 , will
it consider the 450 as a 4xx and consider it as a failure ?(8.1.3.2
Unrecognized Responses of 3261) .Instead if it gets a 250 and even if
it don't understands a 250 , it will consider it as a success case and
may not tear the call.. 
	Also I think if some proxy is in between it will take the 2xx
response end to end ?
	With thanks and regards
	Mahesh

	On 4/15/06, Rajeev Narang (ranarang) <[email-masked]> wrote:

		Mahesh,
		 
		I looked into the draft provided by you. It seems useful
for the scenarios where GW/b2bua level "state" information is to be
notified. And it will need the framework to be implemented and both way
subscription/notification will be needed for every call. I think it will
be useful if specific service state information is needed per call. 
		 
		My requirement is very basic for the sip dialogs and
that situation could encounter in any b2bua's interworking with the
phone. It is mainly for addressing situations where any dialog from
b2bua to the phone could encounter the network loss. And assumption is
media is direct between phones or through media agents. The b2bua to
phone network loss must not impact the established media for currently
active calls. 
		Basically even if one side of b2bua losses network to
the phone, it doesn't mean that media/session between the phones (which
could be direct on a different network) is also lost, so we won't want
to terminate the call to the other side of b2bua. 
		 
		Effectively to support this, it needs to pass the
appropriate mid dialog SIP Status code on the sip dialog to the other
end of b2bua. 
		 
		We could send the BYE to remote UA with appropriate SIP
Status info about this situation (basically n/w out of order with the
phone). 
		So, it is upto the remote UA, whether to tear down the
call or take it as a partial network issue and assume that media between
the phones could still be active. 
		So the remote UA will wait for hangup from the phone on
its side. 
		 
		Main idea is not to restore the call, but to preserve
the established media until graceful hangup.
		 
		The current plan as per discussion with Mike, is to
propose a draft with a new SIP Status code "450 Call in Minimal State"
for this situation, which will reflect the status of the whole b2bua. 
		 
		Thanks much,
		Rajeev
________________________________

		From: Mahesh Govind [mailto:[email-masked]] 
		Sent: Saturday, April 15, 2006 11:16 AM
		
		To: [email-masked]
		Subject: [Sipping] SIP Status code for communicating
about UA in minimalstate-Post active dialog

		
		sorry, the previous copy went to sip list accidentally .
		regds
		Mahesh

		HI,
		We had earlier written a draft about service state of
sip entities .Basically it is an event package.
	
(http://www.ietf.org/internet-drafts/draft-mahesh-sipping-svc-state-noti
fy-00.txt  )
		The draft is not telling  exactly about the requirement
in the thread  , but some thing similiar to it . If you have time please
go through it .Currently we have defined only one state ,
		Out of service, but we see that we can define  other
intermediate states (dormant ) and another final state inservice .also
and  this can be extended very easily.

		(PS :In the examples couple of bugs are there about the
usage and implict subscription)

		With thanks and regards

		Mahesh

		 
		On 4/14/06, Ranga <[email-masked]> wrote: 

			Correct me if I am wrong. 
			
			As per the protocol, SIP responses are sent in
response to the request but not generated.
			
			In this perticular case, you could implement
this on top of NOTIFY ( implicit SUBCRIPTION ). 

			Ranga

			On 4/12/06, Michael Hammer (mhammer) <
[email-masked] <mailto:[email-masked]> > wrote:

				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] <mailto:[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

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

			_______________________________________________
			Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
<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 

_______________________________________________
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