[Sipping] Re: Transcoding and route entries

[Rohan Mahy <[e-mail]>]

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