RE: [Sipping] Re: Transcoding and route entries

["Arnoud van Wijk" <[e-mail]>]

One important function using transcoding is indeed a relay.
Where an interpreter will transcode a voice call into for example text when
the receiving user is deaf and needs text to understand the speech.
(and text to speech).

Greetz

Arnoud

Drs. Arnoud A. T. van Wijk
Viataal
Research & Development
Afdeling RDS
Theerestraat 42
5271 GD Sint-Michielsgestel
The Netherlands. 
Mobile: [phone]
International text telephone: [phone]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Tim Melanchuk
Sent: vrijdag 12 maart 2004 20:07
To: Rohan Mahy
Cc: Gonzalo Camarillo; Eric Burger; Jonathan Rosemberg; Adam Roach; Henning
Schulzrinne; sipping
Subject: Re: [Sipping] Re: Transcoding and route entries

i agree with rohan and prefer using route headers. a transcoding
service seems much more akin to a relay along the path than it
does a conference which is more a destination unto itself. if
this can be achieved without (imho) inappropriately bending
existing mechanism, it is preferable to new mechanism.

timm

Rohan Mahy wrote:
> Hi Folks,
> 
> This decision boils down to a question of semantics.  Does a URI in a  
> Route header mean:  1) send through this proxy, or 2) send through this  
> service or intermediary ?
> 
> One of the important things to consider when there is a difference of  
> philosophy or opinion regarding semantics, is to consider if any harm  
> comes from either of the choices.  In this case, I can come up with no  
> technical reason that using a Route header is harmful.
> 
> Another key question is if there is any precedent.  Again, the two  
> proposals both have some precedent. Conference bridges do not use the  
> Route header (the analogy of approach 1), but folks have been using  
> Route headers to direct SIP requests through B2BUAs for session border  
> control (gasp), policy control, P-CSCFs, etc.. for some time now (the  
> analogy of approach 2).  I can even dig up some old mail when we  
> encouraged 3GPP to use a loose-route for one of their many B2BUAs  
> instead of defining some piece of new mechanism.  Taking this a step  
> further, we've been talking about how *proxies* can use session policy  
> to meet logging requirements.  I think this is very similar to  
> transcoding, since some entity operating on behalf of both  
> intermediaries (transcoder and logging proxy) need to see the media.
> 
> Finally there is the question of using existing mechanism vs. inventing  
> new mechanism.  If the existing mechanism fits, I see no reason to  
> define new mechanism unless a more general approach to other problems  
> is achievable with the new mechanism.  Nobody is proposing using the  
> new mechanism proposed in (1) to do anything else.  Also, the  
> conference bridge analogy breaks IMO since conference bridges do not  
> use this new mechanism to indicate the other participants in the  
> conference.
> 
> In summary, I prefer option 2 (use the Route header).  The approach  
> causes no harm, has precedent for existing usage, and requires no new  
> special-purpose mechanism.
> 
> thanks,
> -rohan
> 
> 
> 
> 
> On Mar 12, 2004, at 3:28 AM, Gonzalo Camarillo wrote:
> 
>> Folks,
>>
>> during the SIPPING session, I presented the following draft:
>> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-transc- 
>> b2bua-01.txt
>>
>> We discussed whether or not it is appropriate to use Route headers to  
>> introduce a B2BUA in the path. The two options are:
>>
>> A and B are the UAs, and T is the transcoder, which is a B2BUA
>>
>> -----     -----     -----
>> | A |-----| T |-----| B |
>> -----     -----     -----
>>
>> 1) Without using Route
>>
>> INVITE T
>> Body: B
>>
>> 2) Using Route
>>
>> INVITE B
>> Route T
>>
>>
>> Reasons for using option 1:
>>
>> - T is behaving as a conference server, so we should invoke it in the  
>> same way as we invoke a conference.
>> - Route headers are intended for proxies, not for B2BUAs.
>> - If we start using Route headers to invoke B2BUAs, what is the  
>> meaning of e2e or e2m security? T would be the recipient of the  
>> headers in the message, but T would not appear in the Request-URI...
>>
>> Reasons for using option 2:
>> - sessions with and without transcoder are invoked in the same way.
>>
>> I would like to hear your opinions. Mine is that we should go for  
>> option 1.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> This communication is confidential and intended solely for the  
>> addressee(s). Any unauthorized review, use, disclosure or 
>> distribution  is prohibited. If you believe this message has been sent 
>> to you in  error, please notify the sender by replying to this 
>> transmission and  delete the message without disclosing it. Thank you.
>>
>> E-mail including attachments is susceptible to data corruption,  
>> interruption, unauthorized amendment, tampering and viruses, and we  
>> only send and receive e-mails on the basis that we are not liable for  
>> any such corruption, interception, amendment, tampering or viruses or  
>> any consequences thereof.
>>
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 
> 


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP