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

From: Orit Levin <[email-masked]>
Date: Wed, 24 Jul 2002 16:24:44 -0400

I think, that as a result of the examination of the proposed different
approaches,  we need to understand for which of the conferencing scenarios
the standardization is MUST and for which alternative
recommendations/examples would suffice (with no interoperability
compromised!).

One of the main advantages of the common "SIP Conferencing Framework" is
that, regardless the way you learn about /establish /route towards
/participate in a Conference, it should be possible to host all different
participants in a common conference.

From my perspective, one of the goals of the upcoming "SIP Conferencing
Framework" draft is to start systemizing these methods.

Orit Levin
Chief Architect
RADVISION Inc.
Tel:  +1.201.689.6330

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 12:32 PM
To: [email-masked]
Subject: Re: [Sipping] Conference URIs and Caller Prefs

>
>Date: Wed, 24 Jul 2002 10:55:09 -0500
>To: Paul Kyzivat <[email-masked]>, [email-masked]
>From: Alan Johnston <[email-masked]>
>Subject: Re: [Sipping] Conference URIs and Caller Prefs
>Cc: Ranjit Avasarala <[email-masked]>, 
>[email-masked], [email-masked]

Paul,

Thanks for your feedback.  See my comments below.

Thanks,
Alan Johnston
sip:[email-masked]

At 12:31 PM 7/18/2002 -0400, Paul Kyzivat wrote:

>[email-masked] wrote:
> >
> > 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.
>
>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.

This is not quite true.  See below.

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

A UA interpreting caller preferences tags is not a hack.  In my view, it is 
as important as the proxy interpretation which is more commonly associated 
with this draft.  It is specifically described in Section 2:

"Furthermore, Contact headers in requests and responses that establish a 
dialog can also contain these parameters. That allows a UA in a dialog to 
indicate its feature set to its peer. For example, by including the 
"feature" feature tag with value "voicemail" in the 200 OK to an INVITE, 
the UAS can indicate to the UAC that it is a voicemail server. This 
information is useful for user interfaces, as well as automated call 
handling. "

(By the way, this is one of a number of places that incorrectly refer to 
the feature tag as "feature" instead of "features" as it is formally 
defined in Section 7.3.)

Similarly, if a 200 OK contains a Contact with a conference feature tag, it 
knows it is connected to a bridge and can perhaps automatically try to 
SUBSCRIBE to the bridge for the conference info package, for example.

I am still convinced that this is a good use of caller prefs and
conferencing.

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

I had assumed in my example that the AOR URI was the same for the UA and 
the bridge so as to avoid any URI configuration issues.  However, this 
would lead to the problems Paul describes.

I'm no longer so sure that this is a proper use of caller prefs.

It seems that there must be some sort of minimal configuration of the 
conference URI in the UA to enable ad hoc conferencing (for example as 
shown in Sections 2.9 and 2.10 in
draft-ietf-sipping-service-examples-02.txt)

> >
> > But then, this logic can be applicable to any other "feature" tag in
> > 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.
>
> >
> > 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.
>
>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?
>
> >
> > * 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.
>
>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

_______________________________________________
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