Subject: [SIP] On Transcoding Device

From: "rafi" <[email-masked]>
Date: Mon, 17 Jul 2000 11:20:25 +0530

Hi,

        In Draft  "draft-camarillo-3pcc-qos-00.txt"
in section 3, example  is  given where
use of transcoding device is mentioned. This
device act as a "dial-up bridge" and  bridges  two
audio stream  from UAC - T and  T- UAS (where T
is transcoding service agent ) and vice versa. However 
it is not clear how T comes  to know which of the  two 
audio  stream it has to  bridge.

Thank You
Rafi Assadi H.M
Silicon Automation Systems
Bangalore

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 17 Jul 2000 09:49:46 +0300

Hi,

T receives two INVITEs, each one with an SDP. These two INVITEs can be
matched betweeen them because they use the same URI in the Request-URI
(in the example: [email-masked]).

The trancoder has to bridge between the SDP of one INVITE and the SDP of
the other one.
That is, everything received on one side is sent to the other side and
the other way around.

Regards,

Gonzalo

> rafi wrote:

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 17 Jul 2000 16:30:41 -0700

Hi,

This thread got me thinking about a related topic:  naming conventions for 
MCU conferences.  I think of transcoders as just simple (2-party) MCUs that 
supports multiple codecs.  Just like Gonzalo's transcoders, MCUs could also 
match on the user portion of Request-URI when forming an ad-hoc 
conference.  Let's call the parties using the same user portion as a "group".

One of the problems traditionally associated with MCU conferences when 
using a distributed signaling protocol, is how to decide when to free up 
resources.

Let's say you need a transcoder so that Alice can leave a voicemail message 
for Bob.  The voicemail system uses G.711 and G.729.  Alice is using a GSM 
mobile phone gateway (GSM codec).  If Alice sends a BYE, you want the 
transcoder to send a BYE to the voicemail system as well.  You could use 
session timer (and other mechnisms) to detect if Alice "went away" without 
sending a BYE.  In the two party case, if either party disappears, you can 
safely drop the call right?

Well, maybe not.  Say Alice gets an important call while leaving 
voicemail.  She  puts voicemail and hold.  She has music on hold, so her UA 
uses TRANSFER or Also to ask the transcoder/MCU to listen to musak. Before 
she can get back to voicemail, her UA crashes and forgets her call-ids and 
request URIs.  Now the MCU/transcoder has Musak streaming forever at Voicemail.

Basically, you have passive and active participants in a group. As long as 
there is at least one active participant, you should keep the group (and 
therefore all the passive participants) up.  This works well if you want 
some conferences to die after the initiator leaves (the initiator is the 
only active party), and for applications like call screening, call 
monitoring, call center coaching, etc.  For more advanced  mixing 
applications each party may be a member of more than one "group" of 
parties, and may send or receive media, or both.

I think a user-part naming convention for transcoders and MCUs would help 
here. I had in mind something along these lines:

   uri = scheme ":" [userpart "@" ] hostport *( ";" params )
   userpart = group  *( "+" group )
   group = group-id *( "," group-params )

So you can INVITE yourself to one or more groups, each group separated by a 
"+".  For each group, you could add optional parameters.

   group-params = participation | direction
   participation = "active" | "passive"
   direction = "send" | "recv" | "sendrecv"

The group ID selected for 3rd party call control is centralized so there 
are no conflicts on the MCU, but you could easily use a local call id and 
add you FQDN or IP address on the end separated by a "&".

   group-id = token | token "&" host

I believe that all these characters (+)  (,)  (&)  plus (=) are legal to 
use unescaped in the user part.

Behavior of the MCU is:  for each RTP sender, find out which groups they 
send on, and mix that media with all listeners of that set of groups which 
understand that media type.

Anyone have any comments on this?

thanks,
-rohan