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

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

Commenting on my own message.

What is the difference between a proxy server that
forwards all calls in it's domain to a single UA,
plus a UA that accepts all usernames sent to it vs
a UA that accepts all usernames sent to it?
Answer - nothing.

Just allow your UA to have a DNS hostname, and have 
the proxy route calls to you (ie [email-masked]).
No need to register.  The existing proxy doesn't know,
and doesn't care, that the next hop isn't a proxy server,
it's just the next hop.  

Brian

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, September 11, 2003 4:32 PM
> To: 'Matt Guertin'; [email-masked]'
> Subject: [Sip] RE: Cannot REGISTER Ad Hoc SIP Conference?
> 
> 
> Well, our proxy server allows rule based routing with regexps.
> I've seen others that have similar capabilities.
> I've also seen registrars that can be configured to accept
> certain classes of registrations without username/password challenges.
> This is BCP stuff, not specification work, but we might have to
> do it.
> 
> One easy way for you to solve your problem is to implement your
> own proxy server which does routing the way you want it.
> Then, the existing proxy servers can have simple routing for
> "conferencing.example.com", for example.  Nearly every proxy
> can handle that.
> 
> Brian
> -----Original Message-----
> From: Matt Guertin [mailto:[email-masked]]
> Sent: Thursday, September 11, 2003 4:12 PM
> To: 'Rosen, Brian'; [email-masked]'
> Subject: RE: Cannot REGISTER Ad Hoc SIP Conference?
> 
> 
> Hi Brian, 
> Our product has a web-based interface for setting up 
> conferences. If you select that you want to start a conference 
> "now" we declare it to be an "ad hoc" conference.  But we 
> still make the user specify an end time.  This is the main, 
> and I think only, difference between your definition and ours.  
> I agree about conference-uris, it doesn't really matter how 
> they come into existence, for this discussion, once you have 
> one, you have one.  Each instance of a conference has a unique 
> conference uri.  All of this is clear in the specs. 
> The problem is that let's say, we send out email saying that 
> conference so-and-so is starting now (or at 1:00PM - it 
> doesn't really matter). There is a SIP uri in the email 
> invitation.  And at the specified time, the caller uses 
> his/her softphone to dial in.  But the proxy server needs 
> to understand that this sip uri needs to go to the conference 
> bridge.  The problem we have right now, is that we don't 
> control the proxy servers.  So how can we follow the standards 
> (or draft standards) and still get this to work?  I don't know 
> of any sip proxy server which allows the flexibility you 
> describe (i.e., rule-based / policy-based routing).  Trying to 
> register the conference-uri's didn't work because of 
> authentication - each conference uri can't have a unique 
> username / password associated with it - the overhead would 
> kill us.  I don't see how the REFER style would work for large 
> conferences, and we use a participant dial-in model, anyway. 
> I thought that the proxy servers would be smart enough to 
> understand that the contact fields can be used as aliases 
> when the 'isfocus' flag is used.  But unfortunately not. 
> This all boils down to resource allocation.  Since audio ports 
> are a valuable resource, we can't tie them up unless we know 
> they are being used.  Hence, the need for scheduling.  If a 
> conference goes over its allocated time slot, it keeps going 
> as long as there are audio ports available.  If someone else 
> scheduled a conference right after yours and there are too 
> few audio ports, the expired conference is stopped so that the 
> next group can use the audio ports.  What if you had an 
> important conference scheduled, and had some important people 
> on the call, but you couldn't start the conference because the 
> people in the earlier conference didn't want to end theirs? 
> It's a lot like a conference room scheduling program, there's 
> the rooms and there are people who can fit in the room, and 
> there are time ranges.  Scheduled audio conferences are 
> becoming extremely popular and going to be around for a long 
> time, because they are more practical in most business 
> applications than open-ended and ad hoc conferences. 
> -----Original Message----- 
> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: Thursday, September 11, 2003 2:58 PM 
> To: 'Matt Guertin'; [email-masked]' 
> Subject: RE: Cannot REGISTER Ad Hoc SIP Conference? 
> 
> 
> Matt 
> Generally, when we say "ad hoc conference", we mean something that 
> happens at the spur of the moment; it's not scheduled. 
> A scheduled conference is something else. 
> Really, there is very little difference, at least in terms of how 
> the mechanisms work: 
> 1) You go to the conference factory to get a conference uri 
> 2) You either hand it out, and people INVITE themselves in, 
> or you REFER people to the conference-id 
> The important point is that the conference factory uri is well 
> known, and generally doesn't change, but the conference-uri 
> is different for every conference. 
> From the point of view of a participant, a conference uri is 
> just a uri.  How it gets it (by INVITE to conference factory 
> uri, or email, or "good guess", doesn't matter.  It has one. 
> The crux of your question, as stated, was how the proxy server 
> routes calls.  I gave one answer, you have another.  In mine, 
> the proxy server has a routing rule based on a pattern match 
> on the uri.  For example, it might say that any username starting 
> with "bridge2-" is routed to a particular conference bridge. 
> Then conference uris handed out by the conference factory might 
> be something like "[email-masked]", but they 
> could also look like "[email-masked]". 
> Your suggestion has the conference factory registering each uri 
> it hands out.  That also will work.  Hybrids will work. For example, 
> I could register "[email-masked]" as an alias for 
> "[email-masked]", if my proxy server allowed 
> aliases.  I don't think that we want to have locked down 
> specifications 
> for this kind of thing, at least right now.  I think a stand-alone 
> conference server, which was not a proxy server, might want to be 
> able to register every conference, but it might want to be 
> configurable 
> so that such a mechanism was controllable. 
> I'll point out that registration isn't particularly desirable for 
> what I call an ad-hoc conference, primarily because I don't want to 
> incur the registration delay between the time I press the 
> "CONF" button 
> on my phone, and the time the party I'm calling's phone rings. 
> One thing I'm curious about.  Have you ever used a conference bridge, 
> or service, that literally kicked you out at the scheduled time? 
> They are pretty uncommon, and, in my own experience, frustrating.  
> Meetings that conclude on schedule are pretty rare, around 
> here anyway. 
> Nearly every conference service I've ever used does not enforce a 
> time limit.  I've seen some video bridges that do that.  Not a matter 
> for standardization of course; if you want to build one that way, I 
> don't want to stop you :) 
> Brian 
> -----Original Message----- 
> From: Matt Guertin [mailto:[email-masked]] 
> Sent: Thursday, September 11, 2003 2:36 PM 
> To: [email-masked]'; [email-masked]' 
> Subject: Re: Cannot REGISTER Ad Hoc SIP Conference? 
> 
> 
> 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]
> t.comms.marcon
> 
> i.com... 
> > 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 
> > 
> 
> _______________________________________________
> 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: Tue, 16 Sep 2003 11:52:19 -0400

