[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] Thoughts on the conf-info package
Jonathan,
See my comments below.
Alan.
> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> On Behalf Of Jonathan Rosenberg
> Sent: Monday, June 24, 2002 3:38 PM
> To: Paul Kyzivat
> Cc: Orit Levin; 'Anders Kristensen'; Rohan Mahy; sipping@ietf.org
> Subject: Re: [Sipping] Thoughts on the conf-info package
>
>
>
>
> Paul Kyzivat wrote:
> > Jonathan,
> >
> > This is an interesting proposal. I think I like it, but
> there are some
> > things I don't understand.
>
> Mee too ;)
>
> Inline.
>
> >>THe other obvious external characteristic of the conference is the
> >>"mixing" characteristic, which is that all dialogs
> connected to that
> >>URI will have their media mixed and distributed.
> >
> >
> > What do you mean by "that URI"? Do you mean the Contact URI, or the
> > request URI that was used to establish the call, or what?
>
> "that URI" is the one that is for the conference.
>
> Let me give an example. A calls B. A's INVITE looks like, in part:
>
> INVITE B
> Contact: sip:A@1.2.3.4
>
> B accepts and sends a 200 OK. A then calls C, and then decides to
> conference them both together. It acts as a local mixer. It
> would send a
> re-INVITE to B:
>
> INVITE B
> Contact: sip:now-a-mixer@1.2.3.4
> Allow-Events: conf
> Resource-Characteristic: mix
>
> The URI for the conference is sip:now-a-mixer@1.2.3.4.
>
>
This is essentially A acting as a 3pcc to establish a new session (the
conference) with B.
This is very close to what I was thinking, but I recall Henning talking
at the interim meeting about a conference URI (which is an AOR instead
of a Contact). It is also very similar to your original join URI passed
around in the "To-Join" header. If A's URI is sip:A@here.com then the
conference URI would be sip:now-a-mixer@here.com, which probably
resolves to the Contact sip:now-a-mixer@1.2.3.4 which may be A's UA if
it is mixer, or may be A's conference bridge.
Within a dialog, A could make the transition using a re-INVITE and the
change of Contact (and probably SDP) as you show. However, to add in
the third (or fourth...) party, a conference URI which is an AOR would
be needed. A could send a REFER to D with the conference URI as the
Refer-To, or it could send the REFER to the conference bridge with the
Refer-To as D, or it could act as a 3pcc and send an INVITE to D using
the bridge SDP and Contact.
Of course, the conference URI must be registered, but I think this is a
small price to pay for the generality you get.
I have some call flows showing this that I plan to include in the next
SIP Service Examples I-D.
> >
> > This could be a "normal" sip phone that happens to have mixing
> > capabilities. It may also be able to handle independent concurrent
> > calls to the same address. If so, what happens when one of
> the calls
> > converts to a conference? Is there some way for another
> party to call
> > in to that conference without being interpretted as a request for an
> > independent call?
>
> Sure; it would re-INVITE and change the Contact address ONLY on those
> calls that are now getting mixed together.
>
>
> >
> > I suppose that when the call converts to a conference, a unique
> > conference address could be used in the Contact header.
>
> Right!
>
> >But that would
> > be odd - normally that wouldn't be
> > used to initiate a new call to that UA. Or it could include
> a Reply-To
> >header with a conference URL. Maybe somebody could be
> expected to try
> >that.
>
> Well, we've wandered into an old problem that has arisen time
> and time
> again - how to direct a new call to a UA *instance* rather
> than a user?
> Its arisen for transfer too. Our current "best practice" for
> that is to
> address it to the address in the To/From but use caller prefs
> to target
> an instance. This is frought with problems, and doesn't work
> generally.
> We need to solve that problem generally, and then use that
> solution here
> too.
>
>
> -Jonathan R.
>
>
> --
> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> jdrosen@dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PH: (973) 952-5000
> http://www.dynamicsoft.com
>
>
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current
> sip Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP