Re: [Sipping] Re: Transcoding and route entries

[Tim Melanchuk <[e-mail]>]

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