Re: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00

[Paul Kyzivat <[e-mail]>]

Gonzalo Camarillo wrote:
> Paul,
> 
> thanks for your comments.
> 
> The flows you are referring to describe how to invoke a transcoder by 
> the caller and by the callee. Nevertheless, this document does not 
> recommend *when* you have to invoke it. This is dealt with by the 
> framework document: draft-ietf-sipping-transc-framework-00.txt
> 
> In particular, the framework says:
> 
> " It is recommended that an offerer does not invoke transcoding
>    services before making sure that the answerer does not support the
>    capabilities needed for the session. Making wrong assumptions about
>    the answerer's capabilities can lead to situations where two
>    transcoders are introduced (one by the offerer and one by the
>    answerer) in a session that would not need any transcoding services
>    at all."
> 
> I guess the paragraph above addresses your concern.

I don't know. Putting it in the framework doesn't make it happen. It has 
to be in something else other than just the framework before it becomes 
functional.

I suppose you could view this as a problem for the human operator of the 
device - to select an appropriate phone feature based on known 
capabilities of the callee. But that is pretty much a cop out. And it 
doesn't work when the decision has to be made  by the callee, as when 
the initial invite has no offer, unless you expect the callee to select 
different answer modes depending on who is calling.

I would expect that the stuff you quote from the framework would appear 
as steps in the call flow that determine those capabilities.

Also, the framework has nothing to do with the codec restriction problem.

 > In any event, if you
> want to see more explanatory text included in any of these drafts, let 
> me know.

This isn't a hot button of mine. If nobody else is bothered then I will 
be happy to leave it be. This isn't normative stuff anyway.

	Paul

> Thanks,
> 
> Gonzalo
> 
> Paul Kyzivat wrote:
> 
>> Somehow I missed this draft altogether. (Asleep at the wheel I guess.)
>>
>> I see a couple of limitations in the approaches recommended, and have 
>> some ideas for how to fix them:
>>
>> 3.2 (Figure 2):
>>
>> This may be appropriate if B wants to hide its actual capabilities and 
>> expose T's instead. But suppose A is also deaf and also prefers text? 
>> In that case you might end up with two transcoders in the call. 
>> (Although there is no flow here that would cause that.) Also, the 
>> transcoding service may cost something so it would be good to delay 
>> requesting it until it is known to be needed.
>>
>> I understand that there is a desire to offer voice, because without 
>> that a call may never be established a dumb voice peer.
>>
>> As an alternative, if T is flexible in what codecs it can use, and B 
>> knows what those are, it can respons with an initial offer that 
>> includes a text stream as well as a voice stream that is black-holed. 
>> (C=0). That doesn't actually permit voice communication but offers 
>> voice and gives a a chance to pick what it wants. And it doesn't yet 
>> bother T.
>>
>> Then, if A's answer accepts the voice, B will invite T and then 
>> reinvite A to splice the streams. If A accepts text and refuses voice, 
>> all is cool.
>>
>> 3.3 (Figure 3):
>>
>> This again will be suboptimal if B prefers text. A perhaps more 
>> serious problem is that the handshake between A and T may 
>> unnecessarily restrict the set of codecs that A offers B. A may offer 
>> a bunch to T, but T may only be able to use one at a time, and so may 
>> restrict its answer to a single codec even though it could also do one 
>> of the others.
>>
>> Both of these issues could be solved using the same tactic I just 
>> suggested above - offering test and black-holed voice. This however 
>> might result in clipping B, who doesn't know the situation and is 
>> likely to start talking immediately. This could be dealt with using 
>> PRACK and UPDATE to refine the media stream selections before the call 
>> is answered.
>>
>> An alternative that works reasonably well with my suggetion above is 
>> for A to initiate the call with an offerless invite. If the offer that 
>> comes back contains only voice, then A can invite T at that time.
>>
>>     Paul
>>
>>
>> Dean Willis wrote:
>>
>>>
>>> I'd like to announce working group last call for the 3PCC transcoding
>>> draft:
>>>
>>>     draft-ietf-sipping-transc-3pcc-00.txt
>>>
>>> This last call period starts immediately and will run through May 15, 
>>> 2004.
>>>
>>> There are two known minor textual issues with this draft which will be
>>> corrected following the WGLC comments:
>>>
>>> 1) Split the references into normative and non-normative.
>>>
>>> 2) Correct the example domains -- s/domain.com/example.com.
>>>
>>> Please review this draft and get your comments, if any, back to the
>>> author (and to the list, if reasonable) as soon as possible.
>>>
>>> As I understand it, we'll be requesting that this draft be published 
>>> as an informational RFC. The procedure for informationals seems to be 
>>> evolving, and my understanding is that they will now receive 
>>> significantly less scrutiny from the IESG. So, we need to make sure 
>>> we do a VERY thorough job of reviewing this in the working group.
>>>
>>> Thanks,
>>>
> 


_______________________________________________
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