Subject: RE: [Sipping] Transcoding

From: Eric Burger <[email-masked]>
Date: Fri, 4 Mar 2005 18:11:16 -0500

<guilty-party hat on>
What we were looking for was a way for a lazy UAC to request transcoding
without it itself being the 3PCC controller.  I would offer that the list
exploder works off-the-shelf.  If we even need to document it, I could see a
1 paragraph Informational RFC saying, "here is how you can use the list
exploder mechanism for doing transcoding."

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Gonzalo Camarillo
> Sent: Wednesday, February 23, 2005 3:41 AM
> To: Paul Kyzivat
> Cc: Dave Oran; 'sipping'; Medhavi Bhatia
> Subject: Re: [Sipping] Transcoding
> 
> 
> Hi Paul,
> 
> > 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
> 
> Yes, that's the situation we are looking at.
> 
> > 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???
> 
> 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.
> 
> 
> > 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.
> > 
> > 
> >>Regarding callee invocation, it could be handled (as Dave 
> pointed out
> > 
> > in
> > 
> >>a separate message) using the conference model,
> > 
> > 
> > Pretty heavy duty machinery. But doable.
> 
> Agreed.
> 
> > 
> > 
> >>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?
> 
> Yes, that is an issue.
> 
> > 
> > Is there really a need to do anything other than the 3pcc 
> model? That 
> > 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.
> 
> > 
> > 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.
> 
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2005 19:02:34 -0500

> exploder mechanism for doing transcoding."

Well - the list exploder works off the shelf except for the new problem 
of consent. It needs consent before it can retarget your request to the 
intended party. And its hard to preload it with consent for everybody 
you might want to call.

Or do we have a special case that list exploders don't need consent when 
there is only one target?

	Paul