Yes, that is of course the prefered solution and this are
the normal procedure how this ad-hoc conference will be
activated..
But like in the other thread we discuss in also here is the
problem with a dumb phone, in the worst case only compliant
to RFC 3261 and only able to handle 1 dialog at the same
time. And for this our proposal is, to develop a fallback
basing on sending a re-INVITE in the original dialog. That
minimizes the requirements on the invited user and maximizes
the chance the conference will be established.
Of course the normal case is that there are smart phones
compliant to all RFCs needed for the service. But I think
it's useful to have at least a fallback for the case that B
does not fulfil all the requirements needed for a service
you're providing to A. Or simply doesn't want to accept a
2nd INVITE.
BR, Martin
> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:pkyzivat cisco.com]
> Gesendet: Donnerstag, 13. September 2007 16:00
> An: Hülsemann, Martin
> Cc: jerry.yinyahoo.com; alansipstation.com; sipietf.org;
> dragealcatel-lucent.com; mary.barnesnortel.com
> Betreff: Re: AW: AW: AW: [Sip] Extension of conference
procedures
>
>
> Why not simply REFER the focus to send an
INVITE/Replaces to
> the calls
> with existing dialogs?
>
> Paul
>
>
> Huelsemann, Martin wrote:
> > Hi all,
> >
> > thanks for your interest in this, but I think my
question
> pointed in a
> > littlebit different direction.
> >
> > I think the procedures to start a centralized
ad-hoc
> dial-out conference
> > are fine, you send an INVITE to the conference
factory to start the
> > conference, and then you send REFERS to the focus
referring
> INVITEs to
> > the other participants. Even better is an INVITE
to the
> confernce with a
> > URI list of the participants who shall be invited
to the
> conference,
> > because this needs lees messages.
> >
> > The problem is the INVITE from the focus to the
> participants. As this is
> > an ad-hoc conference, it's clear that the invited
user is
> already in a
> > dialog with the inviting user, and because of this
it
> depends on the
> > invited user if he accepts the invitation to the
> conference, or if he
> > e.g. just answers with a 486. The proposal is to
trigger a
> re-INVITE in
> > the original dialog by using the "?"
mechanism to transfer
> the dialog ID
> > of the original dialog to the focus, as this
wouldn't cause
> a 2nd dialog
> > at the invited UE and therefore means the fewest
> requirements on the
> > invited user.
>
>
> > To mee it seems that the Join header cannot solve
this
> problem. If you
> > include the Join header in the INVITE to the
focus, that
> means you want
> > to join some dialog at the focus which doesn't
exist.
> > If you include the Join header also using
"?" in the header
> portion in
> > the Refer-to header of a REFER or in the header
protions in the URI
> > list, this means the focus shall generate an
INVITE
> including a Join
> > header and sends this to the invited user. The
invited user
> then would
> > have to start the procedures to include the focus
in the original
> > dialog. If he accepts the 2nd INVITE and is
compatible to RFC3911.
> > Triggering a re-INVITE because of the Join header
part in
> the Refer-to
> > header to me seems to be not in accordance with
RFC3911.
> > Because of this I don't think the usage of the
Join header
> can solve the
> > problem of 2 dialogs at the invited user in case
of an
> ad-hoc dial-out
> > conference.
> >
> > BR, Martin
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > *Von Jerry Yin
[mailto:jerry.yinyahoo.com]
> > *Gesendet Mittwoch,
12. September 2007 22:14
> > *An Alan
Johnston
> > *Cc sipietf.org;
DRAGE, Keith (Keith); Mary Barnes
> > *Betreff Re: AW: AW:
[Sip] Extension of conference procedures
> >
> > Hi Alan and Peili,
> >
> > Thanks for your responses. I saw Alan's RFC
before. I
> revisited it
> > today briefly. But I still can't find the
solution I am
> looking for.
> > Basically in your RFC, even for the ad-hoc
conference, the user
> > always starts with calling the conference
server first.
> What I am
> > looking for is that the user puts two (or
more) lines
> on hold, then
> > he decides to conference them together in a
conference room.
> >
> > The solution I proposed will allow user to
have a
> smooth experience
> > to conduct a conference in a conference room,
if the
> server supports
> > this feature. If server does not support it
then it
> will be a local
> > 3way conference on the phone that most SIP
phones
> support. The UI
> > design and user experience will be exactly the
same in
> both the cases.
> >
> > As to the RFC3911, I agree that it didn't say
> explicitly that the
> > Join header can be used in a re-Invite. I also
admit that my
> > proposal does not interpret the Join header as
the RFC
> defines. But
> > if it works, then we might want to
re-interpret the defintion of
> > Join header? Or we might want to consider
introducing a
> new header
> > for this purpose!
> >
> > To answer your question, if the join does not
match an existing
> > dialog, then according to the RFC 3911, it
will be ignored.
> >
> > BTW, I saw the RFC 4579 depends on out-dialog
REFER.
> Would it be a
> > security concern?
> >
> > thanks,
> > Jerry
> >
> >
> > */Alan Johnston <alansipstation.com>/*
wrote:
> >
> > Hi Jerry,
> >
> > The use of a Join header field in a
re-INVITE in
> your system is
> > problematic. RFC 3911 does not seem to
specifically
> rule it out but
> > implies that it can only be used in a
initial
> (dialog creating)
> > INVITE.
> > Also, the error response generation
described in
> RFC 3911 can
> > not be
> > applied to a re-INVITE scenario, so I'm
curious
> what you do if
> > the Join
> > does not match an existing one.
> >
> > There are solutions in RFC 4579 for
transitioning
> conferences to
> > and
> > from point to point sessions that may be
of use to you.
> >
> > Thanks,
> > Alan
> >
> >
> > Jerry Yin wrote:
> > > I think there are two ways to invoke
a
> conference. One is to
> > invoke
> > > the conference by the conference
server. The
> other is ad-hoc
> > > conference invoked by the
participants. The
> > > draft-ietf-sip-uri-list-conferencing
was trying
> to solve the
> > problem
> > > by initiating a conference from the
server.
> > > Here's what I think for the ad-hoc
conference.
> > > Participants: A calls B (a UA or a
conference
> room) and put B
> > on-hold,
> > > and then A calls C. Now A presses
the conf button.
> > > 1. If B has a conference room url, A
will
> transfer C to B (by
> > REFER),
> > > as some of you discussed already. It
actually is
> supported by
> > some
> > > companies already as I know.
> > > 2. But if B is a UA, when the conf
button is pressed, the
> > only SIP
> > > messages send out by A is the
re-Invite
> (off-hold) to B since
> > most SIP
> > > phones support 3-way conference
locally. Then A
> will do the
> > audio
> > > mixing locally. So far I didn't find
any
> solution to transfer
> > the
> > > local 3-way conference to a
centralized conference yet.
> > Currently in
> > > our system, we adopted the
"Join" header
> (RFC3911). When A
> > sends the
> > > re-Invite to B, it also includes a
Join header
> contains the
> > C's dialog
> > > info. The B2B server will translate
the Join to
> a centralized
> > > conference. It will Invite C with a
Replace
> header to replace
> > the
> > > session between A and C. C will
sends a BYE to
> A. The server
> > will
> > > update the media to A and B
(reInvite). Then all three
> > parties are in
> > > the centralized conference room.
> > > I hope the new RFC for conference
also capture
> the behavior
> > described
> > > in 2. Whether it's Join header or
something
> else. The user
> > should be
> > > able to call someone first and then
decided to setup a
> > conference.
> > > Jerry
> > >
> > > */Jeroen van Bemmel /* wrote:
> > >
> > > Concretely, would we be looking at
something like
> > >
> > >
> >
> sip:b-partyprovider.com?From=sip%3ca-partyprovider.com;tag=x
> &To=sip:b-partyprovider.com;tag=y&Call-ID=i&CSeq=1234&Ro
ute=rrr&body=
> > > with proper session versions
etc>
> > >
> > > in order to help the conference
server fake a
> reINVITE towards B?
> > >
> > > RFC3261 provides some guidance on
the types of
> headers that
> > elements
> > > might accept as part of a URI.
Specifically, it
> states in 19.1.5:
> > > "An implementation SHOULD NOT
honor these
> obviously dangerous
> > header
> > > fields: From, Call-ID, CSeq, Via,
and Record-Route."
> > >
> > > I believe the usage that was
foreseen for this
> mechanism (as
> > > illustrated
> > > by some of the examples in RFC3261)
was to
> provide some context
> > > for the
> > > request, such as Subject and
Priority fields. In
> other words,
> > > optional
> > > information that might help the
receiver
> understand the context.
> > >
> > > The above are not different
semantics for
> headers in a URI
> > (concept
> > > remains: form a new request based on
the URI,
> inserting the
> > headers),
> > > but it does imply a deviation from
the basic SIP
> call model
> > > (basically a
> > > way of encoding dialog state in a
SIP URI, and
> sending that to
> > > another
> > > element such that it can reconstruct
that state
> and assume the
> > > role of
> > > the party which shared the state).
> > >
> > > Apart from the fact that this
approach will fall
> short for SDP
> > > related
> > > state: is this desirable?
> > >
> > > Regards,
> > > Jeroen
> > >
> > > Mary Barnes wrote:
> > > > RFC 4244 (History-Info) also
uses this
> mechanism to capture the
> > > Reason
> > > > and Privacy associated with the
URIs that are
> included as part
> > > of the
> > > > History-Info header. My
understanding is that
> it's really
> > just a
> > > nifty
> > > > way to compactly reuse existing
headers (i.e.,
> it makes the
> > > History-Info
> > > > much more compact as I didn't
need to define additional
> > > parameters for
> > > > the header, but could rather
reuse the
> existing ones, whose
> > existing
> > > > semantics perfectly
applicable). I do think
> that the use of the
> > > headers
> > > > that might be escaped using
this mechanism
> should be explained,
> > > > particularly in cases where you
might be
> extending the use of
> > > existing
> > > > headers as I did for the
Privacy header.
> > > >
> > > > Mary.
> > > >
> > > > -----Original Message-----
> > > > From: Peili Xu [mailto upeil
igmail.com]
> > > > Sent: Wednesday, September 05,
2007 10:41 AM
> > > > To: DRAGE, Keith (Keith)
> > > > Cc: sipietf.org
> > > > Subject: Re: AW: AW: [Sip]
Extension of
> conference procedures
> > > >
> > > > Yes, It's vague in RFC3261. I'm
only aware of
> the usage in
> > REFER
> > > now.
> > > > It'll be good to clarify the
semantics in the usage in
> > url-list.
> > > >
> > > > 2007/9/5, DRAGE, Keith (Keith)
:
> > > >
> > > >> So this is a convenient way
to bring us back
> to the other half
> > > of the
> > > >>
> > > > issue which we do not seem to
have discussed
> yet. When the
> > > syntax was
> > > > defined that allowed ?headers:
> > > >
> > > >> Headers: Header fields to
be included in a
> request constructed
> > > >> from the URI.
> > > >>
> > > >> Headers fields in the SIP
request can be
> specified with the
> > > >>
> > > > "?"
> > > >
> > > >> mechanism within a URI. The
header names and
> values are
> > > >> encoded in ampersand
separated hname = hvalue
> pairs. The
> > > >> special hname
"body" indicates that the
> associated hvalue is
> > > >> the message-body of the SIP
request.
> > > >>
> > > >> What usage did the SIP WG
envisage for this,
> and thus what
> > > semantics
> > > >>
> > > > did they define for that
usage.
> > > >
> > > >> Is it appropriate to assign
new semantics to
> such usage?
> > > >>
> > > >> Regards
> > > >>
> > > >> Keith
> > > >>
> > > >>
> > > > Note: I snipped the rest of
this thread as it
> was getting
> > really
> > > LONG.
> > > >
> > > >
> > > >
_______________________________________________
> > > > Sip mailing list
> https://ww
w1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW
development of the core
> SIP Protocol
> > > > Use sip-implementorscs.columbia.edu for questions on
> > current sip
> > > > Use sippingietf.org
for new developments on the
> > application of sip
> > > >
> > > >
> > >
> > >
> > >
_______________________________________________
> > > Sip mailing list
> https://ww
w1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of
the core SIP Protocol
> > > Use sip-implementorscs.columbia.edu for
> questions on current sip
> > > Use sippingietf.org for new
developments on the
> application
> > of sip
> > >
> > >
> > >
> >
>
------------------------------------------------------------
--
> ----------
> > > Check out
> > >
> > > the hottest 2008 models today at
Yahoo! Autos.
> > >
> >
>
------------------------------------------------------------
--
> ----------
> > >
> > >
_______________________________________________
> > > Sip mailing list
> https://ww
w1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of
the core SIP Protocol
> > > Use sip-implementorscs.columbia.edu for
> questions on current sip
> > > Use sippingietf.org for new
developments on the
> application
> > of sip
> >
> >
> >
>
------------------------------------------------------------
--
> ----------
> > Be a better Globetrotter. Get better travel
answers
> >
> <http://us.rd.yahoo.com/evt=48254/*http://answers.ya
hoo.com/di
>
r/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzB
HN
>
lYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U
-?
> link=list&sid=396545469>from
> > someone who knows.
> > Yahoo! Answers - Check it out.
> >
> >
> >
>
------------------------------------------------------------
--
> ----------
> >
> > _______________________________________________
> > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol
> > Use sip-implementorscs.columbia.edu for
questions on current sip
> > Use sippingietf.org for new developments on the
application of sip
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|