Subject: [Sipping] Conf stuff in natann draft

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Apr 2004 08:59:14 -0700

Their is a bit of weird inconsistency in the having the parameters that are
passed to the __sip-conf service invocation embedded in the user portion.

In the annc and dialog service, there are no parameters in the user portion
of the URI. Yet in the conf service, the conf id is embedded in the user
portion. 

I think this is wrong. It should be

[email-masked];conf=uniqueIdentifier

This makes it feasible to specify routing rules for proxies that correctly
get all the traffic for the service to the media server. Particularly if the
media server is behind a NAT.

Could you change the draft to make the conf service invocation consistent
with the annc and dialog?

Cullen

_______________________________________________
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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Apr 2004 10:29:19 -0700

Thanks for the fast response. I'm lost on how you imagine this working - I
think you will need to walk me through it.  Let's say the domain is
cisco.com and I have two media servers ms1.cisco.com and ms2.cisco.com. And
my conference ID's are 6 digit numbers.

Are you suggesting that ms1.cisco.com and ms2.cisco.com know that
__sip-conf=1 belongs to ms1 and __sip-conf=2 belongs to ms2 and they both
send a REGISTER message to the proxy and ms2 registers
__sip-conf=[email-masked] with a contact pointing to ms2.cisco.com? I don't see
how they could register all the possible conference Ids in any useful way.
Mostly because the message needs to routed to the ms before the ms will
create the conference and conference needs to be created before it's id can
be registered and the registration needs to happen before the routing and
thus we have a circular loop of dependencies in time.
 
I'm proposing that the proxy route to the correct media server by having the
host portion of the URI be ms1.cisco.com or ms2.cisco.com

On 4/12/04 9:28 AM, "Andy Spitzer" <[email-masked]> wrote:

> Cullen,
> 
> The reason for having the conf id as part of the user part, was because
> unlike the other services (annc, ivr, and dialog), conferencing is not
> stand alone.  With annc, ivr, and dialog, each session is unique in
> independent.  With conferencing, however, multiple sessions make up a
> particular conference.
> 
> As such, a particular conference must live on a particular media server.
> All participants into that conference must reach the same media server.
> By placing the conf id in the user part, it makes the conference look like
> a user on a particular media server, and as such any proxy can use the
> correct routing rules for users in order to reach the correct media server
> assigned to that conference.  Just the same way they would route users to
> a particular endpoint.
> 
> If the conf id was done as you describe, it would mean proxies would have
> to look into the parameters to determine which conference was being
> requested in order to determine which media server to INVITE.  We didn't
> want to force proxies to do that, so it was decided the user part was more
> proxy friendly.
> 
> Your approach is certainly feasible, and was indeed originally
> considered.  I believe it may be possible to support both simultainously.
> 
> --Andy Spitzer
> [email-masked]
> 
> On Mon, 12 Apr 2004 08:59:14 -0700, Cullen Jennings <[email-masked]>
> wrote:
> 
>>

---

From: Alan Johnston <[email-masked]>
Date: Mon, 12 Apr 2004 14:57:55 -0500

Cullen,

You are right - there is an inconsistency.  However, if we make netann 
consistent as you propose (and previous versions of netann use exactly this 
format), then netann becomes inconsistent with the conferencing framework 
and the rest of the conferencing work.

The conferencing framework assumes that the conference ID is embedded in 
the user portion of the URI, not in URI parameters.

Can you explain your NAT issue with this approach?

