Subject: RE: [Sipping] Transcoding

From: Eric Burger <[email-masked]>
Date: Tue, 8 Mar 2005 15:53:52 -0500

I was thinking local policy.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, March 04, 2005 7:03 PM
> To: Eric Burger
> Cc: Gonzalo Camarillo; Dave Oran; 'sipping'
> Subject: Re: [Sipping] Transcoding
> 
> 
> 
> 
> Eric Burger wrote:
> > <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."
> 
> 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
> 
> >>-----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