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

From: Dean Willis <[email-masked]>
Date: Thu, 29 Apr 2004 03:07:01 -0500

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,

-- 
Dean Willis
SIPPING WG co-chair

_______________________________________________
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: Thu, 29 Apr 2004 13:33:25 -0400

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 29 Apr 2004 22:09:36 +0300

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:

>> As I understand it, we'll be requesting that this draft be published 
>> as an informational RFC. The procedure for informationals seems to be 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2004 18:17:58 -0400

Gonzalo Camarillo wrote:
> 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

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

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 30 Apr 2004 04:45:19 -0500

Paul Kyzivat wrote:

>>    answerer) in a session that would not need any transcoding services
...

> different answer modes depending on who is calling.

Would something like a priority-ordered preference/capability set in 
caller-preferences/callee caps be a big aid here?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Apr 2004 09:05:53 -0400

> Paul pondered:

`:-)

>> 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 
>> the initial invite has no offer, unless you expect the callee to 
>> select different answer modes depending on who is calling.
> 

Well, the normal use of callerprefs is to select among alternative 
advertised contacts. That doesn't seem to be the case here. Of course an 
endpoint *could* choose to alter its behavior based on callerprefs, but 
I don't know if we want to suggest that.

However I suppose a variant is possible. An endpoint with these 
capabilities could register multiple contacts, tagged with capabilities 
for voice and text. Depending upon which one was called, it could do the 
right thing. And it could prioritize its native capabilities higher, so 
that a forking proxy would try that first even if the caller expresses 
no preferences.

If that were done, when a call arrives at the contact associated with 
text, only text would be offered. When a call arrives at the contact 
associated with voice then all the games described in this draft would 
be carried out.

That sounds like an interesting approach.

	Paul