Thanks,
Alan Johnston
MCI
sip:[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Apr 2004 20:04:08 -0700

I think I understand the confusion. The name of the focus should have the
identify the conference by the user part. However, this is very different
than the service invocation that the focus uses to control the media mixer.
The term __sip-conf is a bit of a red hearing __sip-mixer would be more
appropriate. 

I think that sip:[email-masked] is a perfectly reasonable AOR for a
conference. Note my choice of the word AOR and yes this should be routable
by a proxy. Now this focus is controlling several media servers. One might
be doing video, another audio, and so on. There is certainly an argument to
be made that Megaco might be a better protocol for this but the netann draft
is about using SIP to perform service invocation on these devices. Let's say
that video is done ms1 and audio on ms2 for the same device. The focus needs
to be able to send a SIP service invocations to a proxy and get it routed to
the appropriate ms.

If I was generating a URL to give out externally to join a certain
conference. I might give [email-masked] to folks that were not the
moderator but give [email-masked] to folks that did have moderator
privileges. Perhaps it is the type of conference that does not start mixing
until the moderator arrives. Now these are both valid names to reach the
same focus and they will result in service invocation to add them to a
mixer. I would expect the conference ID in the service invocation to be some
completely other string that perhaps has a conference id of 1234 in it.
Presumable folks that were moderators and ones that were not would all be
going to 1234 on the audio mixer and perhaps some other id 4567 on a
separate video mixer. I want to be able to route to the audio and video
mixer via a proxy for firewall traversal and to make TLS work without
devices other than the proxy having a TLS certificate.

I'll give it all more thought but I don't see how to make it work with a
name like sip:conf=[email-masked] being sent to the proxy but I see how
to make it work if I send sip:[email-masked];conf=1234 even though
it is ugly. I'll think about more.

In summary, as the the netann draft nicely points out, I don't think I see
much of a relation between the external AOR that route to the focus and the
internal service invocation names that the focus sends to the mixer.

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Apr 2004 20:04:01 -0700

First of all let me say thank you for the very complete response. Few
questions inline. Also I put some of my reply to this in the my reply to
Alan's email. 

On 4/12/04 11:32 AM, "Andy Spitzer" <[email-masked]> wrote:

> Cullen,
> 
> It is expected that all sessions into the conference are controlled by an
> application server via third party call control.  The media servers and
> conf id's need not be externally visible.  The calls first go to the AS,
> then are sent to an MS for IVR (conference selection, record name, collect
> PIN, etc), then are sent to (possibly another) MS for the conference.  MS
> conf id's need not be seen externally, as the AS can re-write the messages
> any way it sees fit, acting as a B2BUA

Great, this is exactly the type of model I am interested in.

> 
> The application server responsible for controlling the conferences (and
> thus creating the conference ids) is the one which decides which
> conference lives on which MS.  It is up to the AS to REGISTER the
> conferences with the proxies if the conf ids are externally visible, as
> well as creating the conferences on the MS.

Agree the AS is picking the ids. In my case, I don't want to make the id
that are valid on the ms externally visible but I do need to route traffic
from the AS to the MS through a proxy because the MS is behind a firewall
and connecting over TLS.

> 
> You are correct in that the MS doesn't know the conf id's a-prioi.  The AS
> DOES know the conf id's, however.  It knows when they are supposed to
> start, end, etc., and as such it sends the appropriate REGSISTER methods

My problem is I can't do 3rd Party registration with TLS. The MS connects to
the proxy over TLS and needs to bind the TLS connection in the proxy to this
particular registration so 3rd party registrations don't work.

> to any proxies and any <create conference> MSCML commands to the
> appropriate MS.  It also removes the conferences from the proxies and MS's
> when the alloted time has expired.
> 
> The approach of externally visible ms1.cisco.com and ms2.cisco.com media
> servers does indeed mean you don't have to REGISTER each conference as a
> user, as the host name is used for routing instead.  That's a fine
> solution as well.  Even with that approach, something has to figure out
> the resources available on any given MS at a particular time, and divide
> up the usage across the MS's.  That is still in the realm of an AS.

Agreed it is still the AS making the decision about which resources to use
when. 

> 
> So, to walk through an example where the conf id is externally visible,
> the MS host name is not, and there is no initial IVR for users:
> 
> 1.  AS determines a 1 hour conference is to start at 10:00.  It assignes a
> conf id to the conference.  The conf id it picks is (to stick with your 6
> digit number example) 012345.
> 
> 2.  At 9:55 (just an example) the AS figures out which is the best MS to
> host this conference on.  It creates a control session by sending a
> <create conference> command to the appropriate MS (it picked ms1) to
> reserve resources:  sip:conf=[email-masked]
> 
> 3.  The AS then sends a REGISTER to the proxy for user conf=012345 on
> ms1.cisco.com

I assume here (based on next point) that you mean [email-masked] is
bound to the contact ms1.cisco.com.  Note the domain of the registrar was
cisco.com not ms1.cisco.com. If I was allocating ms1 and ms2 to this
conference, I assume I would give them different conference Ids and focus
would keep track of how they all mapped together.

> 
> 4.  As external calls arrive, they can go via the proxy to the correct
> MS.  External calls are directed to conf=[email-masked].  The proxy
> routes it to conf=[email-masked]
> 

Ok, I think it is this step where the 3rd party registration fails to work
for me. Rest of the steps make sense.

> 5.  At 10:05 the AS determines the conference is over.  It sends a BYE to
> the control session on the MS (the one it created in step 2).  This
> releases the conference resources and ends up sending BYEs to any
> remaining participant legs.
> 
> 6.  The AS removes the registration for user conf=012345 from the proxy.
> 
> 
> For more control over conference participants, usually all calls will go
> to the AS first, which will control an IVR session to decide which
> conference the caller is to be placed into, record the name, collect other
> info, etc.  Then it will place that user into the conference.
> 
> So, to walk through this example:
> 
> 1.  AS determines a 1 hour conference is to start at 10:00.  It assignes a
> conf id to the conference.  The conf id it picks is (to stick with your 6
> digit number example) 012345.
> 
> 2.  At 9:55 (just an example) the AS figures out which is the best MS to
> host this conference on.  It creates a control session by sending a
> <create conference> command to the appropriate MS (it picked ms1) to
> reserve resources:  sip:conf=[email-masked]
> 
> 3. External caller INVITES sip:[email-masked].  That hits the AS
> which selects an available IVR MS and collects the conference info from
> the caller via DTMF.  The AS sends an INVITE to the selected IVR MS:
> sip:[email-masked] and uses MSCML in INFO methods to play prompts,
> collect digits, and record names.  When the IVR session is over it sends a
> BYE to the IVR MS.
> 
> 4. The AS verifies the caller via PIN or whatever, and places the caller
> into the conference by sending an INVITE to the selected conference MS:
> conf=[email-masked]
> 
> 5. After the user joins the conference, the AS uses MSCML in INFO methods
> sent to the control leg created in step 2 to play the name of the new
> participant to the conference, as in "{recorded name} has joined the
> conference".
> 
> 6. As participants leave, they send BYE's to the AS, which sends BYE's to
> the conference MS.  It uses MSCML in INFO methods sent to the control leg
> to inform the other participants "{recorded name} has left the conference".
> 
> 7. At 10:05, the AS decides to destroy the conference so it clears all the
> sessions it has with the external users and the MS.
> 
> No external proxies need to know which MS's own which conferences, as that
> is the AS's responsibility.
> 
> --Andy Spitzer
> [email-masked]

Once again, thanks for the completely write up, it really did spell it out
clearly. 

> 
> 
> On Mon, 12 Apr 2004 10:29:19 -0700, Cullen Jennings <[email-masked]>
> wrote:
> 
>> 
>>>> get all the traffic for the service to the media server. Particularly
>>>> if
>>>> the

---

From: Andy Spitzer <[email-masked]>
Date: Mon, 12 Apr 2004 12:28:14 -0400

Cullen,

--Andy Spitzer
[email-masked]

---

From: Andy Spitzer <[email-masked]>
Date: Mon, 12 Apr 2004 14:32:06 -0400

Cullen,

--Andy Spitzer
[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Apr 2004 15:23:23 -0700

I'm going to try and take a second take at this this stuff.

Things I think we agree on ...

I assume we agree there will be multiple MS and multiple AS and we will use
a proxy to broker connections so that we only require the proxy to act as a
TLS server instead of every device being a TLS server.

There are conference names that link to a particular focus. They route to
the AS. We are not talking about conference names. This has nothing to do
with conference names.

The AS is trying to invoke a service (such as a mixer) on the DSP farm. We
are talking about the name of that service. There may be many mixers
involved with a single conference. I need a name that is routable to a
particular mixer via the proxy. The AS will pick which mixer it wants to
use. 

Where we disagree ....

That you can use 3rd party registration to tell a proxy to send invites down
some particular TLS connection. I don't think you can.

That my proxy needs to keep a binding for every instance of every service.
I'm fine with one biding per media service but not per instance of the
service. I think it is lots of state that is just not needed in a proxy.

That a mixer service is somehow different than other services. I don't see
how it is. An IVR system also has to run on a particular box. It may the
only box that has the voice prompts needed.

My proposal .... 

Lots of people will build systems differently. We should try and support
that. I want to be able to have a GRUU for the contact of a particular
service so I can reach it via a proxy over TLS. Others may want to hand
configure routes in the proxy. I don't care. However, the parameters for
service invocations should not be in the user part because that takes away
the ability to configure the name. An example of this is not being able to
use a GRU. There are other examples.

What I think people should do ....

Is there some reason that this mixer service is somehow different and needs
to have it parameters in the user part.  I just see why - help explain this.
Also help explain how we are going to make this 3rd party registration work.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Apr 2004 16:02:45 -0700

On 4/15/04 3:38 PM, "Andy Spitzer" <[email-masked]> wrote:

> Ahh, but for IVR, each and every CALL to the service is independant of
> every other call.  If call A went to MS 1, and call B went to MS 2, both
> would work just fine, they do not need to know about each other; they are
> independentof each other.

I don't think so. The AS needs to be able to say if it wants MS1 or MS2 even
in the IVR case. Perhaps it knows that one of them is busy. Perhaps one of
them does ASR and the other does not. I agree there are case were you media
servers are interchangeable but there are also cases where they are not and
the AS needs to be able to make the choice about that.

I agree with you that you for the mixer, you need to the the right one. I
just think that is true of all services.

I will make an incredible fluffy analogy here ... You are claiming that
services invocations are like AOR URI's. I don't think they are. I think
they are more like contact URIs. Yes the name of the meeting that gets
routed to the focus may be more like an AOR but we are talking about the
mixer name.

---

From: Andy Spitzer <[email-masked]>
Date: Thu, 15 Apr 2004 18:38:56 -0400

Cullen,

But for mixing, this is not true.  Calls for each mix must find the media 
server hosting THAT mix.  If call A went to MS 1, and call B when to MS 2, 
they would not be talking to each other!  Each individual call is NOT 
indepentant of the other calls in that mix, thus they must "find" the 
correct MS that hosts that mix.

This is why we put the conference id in the user part...so that each 
conference mix can be assigned a unique name (user part), and calls for 
that "user" find the correct MS that hosts that particular mix.  Using the 
"normal" user@domain approach seemed like the right way to pin users (aka 
conference ids) to endpoints.

--Andy Spitzer
[email-masked] (new address)

---

From: Dean Willis <[email-masked]>
Date: Tue, 20 Apr 2004 18:05:49 -0500

Andy Spitzer wrote:

> that "user" find the correct MS that hosts that particular mix.  Using 
> the "normal" user@domain approach seemed like the right way to pin users 
> (aka conference ids) to endpoints.

Zork! It's a GRUU!

--
Dean

---

From: Andy Spitzer <[email-masked]>
Date: Wed, 21 Apr 2004 10:01:07 -0400

Dean,

Yep.  But netann pre-dates GRUU.

--Andy Spitzer

On Tue, 20 Apr 2004 18:05:49 -0500, Dean Willis 
<[email-masked]> wrote:

>> the "normal" user@domain approach seemed like the right way to pin 
>> users (aka conference ids) to endpoints.
>
> Zork! It's a GRUU!
>
> --
> Dean