Subject: Re: [Sipping] Conference URIs and Caller Prefs

From: [email-masked]
Date: Thu, 18 Jul 2002 10:23:42 -0400

Ranjit:
http://search.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-06.txt

Paul: I am not sure if Alan's suggestion requires a registration as a 
must. I am looking at this more as a convenient way to 'join B's adhoc 
bridge if
he has one'. I am assuming that your issue that a call may get misrouted 
stems from the fact that if there is a server in between who routes
a regular call from A to B using B's "conference" contact would probably 
mean that that server did not understand the "feature" directive or was 
mangled up for some other reason.

But then, this logic can be applicable to any other "feature" tag in 
caller-callee including voicemail (say).

Personally, I don't really see a big difference between using SUB/NFY vs. 
Acc/Rej-Contact except for the fact that the later is probably more
efficient for successful conference joins. 

Thinking about your other point about what if user A wants to host 
multiple adhoc bridges and B asks for any-conference:

* first, I feel the possibility of a user hosting one bridge is more than 
it hosting many simul. bridges (unless the 'user' is a conference server 
by itself)

* second, if User B did send an INVITE to user A with the "can I join your 
conference" Accept-Contact clause and User A find this information
ambiguous (ie it hosts more than one), it can always reject and optionally 
give B a list of its conference URLs that it is hosting now.

* when user B wants to join an adhoc conference hosted by A, he typically 
does not do it at random. He would have gotten to know
from some source (maybe a chat) that A has started a conference and more 
likely than not, his request would get accepted by A ->
hence a simple request like 'can you add me to  your conference' should be 
effective.

regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066

"Ranjit Avasarala" <[email-masked]>
Sent by: [email-masked]
07/18/2002 09:19 AM
Please respond to "Ranjit Avasarala"

        To:     "Paul Kyzivat" <[email-masked]>, "Alan Johnston" 
<[email-masked]>
        cc:     <[email-masked]>
        Subject:        Re: [Sipping] Conference URIs and Caller Prefs

where can I find the draft on caller prefs? is the param feature= part of
any draft?

Ranjit
----- Original Message -----
From: Paul Kyzivat <[email-masked]>
To: Alan Johnston <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 17, 2002 7:34 PM
Subject: Re: [Sipping] Conference URIs and Caller Prefs

> Alan,
>
> I am having difficulty coming up with a case when this would be useful. 
My
concerns are:
>
> - requires the UA to register the conference
> - once registered, calls might be accidentally sent to it
> - doesn't work well for more that one conference at an AoR,
>   unless it really doesn't matter which one the caller gets.
>
> To use this, the calling UA needs specific logic to insert the
Accept-Contact header. If it has this, can't it also use other means (e.g.
event packages) to discover the
> (unregistered) conference?
>
> There are of course lots of cases for registering a single conference. 
But
in those cases I am coming up blank thinking of reasons why I would want
multiple contacts in
> that case, especially a mixture of conference and non-conference 
contacts.
>
> Do you have an example in mind when this would be useful? Are you 
assuming
that requests must be proxied through the AoR to be globally routable?
>
> BTW, if you want a conference and only a conference, you'd better use:
>
>     INVITE sip:[email-masked]
>     Reject-Contact: *;feature="!conference"
>
> Paul
>
> Alan Johnston wrote:
> >
> > Here's a thought I've had relating to ad hoc conference URI
identification
> > and caller prefs.
> >
> > If we added a conference feature tag to the Caller Prefs draft,  it
would
> > be useful for labeling a Contact for a conference URI as being a
conference.
> >
> > Specifically, along the same lines as feature=voicemail, define
> > feature=conference.  A conference bridge belonging to User B could be
> > registered with a Registrar that supports Caller Prefs by
> >
> >    REGISTER sip:registrar.there.com
> >    Contact: sip:[email-masked];feature=conference
> >
> > UserB could send a request to his/her ad hoc conference bridge by:
> >
> >    INVITE sip:[email-masked]
> >    Accept-Contact: *;feature=conference
> >
> > This has the advantage that the conference URI
> > sip:[email-masked] does not need to be provisioned into
> > UserB's UA, or discovered using some SIP or non-SIP method.
> >
> > Also, if UserB is in an ad hoc conference and UserC knows this, UserC
has a
> > choice of requesting to join the conference:
> >
> >    INVITE sip:[email-masked]
> >    Accept-Contact: *;feature=conference
> >
> > Or just to talk to UserB individually,  by sending the INVITE without
using
> > the Accept-Contact header.
> >
> > The Accept-Contact header could also be escaped into a Refer-To header
> > within a REFER for UserB to add a participant to a ad hoc conference,
again
> > without any configuration or URI discovery mechanism.
> >
> > Also, if UserB's UA is capable of performing local mixing, if User C 
was
> > added in a local conference with UserA, UserB could let UserA know 
that
> > they are now involved in a conference by adding the feature=conference
tag
> > to its Contact header in a re-INVITE.
> >
> > Thoughts?  Comments?
> >
> > Thanks,
> > Alan Johnston
> > sip:[email-masked]
> >

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jul 2002 12:31:01 -0400

