Subject: RE: [Sip] Cannot REGISTER Ad Hoc SIP Conference?

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Sep 2003 09:05:16 -0400

We make this work roughly (code is evolving) the following way:
	We provision (actually, it's learned) the name of the local
		conference factory uri.  This is a fixed uri, and is
		local to the domain of the conference host.
	The conference host registers with this well known
		address.  It is an actual "user" in the system.
	We start with a 1on1 call, between the first two parties
	When we add the third party, the UA initiating this action
		sends an INVITE to the conference factory uri.
	The conference host returns a Contact header with
		a unique conference uri.  The conference uri is
		constructed using a pattern known to the outgoing proxy
	The UA initiating the conference REFERs all three parties to
		the conference using the conference uri
	Invites with a username matching the pattern are routed to
		the conference host

Brian

> -----Original Message-----
> From: Matt Guertin [mailto:[email-masked]]
> Sent: Wednesday, September 10, 2003 11:20 AM
> To: [email-masked]
> Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference?
> 
> 
> I read through all the SIP specs that I know of, and believe to have
> implement our SIP Conference "focus" correctly.  We have what 
> is sometimes
> referred to as a SIP Conference Bridge Marshal Server (in vocal speak
> anyway).  When I go to do a REGISTER request, the 
> authentication fails,
> because the username/password does not match with the 
> ConferenceURI.  I can
> only register with ConferenceURIs which have 
> usernames/password provisioned.
> This doesn't work for Ad Hoc conferences, and even for 
> scheduled conferences
> for that matter.  It is unacceptable in a practical 
> application to send mail
> to an administrator every time a new conference is scheduled 
> to generate a
> username/password for the conference.  The administrator may 
> not get around
> to adding the new username/password for hours or even days.  
> Am I missing
> something?  We are using the contact field the way it is 
> spec'ed in the
> conference framework draft (ie., the isfocus flag is set).
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Matt Guertin" <[email-masked]>
Date: Thu, 11 Sep 2003 14:33:34 -0400

Hi Brian,

Thanks for taking the time to respond to my posting. What you describe
sounds like it will work for very small conferences.  However, we support
"open-ended" conferences, where anyone who knows the "conference-id" can get
in, even if the host does not explicitly invite them. In addition, for a
scheduled conference, the host can send out invitations to dozens of people,
knowing that only maybe half will be able to participate. But the real
"gotcha" here is that the conference always has an end time.  For example,
if there is a 1:00PM sales meeting, it will go until maybe 2:00PM.  Then
that's it.  There may be another one tomorrow, or next week at the same
time, but the conference is over until then.  You wouldn't want to tie up
the ports on a conference bridge for a conference that's over.  You would
let someone else use them for another conference, and/or the earlier host to
use them again for some other meeting.

I don't see why the SIP proxy server can't just forward the requests for the
additional URIs in the contact field.  That would solve all the problems
associated with "time-based" conferences.  1) The SIP proxy would know that
it is dealing with a conference bridge, which will have many "aliases" for
conferences. 2) The conference bridge is still looked at as a single user
agent, with a single username and password.  For example:

REGISTER sip:10.1.4.35:5060 SIP/2.0
From: sip:[email-masked]:5060
To: sip:[email-masked]
Contact: <sip:[email-masked]:5060>;isfocus
Contact: <sip:[email-masked]:5060>;isfocus
Contact: <sip:[email-masked]:5060>;isfocus
Call-ID: 12707648587750000@SONEXIS-C723CFA
CSeq: 85 REGISTER
Content-Length: 0
Expires: 1200
Proxy-Authorization: Digest username="2038",realm=...

The above might represent registering three concurrent conferences going on
at a conference bridge called 2038.  Of course, the conference bridge would
only register "active" conferences, and unregister them when they are over.
And when someone issued an INVITE request to the conference bridge it would
be responsible for placing the participant in the correct conference.

-Matt.

"Rosen, Brian" <[email-masked]> wrote in message
news:[email-masked]...