Subject: RE: [Sipping] updated dialog package

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Mon, 23 Feb 2004 05:43:52 -0800

Resending the same as my first posting somehow was empty in the mailing list !

From a shared line application perspective: 

There is a piece missing from a implementation perspective for shared line appearances. 

   - Ability to signal Hold. I know there have been a few discussions in the SIPPING mailing list around this and it there was no conclusion about what "hold" actually is ! However, one of the important aspects of shared lines is the ability to communicate a held call to the other parties in the group. Currently the anil-sipping-bla draft uses the SDP information to help other UA's decide a dialog is transitioning to hold and off hold. It would be definitely useful to have the dialog state express this state to the far end rather than having to send out SDP information. For the purpose of SLA, instead of going down defining what is Hold, I was wondering if we can create  a state/or an attribute in the dialog state package say "pickable" dialog to indicate the same. I've heard comments saying a UA can block relevant fields of a dialog whenever it wants others to be able to pick or not to pick a dialog, however the same is not clean and it breaks when say the same UA that put the dialog on Hold, retrieves the dialog. Nothing in the dialog identifiers have changed.

The anil-sipping-bla-draft covers other various aspects of SLA from an application implementation perspective with call flow examples.

regards, 
Venkatesh 

	-----Original Message----- 
	From: [email-masked] on behalf of Rohan Mahy 
	Sent: Thu 2/19/2004 9:59 AM 
	To: sipping 
	Cc: [email-masked] 
	Subject: [Sipping] updated dialog package

	Hi Everyone, 

	I've updated the dialog packages with the changes we agreed to in 
	Minneapolis (removing CSeq and the Route-Set). 

	I've also provided a detailed example of using the dialog package for a 
	"shared-line" application.  I apologize for my tardiness here.  I was 
	supposed to post something shortly after the meeting.  I any case, I 
	believe this demonstrates that the current syntax is at least 
	sufficient for the use cases we've discussed.  I would like to hear 
	from all of you if this does the trick. 

	many thanks, 
	-rohan 

	_______________________________________________ 
	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 

J*i�x&j)b�	b��m��?�0�'�~���f��f��X��)ߣ�"����8b�X��+��DYׯzZ)�����ay�i�'�*'��=K�*b��^�������%�f�i�n~���-���w.����ȩRǬ�����+��+��z�������(}�+y"

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 23 Feb 2004 18:54:47 -0800

Hi,

On Feb 23, 2004, at 5:43 AM, Venkatesh Venkataramanan wrote:

>    - Ability to signal Hold. I know there have been a few discussions 
> in the SIPPING mailing list around this and it there was no conclusion 
> about what "hold" actually is ! However, one of the important aspects 
> of shared lines is the ability to communicate a held call to the other 
> parties in the group. Currently the anil-sipping-bla draft uses the 
> SDP information to help other UA's decide a dialog is transitioning to 
> hold and off hold. It would be definitely useful to have the dialog 
> state express this state to the far end rather than having to send out 
> SDP information.

I'm sorry.  I dropped the ball on this.  I was going to propose a new 
callee-caps style "media feature parameter" called "interactive".  I 
think this satisfies the requirement for what folks are actually 
interested in for "hold", but I need to send out the proposal tomorrow 
to verify this with everyone on the list.

> For the purpose of SLA, instead of going down defining what is Hold, I 
> was wondering if we can create  a state/or an attribute in the dialog 
> state package say "pickable" dialog to indicate the same. I've heard 
> comments saying a UA can block relevant fields of a dialog whenever it 
> wants others to be able to pick or not to pick a dialog, however the 
> same is not clean

why isn't this clean?

> and it breaks when say the same UA that put the dialog on Hold, 
> retrieves the dialog. Nothing in the dialog identifiers have changed.

I don't see why this is a problem.  Also, if I'm already in a dialog, 
the implicit filtering of the dialog package prevent me from receiving 
notifications about state that I already know about directly.  Not 
exactly sure what you mean.

In any case, lets take two cases, cooperating and non-cooperating UAs.  
Cooperating UAs can use the presence or existence of dialog identifiers 
in notifications that they receive to convey that a call is pickable by 
them. Non-cooperating UAs that happen to learn the dialog identifiers 
but aren't authorized, can try to pick calls all they want, but will 
just get 403 Forbidden responses for their requests.

thanks,
-rohan

> The anil-sipping-bla-draft covers other various aspects of SLA from an 
> application implementation perspective with call flow examples.
>
> regards,
> Venkatesh
>