Subject: [Sipping] New Contact attributes proposed for Call Control

From: Rohan Mahy <[email-masked]>
Date: Wed, 05 Sep 2001 21:15:47 -0700

Hi,

At IETF 51 I presented a call control model 
(draft-mahy-sip-cc-model-00.txt) which listed some requirements for passing 
attributes about particpants in a "conversation space".  I have listed 
below some candidates for additional Contact parameters in the spirit of 
the caller-preferences draft.  Note that all of these attributes are 
orthogonal to each other and to the attributes in the caller preferences draft.

While I think these attributes should be described in another document, I 
wanted folks to get a chance to see these before caller-prefs gets put to 
bed.  I also want to make sure that caller-preferences allows for extension 
later.

Additional descriptions of the meaning of these attributes are in the call 
models draft.

** Visibility Attribute
Conveys if a UA wishes to be visible among the list of participants in the 
conversation space correpsonding to the current call-leg.
[Obviously a UA that wishes to remain hidden should only establish 
call-legs with other UAs that will respect that desire.]

Syntax:
	"visibility" "=" <"> ( "visible" | "hidden" ) <">

Default:
	visibility="visible"

Examples:
	Contact: sip:[email-masked];visibility="hidden"
	Contact: sip:[email-masked];visibility="hidden"

** Participation Attribute
Conveys if a participant is capable of terminating a 
session/call/conversation on its own (active) or not (passive), or will not 
contribute any unique content (none) as in the case of a relay, transcoder, 
or mixer.

Syntax:
	"participation" "=" <"> ( "active" | "passive" | "none" ) <">

Default:
	participation="active"

Examples:
	Contact: sip:[email-masked];participation="passive"
	Contact: sip:[email-masked];participation="none"
	Contact: sip:[email-masked];participation="none"

**Type of User Attribute
Conveys if the user is a human or machine/robot/automaton.

Syntax:
	"user" = <"> ( "human" | "automaton" | "unknown") <">

Default:
	user="unknown"

Examples:
	Contact: sip:[email-masked];user=automaton
	Contact: sip:[email-masked];user=human

comments welcome.
thanks,
-rohan

_______________________________________________
Sipping mailing list  http://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: "David R. Oran" <[email-masked]>
Date: Sun, 9 Sep 2001 08:58:56 -0400

I assume these are allowed on register, right?

Also, it would be really nice to have symmetry on the user= parameter so
that in an Invite's caller preferences I can say  "user=human" to avoid
my call getting hijacked by a proxy and redirected to an autoattendant
or announcement server.

Dave.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Rohan Mahy
> Sent: Thursday, September 06, 2001 12:16 AM
> To: [email-masked]
> Subject: [Sipping] New Contact attributes proposed for Call Control
> 
> 
> Hi,
> 
> 	Contact: 
> sip:[email-masked];visibility="hidden"
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 9 Sep 2001 22:36:43 -0500

Well, the called parties's proxy has priority over the caller's preference,
so I can still force your user=human call to talk to my autoattendant or my
blow-my-phone-up robot. Given the level of spam calls I get these days (kept
a log -- over 90% of calls to my house are marketing) I may just force ALL
incoming calls to go to an autoattendant for verification, then proxy them
to blow-my-phone-up when they turn out to be marketing . . .

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 09 Sep 2001 22:41:18 -0700

>I assume these are allowed on register, right?

yes

>my call getting hijacked by a proxy and redirected to an autoattendant

yes, Accept/Reject-Contact should still work with the new parameters.

thx,
-r

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 10 Sep 2001 07:30:21 -0400

> On Behalf Of Dean Willis
> Sent: Sunday, September 09, 2001 11:37 PM
> To: David R. Oran; [email-masked]
> Subject: Re: [Sipping] New Contact attributes proposed for 
> Call Control
> 
> 
Is this mandated in so many words, implied by the fact that caller
preferences are all "preferences" and not demands, or just a fact of
life that this is only enforceable by the non-existent protocol police?
Using the word "priority" imples the first, which I don't think is the
case.

A nice proxy SHOULD obey the caller preferences, since in my example
this gives the calling UAC the opportunity to do smart things without
being an oracle engaging in a robot-to-robot dialog with an
autoattendant.

So, I think my examples still show value in allowing the caller to bias
the proxies against redirection/forking to an automaton.

>so I can still force your user=human 
> call to talk to my autoattendant or my blow-my-phone-up 
> robot. Given the level of spam calls I get these days (kept a 
> log -- over 90% of calls to my house are marketing) I may 
> just force ALL incoming calls to go to an autoattendant for 
> verification, then proxy them to blow-my-phone-up when they 
> turn out to be marketing . . .
>
Sure. Of course I'd like to see your code for the attendant that with
high probability figures out that the caller is marketing. Remember, my
suggestion is to REJECT the call with a 4xx, not complete it and spoil
your dinner. If you have a smart enough call screening program (as you
posit above), you can send back a "no such user" and hopefully get taken
off the call list, as some folks do today by playing re-order tone back
to marketing calls.
 
> > Also, it would be really nice to have symmetry on the user= 
> parameter 
> > so that in an Invite's caller preferences I can say  
> "user=human" to 
> > avoid my call getting hijacked by a proxy and redirected to an 
> > autoattendant or announcement server.
> >
> > Dave.
> >
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Rohan Mahy
> > > (draft-mahy-sip-cc-model-00.txt) which listed some 
> requirements for 
> > > passing attributes about particpants in a "conversation space".  I
> > > have listed
> > > While I think these attributes should be described in another 
> > > document, I wanted folks to get a chance to see these before 
> > > caller-prefs gets put to
> > > Additional descriptions of the meaning of these attributes are in 
> > > the call models draft.
> > >
> > > ** Visibility Attribute
> > > Conveys if a UA wishes to be visible among the list of 
> participants 
> > > in the conversation space correpsonding to the current call-leg.
> > > session/call/conversation on its own (active) or not 
> (passive), or 
> > > will not contribute any unique content (none) as in the case of a
> > > relay, transcoder,
> > > or mixer.
> > >
> > > Syntax:
> > > Sipping mailing list  
> http://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
> > >
> >
> >
> > 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
> >
> >
> 
>