Subject: [Sipping] Transcoding

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 13 Feb 2005 10:46:24 +0200

Folks,

I guess it is time to re-start the discussions we had some time ago on 
transcoding invocation. As you know, the transcoding framework defines 
two transcoding models.

http://standards.ericsson.net/gonzalo/papers/draft-ietf-sipping-transc-framework-00.txt

In the first one, referred to as the 3pcc model, the user agent invoking 
the transcoding service has a signalling relationship with the 
transcoder and with the remote user agent. This model has already been 
approved.

http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-3pcc-02.txt

In the second model, the transcoder receives SIP messages from a user 
agent and forwards them to the other user agent. It is a B2BUA.

The open issue is how to invoke this transcoder. There are currently two 
proposals:

1) Treat the transcoder as a simple conference server and use the 
URI-list service for INVITEs to establish the sessions. That is, the UAC 
sends an INVITE to the transcoder with the URI of the UAS in a body.

INVITE [email-masked]
[SDP]
[[email-masked]]

This approach was documented in the following document:

http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-transc-b2bua-01.txt

2) User Route headers as if the transcoder was a proxy. This is 
basically what SBCs do. The transcoder would rewrite the SDP.

INVITE [email-masked]
Route: [email-masked]
[SDP]

Approach 1 requires user agent to generate one-element XML resource 
lists, and approach 2 has a number of problems associated to it (these 
problems have been discussed in the context of SBCs).

Alternative proposals include defining a new header field similar to 
Route but which is used to include B2BUAs instead of Proxies...

Comments are welcome,

Gonzalo

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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Sun, 13 Feb 2005 18:07:12 -0500

Gonzalo,

Some comments inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gonzalo Camarillo
Sent: Sunday, February 13, 2005 3:46 AM
To: sipping
Cc: Rohan Mahy; Janne Peisa (JO/LMF); Fredrik Aberg (JO/LMF)
Subject: [Sipping] Transcoding

Folks,

http://standards.ericsson.net/gonzalo/papers/draft-ietf-sipping-transc-frame
work-00.txt

[MB] The draft indicates that either one of the caller or callee could
invoke transcoding, but the determination of that is too weak on the caller
side (it may not be able to determine the media capabilities).

http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-transc-
b2bua-01.txt

INVITE [email-masked]

[MB] I don't see the difference between Approaches 1&2 from a semantic point
of view. Both require SDP rewrite it seems, which means any SDP encryption
must be hop-by-hop. What are the other problems ? At the media stream level,
it seems no different from the 3pcc model. 

Comments are welcome,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 14 Feb 2005 09:04:01 +0200

Hello,

> must be hop-by-hop.

If you use the URI-list service approach the entity "rewriting" the SDP 
is the entity in the Request-URI of the INVITE. That is, the destination 
of the INVITE. That is not SDP rewriting.

> What are the other problems ? At the media stream
> level,

The idea is to set up a transcoder between both UAs. So, at the media 
level, both approaches must be the same.

The main problem related to using Route entries to introduce B2BUAs is 
that it is impossible to distinguish a man-in-the-middle attack from the 
B2BUAs modifying stuff to help you.

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Feb 2005 09:14:25 -0500

Gonzalo Camarillo wrote:
[snip]
> of the INVITE. That is not SDP rewriting.
[snip]
> B2BUAs modifying stuff to help you.

No matter how you try to spin it, this *is* a man-in-the-middle.

Its not objectionable *if* it is understood to be an authorized agent 
for one of the parties in the call. If it is, and if it then can 
authenticate as that party, then there isn't a problem. If that is the 
situation, and is known to be by the party it is acting on behalf of, 
then I don't think the differences between the two schemes are very 
significant. They are just mechanical differences.

I think this approach only makes sense when the transcoder is working on 
behalf on the party that is requesting the transcoder. And the 
techniques both require the one that is sending the invite be the one 
that is invoking the transcoder. So apparently this technique  is always 
a case of a caller taking preemptive action to involve a transcoder, 
whether needed or not, on the off-chance that it *might* be needed.

I don't find this a very pleasing setup. Seems like a bad way to operate 
unless the signaling intermediary is needed for other reasons. For 
instance, this fits well if you think you need an SBC in every call.

	Paul

---

From: David R Oran <[email-masked]>
Date: Mon, 14 Feb 2005 10:59:05 -0500

On Feb 14, 2005, at 9:14 AM, Paul Kyzivat wrote:

>
>
> Gonzalo Camarillo wrote:
> [snip]
>> If you use the URI-list service approach the entity "rewriting" the 
>> SDP is the entity in the Request-URI of the INVITE. That is, the 
>> destination of the INVITE. That is not SDP rewriting.
> [snip]
>> The main problem related to using Route entries to introduce B2BUAs 
>> is that it is impossible to distinguish a man-in-the-middle attack 
>> from the B2BUAs modifying stuff to help you.
>
> I think this approach only makes sense when the transcoder is working 
> on behalf on the party that is requesting the transcoder. And the 
> that is invoking the transcoder. So apparently this technique  is 
> always a case of a caller taking preemptive action to involve a 
> transcoder, whether needed or not, on the off-chance that it *might* 
> be needed.
>
> I don't find this a very pleasing setup. Seems like a bad way to 
> operate unless the signaling intermediary is needed for other reasons. 
> For instance, this fits well if you think you need an SBC in every 
> call.
>
Neither do I. It's just as likely that a callee is the one wanting to 
impose a transcoder as a caller.  If we take the conference approach 
rather than the B2BUA approach this still doesn't fall out, but at 
least appears more tractable. The initial Invite goes all the way to 
the callee, who creates a conference with a focus at the transcoder, 
joins that conference, and then redirects the caller to that focus.