I think I now understand what's happening.  We can get this to work by not
using authentication when REGISTERing the generated Conference URIs.  But
that is not a practical solution because we are selling a secure product to
customers who will be using SIP Proxy Servers with security/authentication
enabled.  We would *like* to use the REGISTER technique because we can then
leverage presence servers to tell SIP users (who SUBSCRIBE) that the
conference is "active".  But this is more like a nice-to-have, anyway.
We can also get this to work if we don't perform REGISTER requests for the
generated conference URIs, and the Proxy Server is configured to forward
these to the Conference Bridge (as you just described). But then: 1) why
even go through the effort of generating Conference URIs? 2) what if the
customer's SIP proxy server doesn't have this capability or they want the
"security" of having all INVITE requests authenticated against registered
SIP entities (...both of which seem highly unlikely)?  and 3) We lose the
presence capability.

Bottom line is this: now that I see how everything actually works in the
_real_ world (so to speak), I just don't understand the logic in the SIP
conferencing draft specs about INVITE requests with generated Conference
URIs.  They could never really work in a secure business environment,
because they would never make it past authentication.  Therefore, all INVITE
requests MUST be for long-lived URIs (such as the Conference factory URI),
_OR_ the SIP proxy servers must be configured to allow routing based on 1)
prefix, or 2) domain/realm, or 3) some combination.  Am I missing something?
Isn't there some way to securely register SIP Conference URIs?

-Matt.

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