Subject: Re: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding serviceinvocation

From: "Rai, Shambhu" <[email-masked]>
Date: Fri, 7 Mar 2008 12:19:02 +0530

Hi Eric,

I did not realize that you are one of the editors of the RFC 4117(brooktrout->bea). Let me restate if I understand the common transcoding procedure suggested by you in your mail below.

1. A calls B via AS
2. AS determines need of transcoding.
3. AS sends INVITE with "A" Party SDP Offer to MS. RURI points to transcoding service URI, with request for New Identifier. 
4. MS responds 200 OK to offer with Conf ID for the transcoding context.
5. AS INVITE "B" Party with MS SDP and get the B's SDP
6. AS sends INVITE with "B" Party SDP to MS, RURI points to Transcoding service URI with Conf ID received earlier. 
7. MS performs the transcoding based on SDPs on two call legs.

Is there any common/standard syntax used in the industry to request Conf-ID creation (step 3), send back conf-ID (step4), using conf-ID to add new call leg (Step 5)?  
OR 
AS generate Unique ID for every new transcode request and put the ID in RURI user part. MS will just join two call legs received from AS with same RURI (userPart+ unique ConfID)?

Regards,
Shambhu

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 9:27 PM
To: Rai, Shambhu
Cc: [email-masked]
Subject: Re: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding serviceinvocation

I know; check out the editors on the draft. However, I am unaware of any device, client or server, that implements that part of 4117.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

----- Original Message -----
From: Rai, Shambhu <[email-masked]>
To: Eric Burger
Cc: [email-masked] <[email-masked]>
Sent: Thu Mar 06 01:09:55 2008
Subject: RE: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding serviceinvocation

Hi Eric, 

Actually, RFC 4117 specifies slightly different way of invoking the transcoding service.

1. Caller / Called Party / 3PCC Application server sends the INVITE request to invoke the transcoding service with following
	- RURI pointing to Transcoding service URI, to identify the service
	- Body of INVITE will contain two SDPs (SDP of called and Caller) between which Transcoding session needs to be established. 

2. MS responds 200 OK for INVITE
	- Body of 200 OK will contain two SDPs of MS SDP answer to called and Caller)

3. MS then uses caller and called Party SDPs to setup transcoding appropriately.

There are call flow variants in which only one SDP will be known at the time of invocation. But, I will not get in those details. Crux of things is that only one SIP Dialog is established between AS invoking the service and MS and there is NO NEED of any Conference Identifier as both sessions are associated by same SIP dialog.

Regards
Shambhu

RFC 4117 Sample Call flow

      A                            T                            B

      |                            |                            |
      |--------------------(1) INVITE SDP A-------------------->|
      |                            |                            |
      |                            |<---(2) INVITE SDP A+B------|
      |                            |                            |
      |                            |---(3) 200 OK SDP TA+TB---->|
      |                            |                            |
      |                            |<---------(4) ACK-----------|
      |                            |                            |
      |<-------------------(5) 200 OK SDP TA--------------------|
      |                            |                            |
      |------------------------(6) ACK------------------------->|
      |                            |                            |
      | ************************** | ************************** |
      |*          MEDIA           *|*          MEDIA           *|
      | ************************** | ************************** |
      |                            |                            |

          Figure 1: Callee's Invocation of a Transcoding Service

 -----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 3:30 AM
To: Rai, Shambhu
Cc: [email-masked]
Subject: RE: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding serviceinvocation

In terms of 4117, you simply invite two legs to a 4240 session with the same conf= URI.  Each leg gets its SDP negotiated separately.  The MS transcodes "by magic" from the AS' point of view. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Buko
Sent: Tuesday, March 04, 2008 1:37 PM
To: Rai, Shambhu; [email-masked]
Cc: [email-masked]
Subject: Re: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding serviceinvocation

The <join> defined in draft-boulton-conference-control-package can be used to connect endpoints.
It can connect endpoints to conferences, endpoints to endpoints, or conferences to conferences.

In your case below, it would be connecting two separate endpoints ("connections").

My experience with this scenario has been that the MS can use "smart transcoding".  Nothing in the <join> will define if transcoding is required (although that might be something to think about).  However the MS terminated both calls and knows if transcoding is required based on the media that was negotiated.

