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

[Gonzalo Camarillo <[e-mail]>]

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. In any event, if you 
want to see more explanatory text included in any of these drafts, let 
me know.

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

-- 
Gonzalo Camarillo         Phone :  [phone]
Oy L M Ericsson Ab        Mobile:  [phone]
Telecom R&D               Fax   :  [phone]
FIN-02420 Jorvas          Email :  [e-mail]
Finland                   http://www.hut.fi/~gonzalo


_______________________________________________
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