[email-masked] wrote:
> must.

Callerprefs don't come into play unless there is a registration, because their purpose is to give the caller a say in how the choice is made among registered contacts.

> I am looking at this more as a convenient way to 'join B's adhoc
> bridge if
> he has one'.

I *suppose* the UAS could interpret the callerpref selections, but that seems like a hack, and I don't think it is what Alan was suggesting. (Hopefully he will tell us.)

> I am assuming that your issue that a call may get misrouted

Its not a matter of the server not "understanding" the conference feature. It is about the rules provided in callerprefs. If the caller provides no preferences, then all
the contacts are processed according to their q-values. 

If there is both a "regular" contact and a "conference" contact registered, then both may be tried. Even if the conference contact has a lower q-value, it may get tried
either because of parallel forking or by serial forking if the other contact fails to answer. 

Of course this callerpref feature could be accompanied by some additional callee specified scripting to prevent this from happening. But again, that isn't something Alan
mentioned.

> caller-callee including voicemail (say).

In the case of voicemail things work more reasonably. If the q-value of the voicemail contact is set lower than that of the regular UA, then in absence of a callerpref to
the contrary, the regular ua will be tried first, and the voicemail will be tried if the other fails. This is exactly what you expect in this case. And then, an
Accept-Contact for voicemail will cause voicemail to be tried first, failing over to the regular phone, while a Reject-Contact of "!voicemail" will only try voicemail.

> give B a list of its conference URLs that it is hosting now.

Yes, but in scenario Alan seemed to be proposing, this logic would need to be in the proxy server. Does something like CPL have the capability to deal with this scenario?

> hence a simple request like 'can you add me to  your conference' should be

In this kind of adhoc case, wouldn't it be more likely that B will simply call A. A will answer (as a separate call) and then transfer the caller into the conference if
that is the right thing to do?

There may be some cases when what Alan is proposing would be helpful. But it is going to require explicit support at the calling end to initiate a call this way. Providing
that as a feature is unlikely unless it is to be a widely used feature.

	Paul

---

From: "Ranjit Avasarala" <[email-masked]>
Date: Fri, 19 Jul 2002 14:48:47 +0530

Paul
        What is the q-value? like what does q stand for here?

Thanks
Ranjit
----- Original Message -----
From: Paul Kyzivat <[email-masked]>
To: <[email-masked]>
Cc: Ranjit Avasarala <[email-masked]>; Alan Johnston
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, July 18, 2002 10:01 PM
Subject: Re: [Sipping] Conference URIs and Caller Prefs

> Callerprefs don't come into play unless there is a registration, because
their purpose is to give the caller a say in how the choice is made among
registered contacts.
> I *suppose* the UAS could interpret the callerpref selections, but that
seems like a hack, and I don't think it is what Alan was suggesting.
(Hopefully he will tell us.)
> Its not a matter of the server not "understanding" the conference feature.
It is about the rules provided in callerprefs. If the caller provides no
preferences, then all
> If there is both a "regular" contact and a "conference" contact
registered, then both may be tried. Even if the conference contact has a
lower q-value, it may get tried
> Of course this callerpref feature could be accompanied by some additional
callee specified scripting to prevent this from happening. But again, that
isn't something Alan
> In the case of voicemail things work more reasonably. If the q-value of
the voicemail contact is set lower than that of the regular UA, then in
absence of a callerpref to
> the contrary, the regular ua will be tried first, and the voicemail will
be tried if the other fails. This is exactly what you expect in this case.
And then, an
> Accept-Contact for voicemail will cause voicemail to be tried first,
failing over to the regular phone, while a Reject-Contact of "!voicemail"
will only try voicemail.
> Yes, but in scenario Alan seemed to be proposing, this logic would need to
be in the proxy server. Does something like CPL have the capability to deal
with this scenario?
> In this kind of adhoc case, wouldn't it be more likely that B will simply
call A. A will answer (as a separate call) and then transfer the caller into
the conference if
> There may be some cases when what Alan is proposing would be helpful. But
it is going to require explicit support at the calling end to initiate a
call this way. Providing