Steve

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Rai, Shambhu
|Sent: Tuesday, March 04, 2008 1:23 PM
|To: [email-masked]
|Cc: [email-masked]
|Subject: Re: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding 
|serviceinvocation
|
|Hi lorenzo,
|
|Thanks for the response.
|
|I agree, MS can setup the transcoding with a request from 3PCC using 
|SIP/SDP. You do not necessarily need any media control package for the 
|same. But, media server needs to be told clearly which two call legs 
|need to be joined in the transcoding? I am more worried about what 
|mechanism AS can use to convey this information.
|1. Use Conference package over Media control channel 2. Use RFC 4117 
|defined flows to setup transcoding 3. Anything else?
|
|I know some of the existing MS vendors use protocols like MGCP to move 
|two call legs (endpoints) in the same context. Has Any one any 
|experience on transcoding setup on MS using SIP 3PCC AS?
|
|Regards,
|Shambhu
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]]
|Sent: Tuesday, March 04, 2008 6:19 PM
|To: Rai, Shambhu
|Cc: [email-masked]
|Subject: Re: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding 
|serviceinvocation
|
|Hi Rai,
|
|from my understanding, the MS takes care of transcoding automatically.
|Control packages are only interfaces to the primitive functionality the 
|MS itself provides with.However, the conferencing control package is 
|currently needed to put two UACs in contact: if transcoding between 
|them is needed (according to the previous 3PCC the AS had between them 
|and the MS), the MS does that. Same for an announcement to play to a 
|UAC, for instance: if the source is to be transcoded to a format the 
|receiving UAC understands, the MS takes care of that.
|
|I'm not sure I addressed your concern.
|
|Lorenzo
|
|
|Quoting "Rai, Shambhu" <[email-masked]>:
|
|> HI,
|>
|> I am not sure, if my message reached the list.. Can some one comment 
|> on my questions on Transcoding service using media control channel 
|> framework in the mail below?
|>
|> Regards,
|> Shambhu
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] 
|> On Behalf Of Rai, Shambhu
|> Sent: Monday, March 03, 2008 2:55 PM
|> To: [email-masked]
|> Subject: [MEDIACTRL] FW: RFC 4117: Sip signaling for Transcoding 
|> serviceinvocation
|>
|> Hi Guys,
|>
|> I am new to this list. So, please excuse me if I am raising already 
|> discussed questions.
|>
|> 1. I am looking at the signaling model options for Transcoding 
|> service invocation on media server. Is there a package defined in the 
|> "mediactrl" framework for invoking the transcoding service on media 
|> server or one has to support conference packages to support the 
|> transcoding?
|>
|> 2. RFC 4117 proposes framework/call flows to invoke the transcoding 
|> service on Media server from a 3PCC AS. What is the MediaCtrl group's 
|> position on the same?
|>
|> Regards,
|> Shambhu
|>
|>
|>
|> -----Original Message-----
|> From: Rai, Shambhu
|> Sent: Thursday, February 28, 2008 10:23 AM
|> To: [email-masked];
|> [email-masked]'; [email-masked]'
|> Subject: RFC 4117: Sip signaling for Transcoding service invocation
|>
|> HI All,
|>
|> Is anyone aware of any Media server / MRF / Transcoder using 3PCC 
|> control mechanism described in RFC 4117 for invoking a transcoding 
|> service?
|>
|> I am evaluating the Signaling model to invoke transcoding service on 
|> MRF. I can think of following options.
|>
|> 1. RFC 4117 based 3PCC transcoding service invocation:
|>         In this case AS setup only one Dialog (with SDP of A and 
|> B)towards MRF requesting the transcoding service.
|>
|> 2. 3PCC AS Use an identifier like a conference identifier to move 
|> both parties in the same context.
|>     I am wondering, If setting up transcoding as two party conference 
|> will be a good idea?  As there will be need to distinguish transcoder 
|> service from the conferencing service. Like A party doing hold unhold 
|> etc, These scenarios needs to be handled differently for transcoding 
|> from conference.
|>
|> It will be good to know industry accepted mechanism for the same. Any 
|> inputs are welcome.
|>
|> Regards,
|> Shambhu
|>
|> _______________________________________________
|> MEDIACTRL mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/mediactrl
|> Supplemental Web Site:
|> http://www.standardstrack.com/ietf/mediactrl
|>
|> _______________________________________________
|> MEDIACTRL mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/mediactrl
|> Supplemental Web Site:
|> http://www.standardstrack.com/ietf/mediactrl
|>
|
|
|
|--
|Lorenzo Miniero, Junior Researcher
|Dipartimento di Informatica e Sistemistica Università degli Studi di 
|Napoli "Federico II"
|Via Claudio 21 -- 80125 Napoli (Italy)
|Phone: +390817683821 - Fax: +390817683816
|Email: [email-masked]
|
|_______________________________________________
|MEDIACTRL mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/mediactrl
|Supplemental Web Site:
|http://www.standardstrack.com/ietf/mediactrl
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

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

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 16 Mar 2008 07:57:57 -0700

There isn't a standard for generating the conference ID.  Sounds like a standardization opportunity. 

-----Original Message-----
From: Rai, Shambhu [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 1:49 AM
To: Eric Burger
Cc: [email-masked]
Subject: RE: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding serviceinvocation

Hi Eric,

1. A calls B via AS
5. AS INVITE "B" Party with MS SDP and get the B's SDP 6. AS sends INVITE with "B" Party SDP to MS, RURI points to Transcoding service URI with Conf ID received earlier. 

Regards,
Shambhu

----- Original Message -----
From: Rai, Shambhu <[email-masked]>
To: Eric Burger
Cc: [email-masked] <[email-masked]>
Sent: Thu Mar 06 01:09:55 2008
Subject: RE: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding serviceinvocation

Hi Eric, 

Regards
Shambhu

      A                            T                            B

      |                            |                            |

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Buko
Sent: Tuesday, March 04, 2008 1:37 PM
To: Rai, Shambhu; [email-masked]
Cc: [email-masked]
Subject: Re: [MEDIACTRL] RFC 4117 Vs MCCF for Transcoding serviceinvocation

Steve