Subject: [MEDIACTRL] [RAI] RAI Review of draft-ietf-mediactrl-sip-control-framework-02 - Critical Issue 1

From: "Chris Boulton" <[email-masked]>
Date: Fri, 23 May 2008 23:36:03 +0100

1)    It is not clear to me why the media control protocol needs to be
negotiated via SIP. SIP primarily offers rendezvous and media
negotiation.

[CJB] Agreed.

 I'm not sure why this protocol needs either.

[CJB] Taking your two characteristics of SIP and applying them to the
problem.

-        Does Media Server Control require media negotiation - well yes,
it most certainly does.  A media server is acting as a SIP UAS and can
only benefit from all that SIP has to offer with regards media
negotiation.  The control of a media server should just be viewed as
'another' media type that can be negotiated between two entities.  Its
how it's done today with thousands of live deployments of media servers.
Are we saying that they are doing it wrong (if so you can tell them
:-)).

 There are several mentions of rendezvous, but no discussion of why it
is needed.  

Are application servers or media servers likely to move around, or have
dynamically assigned IP addresses, etc?

[CJB] Why not?  There are no hard and fast rules for the use of the
packages being created in MediaCtrl.  They are not simply designed for
high end Media Servers that can process millions of calls.  The idea is
to provide 'Media Services' to a plethora of devices.  This maybe a
juggernaut of a Media Server processing thousands of calls OR it might
just be a low end endpoint that also offers simple IVR/Conferencing
capability.  So we need to be clear that the packaged approach using SIP
is intended to be as flexible as possible. 

 Do we need registration,

[CJB] Yes - I can certainly see a UAS making use of media services that
use SIP Register.  We already have an individual effort looking into
this topic -
http://www.ietf.org/internet-drafts/draft-boulton-mediactrl-feature-tags
-00.txt.

 forking, etc?

[CJB] See above - why not?

 Or more to the point, why can't a media control client just open the
connection to the server directly, rather than going through an SDP
offer/answer? What makes it different from thousands of other protocols
that get by just fine without SIP?

[CJB] In short - 'Sure it could'.  This will be fine for a bog standard
solution but does not in anyway take advantage of richness that we are
trying to promote in the solution (Or are we really all on the PSTN
emulation train).  I think I have discussed above the main reasons for
use of SIP.  Using SIP for Media Server control has many years of
development and deployment experience.  The group developing these
solutions are at the coal face and have thousands of lines of running
code (a rare thing for the IETF I know as opposed to some cool academic
solution that is never implemented :-)).  We even have a host of
companies developing prototypes of this document as I type to help
develop the document (again, a rarity I know). 

I'd like to at least see motivation for this discussed in the draft.

[CJB] We (the authors) are more than happy to add as much text as think
is required for clarity.

To end with some words from (one of our) our great leader(s) - as
documented in http://tools.ietf.org/html/draft-burger-mscl-thoughts-01:

  One might ask, "If all we are doing is establishing a TCP connection
   to control the media server, what do we need SIP for?"  This is a
   reasonable question.  The key is to be using SIP for media session
   establishment.  If we are using SIP for media session establishment,
   then we need to ensure the URI used for session establishment
   resolves to the same node as the node for session control.  Using the
   SIP routing mechanism, and having the server initiate the TCP
   connection back, ensures this works.  For example, the URI sip:
   myserver.example.com may resolve to sip:
   server21.farm12.northeast.example.net, whereas the URI
   http://myserver.example.com may resolve to
   http://server41.httpfarm.central.example.net.  That is, the host part
   is NOT NECESSARILY unambiguous.

Chris.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Ben Campbell <[email-masked]>
Date: Fri, 23 May 2008 21:53:06 -0500

I guess I am convinced by the final argument (the quote from Eric's  
draft.).

In summary, the litmus test I have applied to all of your arguments  
is, how is this different than something like HTTP? Rendezous? Yes,  
I'm sure there are use cases where HTTP could have used rendezvous,  
but it's gotten buy pretty well without it. Capabilities based  
routing? Same answer.

Identifier equivalence (i.e. mapping SIP URIs with some other protocol  
identifier and getting to the same place)? Well, you've got me there-- 
the best way to make sure we reach a device identified with a SIP URI  
is to use SIP, even if it is otherwise overkill.

I would still like to see the motivation for using SIP described in  
the draft, but I withdraw my argument against using SIP.

On May 23, 2008, at 5:36 PM, Chris Boulton wrote:

> 1)    It is not clear to me why the media control protocol needs to  
> be negotiated via SIP. SIP primarily offers rendezvous and media  
> negotiation.
>
> [CJB] Agreed.
>
> [CJB] Taking your two characteristics of SIP and applying them to  
> the problem.
>
> -        Does Media Server Control require media negotiation – well  
> yes, it most certainly does.  A media server is acting as a SIP UAS  
> and can only benefit from all that SIP has to offer with regards  
> media negotiation.  The control of a media server should just be  
> viewed as ‘another’ media type that can be negotiated between two  
> entities.  Its how it’s done today with thousands of live  
> deployments of media servers.  Are we saying that they are doing it  
> wrong (if so you can tell them J).
>
>  There are several mentions of rendezvous, but no discussion of why  
> it is needed.
> Are application servers or media servers likely to move around, or  
> have dynamically assigned IP addresses, etc?
>
> packages being created in MediaCtrl.  They are not simply designed  
> for high end Media Servers that can process millions of calls.  The  
> idea is to provide ‘Media Services’ to a plethora of devices.  This  
> maybe a juggernaut of a Media Server processing thousands of calls  
> OR it might just be a low end endpoint that also offers simple IVR/ 
> Conferencing capability.  So we need to be clear that the packaged  
> approach using SIP is intended to be as flexible as possible.
>
>  Do we need registration,
>
> [CJB] Yes – I can certainly see a UAS making use of media services  
> that use SIP Register.  We already have an individual effort looking  
> into this topic - http://www.ietf.org/internet-drafts/draft-boulton-mediactrl-feature-tags-00.txt 
> .
>
>  forking, etc?
>
> [CJB] See above – why not?
>
>  Or more to the point, why can't a media control client just open  
> the connection to the server directly, rather than going through an  
> SDP offer/answer? What makes it different from thousands of other  
> protocols that get by just fine without SIP?
>
> [CJB] In short – ‘Sure it could’.  This will be fine for a bog  
> standard solution but does not in anyway take advantage of richness  
> that we are trying to promote in the solution (Or are we really all  
> on the PSTN emulation train).  I think I have discussed above the  
> main reasons for use of SIP.  Using SIP for Media Server control has  
> many years of development and deployment experience.  The group  
> developing these solutions are at the coal face and have thousands  
> of lines of running code (a rare thing for the IETF I know as  
> opposed to some cool academic solution that is never implemented  
> J).  We even have a host of companies developing prototypes of this  
> document as I type to help develop the document (again, a rarity I  
> know).
>
> [CJB] We (the authors) are more than happy to add as much text as  
> think is required for clarity.
> To end with some words from (one of our) our great leader(s) – as  
> documented inhttp://tools.ietf.org/html/draft-burger-mscl-thoughts-01:
>