Subject: RE: [Speechsc] What is the scope of MRCPv2 session

From: Dan Burnett <[email-masked]>
Date: Fri, 8 Sep 2006 08:58:18 -0700 (PDT)

After carefully review your comments, Dave Oran's, and
the text of draft -10, I think the key relevant text
in 6.2.1 here is the following:

"The unambiguous string (first part) MUST BE unique
among the resource instances managed by the server and
is common to all resource channels with that server
established through a single SIP dialog."

Since the example in section 4.2 uses a single SIP
dialog to set up two resource channels with the same
MRCP server, the prefix values must be the same.  I
have corrected the example to use the same prefix in
the a=channel line for both resources.  This
correction will appear in draft -11.

-- dan

--- santhanakrishnan <[email-masked]> wrote:

> Hi Oran,
> 
>       Thanks for your detailed explanation. It
> clarifies enough of our
> queries.
> 
> But I would like to highlight the main source of
> confusion again to you.
> 
>  
> 
> Please refer the following section from the draft
> 
> 6.2.1 
> 
>    All MRCPv2 requests, responses and events MUST
> contain the Channel-
> 
>    Identifier header.  The value is allocated by the
> server when a
> 
>    control channel is added to the session and
> communicated to the
> 
>    client by the "a=channel" attribute in the SDP
> answer from the
> 
>    server.  The header value consists of 2 parts
> separated by the '@'
> 
>    symbol.  The first part is an unambiguous string
> identifying the
> 
>    MRCPv2 session.  The second part is a string
> token which specifies
> 
>    one of the media processing resource types listed
> in Section 3.1.
> 
>    The unambiguous string (first part) MUST BE
> unique among the resource
> 
>    instances managed by the server and is common to
> all resource
> 
>    channels with that server established through a
> single SIP dialog.
> 
>  
> 
> Here it says the prefix (First part) identifies an
> MRCPv2 session.
> 
>  
> 
> But in the following example, the channel Id
> returned by the Server 
> 
> for Synthesizer and Recognizer belonging to the same
> MRCPv2 Session 
> 
> is shown with different prefix(First Part).
> 
>  
> 
> S->C:  SIP/2.0 200 OK
> 
>           Via:SIP/2.0/TCP
> client.atlanta.example.com:5060;
> 
>           branch=z9hG4bK74bf9
> 
>           To:MediaServer
> <sip:[email-masked]>
> 
> ........................................
> 
>           v=0
> 
>           o=sarvi 2890844526 2890842809 IN IP4
> 126.16.64.4
> 
>           s=-
> 
>           c=IN IP4 224.2.17.12
> 
>           m=application 32416 TCP/MRCPv2
> 
>           a=setup:passive
> 
>           a=connection:existing
> 
>           a=channel:32AECB234338@speechrecog
> 
>           a=cmid:1
> 
>           m=application 32416 TCP/MRCPv2
> 
>           a=setup:passive
> 
>           a=connection:existing
> 
>           a=channel:32AECB234339@speechsynth
> 
>           a=cmid:1
> 
>           m=audio 48260 RTP/AVP 0 96
> 
>           a=rtpmap:0 pcmu/8000
> 
>           a=rtpmap:96 telephone-event/8000
> 
>           a=fmtp:96 0-15
> 
>           a=sendrecv
> 
>           a=mid:1
> 
>  
> 
> Here I wonder either the example or the draft
> statement seems to be
> incorrect. 
> 
> Please clarify on this.
> 
>  
> 
> Regards,
> 
> Santhanakrishnan;
> 
>  
> 
>  
> 
>  
> 
> -----Original Message-----
> From: David R Oran [mailto:[email-masked]] 
> Sent: Friday, June 16, 2006 2:37 AM
> To: IETF SPEECHSC (E-mail)
> Subject: Re: [Speechsc] What is the scope of MRCPv2
> session
> 
>  
> 
>  
> 
> On Jun 13, 2006, at 5:01 AM, Burger, Eric wrote:
> 
>  
> 
> > Do we need to tighten the language? Maybe
> introduce a new term?  
> 
> > Pick two from the set {MRCPv2, SIP, control, media
> control,  
> 
> > resource control, or something else descriptive of
> your choice}.
> 
>  
> 
> >
> 
> >
> 
> > Please follow-up to the list with your thoughts.
> 
> >
> 
> >
> 
> Well, this all seems clear to me, but I can
> certainly see how a  
> 
> newcomer would have his head spinning unless they
> were already very  
> 
> conversant in SIP, SDP, and in the architectural
> structure of MRCP.
> 
>  
> 
> The relationships are (unless I'm REALLY confused).
> 
> 1. SIP is used to establish and maintain a SIP
> dialog with a SIP UA  
> 
> acting on behalf of an MRCP server.
> 
> 2. Within that dialog, SDP offer-answer has been
> used to negotiate  
> 
> one *or more* MRCP Sessions. Each of these is
> described with a  
> 
> separate m= line in the SDP. In SDP terminology,
> each constitutes a  
> 
> 
=== message truncated ===>
_______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Dan Burnett <[email-masked]>
Date: Fri, 8 Sep 2006 09:08:30 -0700 (PDT)

I also updated the examples in 14.1 as well (both the
a=channel lines and the Channel-Identifier values).

-- dan

> > > Please follow-up to the list with your thoughts.
=== message truncated ===

---

From: "Dave Burke" <[email-masked]>
Date: Sun, 10 Sep 2006 19:31:22 +0100

I'm fine with this clarification (i.e. that the text in 6.2.1 is indeed 
correct). Are we all agreed, however, that as a consequence, the client 
cannot allocate more than one instance of the same resource type within a 
given SIP dialog? (If this was allowed and the text in 6.2.1 applied, the 
channel identifier would be the same for both resources and it would be 
impossible to disambiguate messages from the two resources).

To completely address this thread, there are two more adjustments needed:

1. The use-case of using two speechrecog resources (one in normal mode and 
the other in hotword) can only be realised using separate SIP dialogs. In 
section 9, change "same" to "separate":

   ... "the two modes can be invoked through separate resources
   allocated to the same SIP dialog"

2. What happens if the client attempts to establish two or more resources of 
the same type within a single SIP dialog? Presumably, 488 Not Acceptable 
Here? This error and the the restriction as a consequence of 6.2.1 should be 
called out.

Dave

---

From: Dan Burnett <[email-masked]>
Date: Mon, 11 Sep 2006 12:35:54 -0700 (PDT)

Based on this email and others I have received
personally, I believe there is dispute on this issue,
even though the original requirements document does
not specifically ask for multiple instances of each
resource and, in fact, we have discussed precisely
this topic in the past and agreed on the existing
text.

Note that Dave's use case #1 is achievable by using a
separate MRCP server, so the first change is
unnecessary.

Nevertheless, in honor of the dispute (and the fact
that I need to get a draft out this week) I will add
this to the issue tracker.  Future drafts beyond -11
can reconsider this issue if appropriate.

I will add your suggested clarification (#2) to the
issue tracker as well.  It is nice to have but
technically unnecessary since the client should know
which resources it's using.

In all interpretations the modified examples are
legal, so I will leave the modifications.

-- dan

--- Dave Burke <[email-masked]> wrote:

> >> After carefully review your comments, Dave
> Oran's,
> >> and
> >> among the resource instances managed by the
> server
> >> and
> >> >    Identifier header.  The value is allocated
> by
> >> the
> >> > server when a
> >> >
> >> >    instances managed by the server and is
> common
> >> to
> >> > all resource
> >> >