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

From: "Mahesh Govind" <[email-masked]>
Date: Sat, 15 Apr 2006 14:40:33 +0900

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-notify-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]> 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]'
> > *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
> 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
>
>
_______________________________________________
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