Subject: RE: [Sipping] comments on draft-kang-sipping-transc-scenario-00

From: 강태규 <[email-masked]>
Date: Mon, 7 Nov 2005 17:02:05 +0900

Thank for your comments.
Answers are in line:
Kang
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
Sent: Monday, November 07, 2005 1:12 AM
To: IETF Sipping List
Subject: [Sipping] comments on draft-kang-sipping-transc-scenario-00

>  The transit party SHOULD provide all transcoding capability to the 
>    calling party and called party during call negotiation in call set up 
>    procedures[12-13]. This minimizes codec mismatch call setup failure 
>    due to a lack of codec negotiation information. 

>> what exactly is a "transit party", and what do you do in situations 
>> where there isn't a transit provider? I.e., two enterprises calling each 
>> other.

Answer1: "transit party" supports communication between calling party and called party using transcoding coding capability. We can say intermediary instead of “transit party”.
I think that there are two ways: one is peer-to-peer without UA(User Agent), the other is with UA. In this situation, it means last one.

>> Also, I don't understand the references - 12/13 are to caller prefs. How 
>> is this relevant?

Answer2: ref 12(RFC 3840) says that “a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents ...’. I think it is similar but not exactly same. So, I will make clear not to confuse it. 
I will delete ref 11/12 or rewrite the sentences at the next version.

> A discriminator for codec characteristics SHOULD provide the 
>    information whether it will be transcoded or not. The discriminator 
>    prevents it from re-transcoding or transcoding-cycling occurring. 

>> what discriminator? Are you referring to an existing SDP attribute? Or 
>> proposing that a new one be developed?

Answer3: I mean proposing that a new one be developed. I am not sure whether 
an existing SDP attribute supports for it or not. My understanding so far, 
an existing SDP attribute does not support for it. 
I would like to discuss about this issue at email lists.

> If T and B can not support a codec, T SHOULD reply to A with Not 
>    Acceptable:406 and Not transcoding supportable A at T after receiving 
>    Not Acceptable Here: 488 from B. 

>> I can't quite follow what you are proposing here. I think you are 
>> assuming that the offer sent by T to B contains all of the codecs 
>> supported by T, but none of those are compatible with B. Is that right?

Answer4: Yes, That’s right. It means there is no reason code as far as I know. 
I try to define it. I need to discuss it and more comments.

>> 406 seems the wrong response here. Also, your notation for indicating 
>> errors is hard to understand. Typeically the convention is response-code 
>> (reason), i.e., 406 (Not Acceptable). As such, I can't follow how you 
>> propose indicating "Not Acceptable:406 and Not transcoding supportable A 
>> at T". This seems like two error codes?

Answer5: Thanks. I will rewrite it with following the convention response-code(reason) at next version. Two error codes are used in internet-draft temporary due to not proper response code. After it defined, it will be one error code.

> T1 sends to T2 the codec a from A and the Tb from T1. T2 sends to T3 
>    the a from A, the Tb from T1, and the Tc from T2. T3 sends to B the a 
>    from A, the Tb from T1, the Tc from T2, and the Td from T3. 

>> You might want to explain how this can happen. Its not clear that it 
>> really can given the current transcoding models. It can if you have 
>> intermediaries which act as b2bua and force transcoding without it being 
>> requested.

Answer6: Yes, I think there are two kinds of transcoding: one is with it being requested,
The other is without it being requested. This is last one. 
Does it violate a basic rule of SIP or SDP?

Thanks,
Kang

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 09:36:21 -0500

inline.

강태규 wrote:

> *T**hank for your comments.*
> 
> *Answers are in line:***
> 
> Kang
> 
> *Answer**1**:** "transit party"** support**s** communication between 
> calling party and called party**** using**** transcoding coding 
> capability**.** We can say intermediary** instead of** “**transit 
> party**”**.***
> 
> *I think that there are two ways: one is peer-to-peer without UA**(User 
> Agent)**, the other is with UA.** In this situation,** it means** last 
> one.***

My point was that it is common to have a situation in which there is not
a separate transit provider.

> *Answer**2:** ref 1**2**(RFC 3840) says** that** “**a Session 
> Initiation**** Protocol (SIP) user agent can convey its capabilities and 
> characteristics to other user agents** ..**.**’**. I t**hink it is 
> similar but not exactly same. So, I will** make clear not to confuse it**. *
> 
> *I will** delete** ref 11/12 or** rewrite the sentences at the next 
> version.***

Its just not clear how you are intending this to be used and why.

> *Answer3:** I mean proposing that a new one be developed.** I am not 
> sure whether *
> 
> *an existing SDP attribute** support**s for it or not.** My 
> understanding so far,** *
> 
> *an existing SDP attribute**** does not** support** for it**.** *
> 
> *I** would like to**** discuss** about this issue** at email lists**.***

Whether its necessary depends a lot on how the transcoding services are
invoked. If the transcoding service is picking, on its own, which codecs
to offer to the remote party, and as a consequence, what codecs are
transcoded, there might be a need. If the originator picks the codecs
and tells the transcoder, there would be no need.

> *Answer4:** Yes,** That**’**s right. It means there is no reason code** 
> as far as** I know.** *
> 
> *I try to define it.** I need to discuss** it and more comments.***
> 
> *Answer5:** Thanks. I will** rewrite it with** follow**ing** the 
> convention** response-code(reason) at next version.** Two error codes** 
> are used in internet-draft temp**o**ra**r**y due to** not proper 
> response code.** After**** it**** define**d**, it will be one error code.***
> 
> *Answer6:** Yes,** I think there are two kind**s** of** transcoding**: 
> one is with it being requested,*
> 
> *T**he other is without it being requested.** This is last one.** *

That requires some discussion. I thought that the objective of the
transcoding framework was to allow endpoint control of transcoding services.

-Jonathan R.