If the transcoder is wanted by some intermediary (e.g. to force 
transcoding for some policy reason, then I think we need to appeal to 
session policies to cause the caller to explicitly ask for the 
transcoder as if they had wanted it in the first place.

> 	Paul
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 22 Feb 2005 10:31:53 +0200

Hi Paul,

Paul answered:

> authenticate as that party, then there isn't a problem. If that is
> the situation, and is known to be by the party it is acting on behalf
> of, then I don't think the differences between the two schemes are
> very significant. They are just mechanical differences.

The problem with Route entries is that they can be inserted by
intermidiaries and that, so far, consist of proxies that do not modify
SDPs. So, if we use Route to invoke B2BUAs, clients that do not know
about the new usage of Route will be extremely confused. On the other
hand, if the entity receiving the SDP is the one in the Request-URI,
every SIP client in the world would understand what is going on.

So, my proposal would be to use the Request-URI to address the B2BUA
(that would be the conferencing approach) or to use a new mechanisms. I
would not like to reuse the Route header field.

> on
> always

You would only invoke the transcoder if needed. The UAC attempts to
contact the UAS and discovers that they do not have any codec in common.
At this point, the UAC invokes the transcoder (i.e., with a new INVITE).

Regarding callee invocation, it could be handled (as Dave pointed out in
a separate message) using the conference model, or using a re-direction
at the callee side.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Feb 2005 18:41:43 -0500

> At this point, the UAC invokes the transcoder (i.e., with a new INVITE).

So, the situation you are considering is:

- A tries to call B
- B returns error - no matching codec (I forget the error for this)
- A chooses a transcoder to use
- A makes another call attempt to B, modified to involve the
   chosen transcoder

And you are worried that A will be confused that the chosen transcoder 
will act as a transcoder if it is identified by a Route header???

I think it is much simpler to simply say that Route headers identify 
intermediaries that are to be included on the path between the source 
and the destination. Whether they act as proxies, or B2BUAs is 
immaterial, as long as they do so well enough to not bother the endpoints.

> a separate message) using the conference model,

Pretty heavy duty machinery. But doable.

> or using a re-direction at the callee side.

Problem with that is the redirect needs to somehow specify both the 
transcoder address and the address of the UAS. How is that going to work?

Is there really a need to do anything other than the 3pcc model? That 
has none of these problems, and isn't especially complicated.

I think the time when you want to use this non-3pcc method is in cases 
like SBCs, where something in the call path, other than the UAC or UAS, 
*decides* that a transcoder is needed and inserts one in the call path, 
without the express permission of the UAC or UAS. This is truly a MITH, 
and something I would prefer not to discuss, but is the only compelling 
case I can see where the 3pcc model isn't sufficient.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 Feb 2005 10:41:22 +0200

Hi Paul,

> - A makes another call attempt to B, modified to involve the

Yes, that's the situation we are looking at.

> will act as a transcoder if it is identified by a Route header???

Well, in this case A will most likely know that what it inserted in the 
Route header was a B2BUA. I am worried because Route headers can be 
inserted by any intermediary. So, if a random proxy in the path decides 
to insert a Route header pointing to a B2BUA, the UAC will not know 
anything about this. The UAC may have encrypted the SDP, and the B2BUA 
will not be able to do its job.

On the other hand, if the destination of the request is identified by 
the Request-URI, as usual, the UAC generating the request will know who 
will be the reciptient of its SDP.

Debugging a system where you know who should parse what is also easier. 
If any entity in the Route header can suddently become a B2BUA, 
debugging becomes more difficult.

I am asking for a clear way to indicate whether something will act as a 
proxy or as a UA. Since so far Route headers have identified proxies and 
the Request-URI has identified the UAS, this would be one possible 
approach. Other approaches would include labelling some Route entries as 
B2BUAs or employing a new mechanism to carry B2BUA's addresses.

>>Regarding callee invocation, it could be handled (as Dave pointed out
> 
> in
> 

Agreed.

> transcoder address and the address of the UAS. How is that going to

Yes, that is an issue.

> has none of these problems, and isn't especially complicated.

For the callee invocation case, the 3pcc model will probably be the 
easiest way to handle it. However, when the caller is the one invoking 
the transcoder, the 3pcc model involves many messages. If we are dealing 
with a terminal using a slow radio access, the 3pcc model does not seem 
so attractive.

> case I can see where the 3pcc model isn't sufficient.

I actually like the 3cpp model as well, but I acknowledge that having an 
alternative model that involved fewer messages over the air interface 
and allowed for simpler logic in the user agent would be useful in some 
scenarios.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Feb 2005 10:20:54 -0500

> B2BUAs or employing a new mechanism to carry B2BUA's addresses.

Anything that happens after the request leaves the UAC isn't likely to 
be known by the UAC. Does it really matter if an intermediary inserts a 
route header and the corresponding server acts as a B2BUA, vs an 
intermediary routing the request to something that acts as a B2BUA 
without use of a route header?

Or is your goal simply to declare it non-conforming for something to be 
installed as a B2BUA in the middle of a call without that having been 
explicitly requested by the UAC itself? I guess I can see some good 
reasons to want to do that, as a way to make clear that certain kinds of 
usage (e.g. some uses of SBCs) are unacceptable.

But while that might be a desirable goal, it may also be in conflict 
with the kind of service some want to expect, and others want to 
provide. There is certainly something seductive about a service provider 
that simply "makes things right" - allowing you to form a call as you 
wish, with a transcoder magically installed if needed. But doing that 
means implicitly granting permission for an optional MITM.

	Paul