Re: [Sipping] Transcoding and route entries

[Paul Kyzivat <[e-mail]>]

Gonzalo - inline.

	Paul

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

I vote for option 2.

> 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.

It is a stretch to call this a conference server. If you made it one, 
then T would be obligated to support all the things that a conference 
focus does. That is quite a burden to place on a poor transcoder that 
never wants to support more than two legs.

> - Route headers are intended for proxies, not for B2BUAs.

There has never been much work done on defining various specific kinds 
of B2BUAs. But there has always been discussion of various degrees of 
transparency on the part of a B2BUA. There seems to be a continuum, from 
ones that are just barely more than a proxy, to those that are clearly a 
full-blown UA that is the intended destination of the caller.

At least for those that are close to being proxies, the Route header 
seems entirely appropriate. The box is just a waypoint on the path 
between the caller and the intended callee.

I think the question is whether the transcoder is close enough to being 
a proxy for this argument to apply to it. I think so - it clearly isn't 
the caller's intended destination - it is merely a waypoint.

> - 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...

I do agree that security may be an issue here. But it is going to be an 
issue of some sort no matter what. (What happens if B has a whitelist of 
acceptable callers, and A is on the list but T is not?)

If this proves to be a problem, then this architecture for a transcoded 
call may be entirely wrong. What ever happened to the concept of having 
A (or B) act as a B2BUA, bringing in T when needed? As in:

	T ---2----- A ----1------ B
	  ===3=====
	  =========4=============

where 1 and 2 are sip connections that A joining, acting as a B2BUA, 
while 3 and 4 are media sessions that T is joining, acting as a transcoder.

The advantage of this config is that the call between A and B is direct, 
so there is no issue of identifying another party, and no issue of 
authentication or authorization. And presumably T is only brought in 
when it is apparent that it is needed.

> 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