Subject: [MEDIACTRL] Alligning error codes between msc-ivr and msc-mixer

From: Stéphane Bastien <[email-masked]>
Date: Sat, 25 Apr 2009 05:28:42 -0700

Hi,

Would it be possible to allign msc-ivr and msc-mixer error codes? For example:

connectionid does not exist: msc-ivr: 407  msc-mixer: 412
conferenceid does not exist: msc-ivr: 408 msc-mixer: 406
incompatible stream config: msc-ivr: 411 msc-mixer: 407
unsupported foreign namespace: msc-ivr 431 msc-mixer: 428
other unsupported capability: msc-ivr: 439 msc-mixer: 435

Thanks,

Stéphane

---

From: Eric Burger <[email-masked]>
Date: Sun, 26 Apr 2009 07:02:46 -0400

That would be a great idea.

On Apr 25, 2009, at 8:28 AM, Stéphane Bastien wrote:

> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: Eric Burger <[email-masked]>
Date: Sun, 26 Apr 2009 07:04:27 -0400

Although thinking about it a bit more, one could argue that packages  
are independent of one another. Assuming error codes map may be a  
really, really bad thing. By having the error codes different in the  
first set of IETF packages, we highlight to implementors they really,  
really need to read the specification.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sun, 26 Apr 2009 13:51:38 +0200

Without knowing what this is about in detail, I find the last call for 
unintuitive design not appealing.
I think for some good reason response/error codes in SIP are mimicking 
HTTP ones.

Giving the same error reason a different code in each and every package 
is helping really no one. Being able to guess what a certain code means 
is a good thing in practice.

/Hans Erik

Eric Burger wrote:
> ------------------------------------------------------------------------
>

---

From: Eric Burger <[email-masked]>
Date: Sun, 26 Apr 2009 18:10:10 -0400

So long as the error codes are ALWAYS the same.

The point is one cannot create a generic package error code handler.  
You will have to write an IVR, "What do I do with a 407 error code"  
handler AND A SEPARATE "What do I do with a 407 error code" handler  
for MIXER.

Just assuming they are the same will most likely bit an implementer,  
UNLESS we say there is a closed set of error codes (which is OK with  
me), meaning 407 is the same for ALL packages, whether 407 is  
appropriate or not. Likewise, I would expect a bunch of entries in the  
IANA table that will be for one and only one package.  So be it.

On Apr 26, 2009, at 7:51 AM, Hans Erik van Elburg wrote:

> Without knowing what this is about in detail, I find the last call  
> for unintuitive design not appealing.
> I think for some good reason response/error codes in SIP are  
> mimicking HTTP ones.
>
> Giving the same error reason a different code in each and every  
> package is helping really no one. Being able to guess what a certain  
> code means is a good thing in practice.
>
> /Hans Erik
>
> Eric Burger wrote:
>> Although thinking about it a bit more, one could argue that  
>> packages are independent of one another. Assuming error codes map  
>> may be a really, really bad thing. By having the error codes  
>> different in the first set of IETF packages, we highlight to  
>> implementors they really, really need to read the specification.
>>

---

From: Eric Burger <[email-masked]>
Date: Sun, 26 Apr 2009 18:11:34 -0400

[I need to stop pressing Send so fast]

Also, to do this, we will need to update Framework to say the package  
error code space is closed and flat and NOT per-package.

On Apr 26, 2009, at 6:10 PM, Eric Burger wrote:

> appropriate or not. Likewise, I would expect a bunch of entries in  
> the IANA table that will be for one and only one package.  So be it.
>
>> package is helping really no one. Being able to guess what a  
>> certain code means is a good thing in practice.
>>
>> /Hans Erik
>>
>> Eric Burger wrote:

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 27 Apr 2009 00:16:10 +0200

Ok I was thinking about the poor people staring at Wireshark traces to 
find out why something doesn't work as they expected. That is probably a 
much larger group then the few implementors of whom one should expect 
they have read the specification!

/Hans Erik

---

From: Chris Boulton <[email-masked]>
Date: Mon, 27 Apr 2009 10:17:05 +0100

I would rather not change the Framework OR IVR drafts at this stage.  
While I see small amount of merit in the small number of response codes 
aligning I do not think its worth the additional effort of opening up 
the specs.  Lets just get them published.  I am not against aligning the 
mixer package.

Chris.

Eric Burger wrote:
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.287 / Virus Database: 270.12.4/2081 - Release Date: 04/26/09 09:44:00
>
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 27 Apr 2009 06:56:58 -0400

I would offer there is nothing worse than "almost standard."  Either  
response codes MUST align or response codes are independent.

Having response codes SOMETIMES align is a formula for non- 
interoperation.

On Apr 27, 2009, at 5:17 AM, Chris Boulton wrote:

> I would rather not change the Framework OR IVR drafts at this  
> stage.  While I see small amount of merit in the small number of  
> response codes aligning I do not think its worth the additional  
> effort of opening up the specs.  Lets just get them published.  I am  
> not against aligning the mixer package.
>
> Chris.
>
>
> Eric Burger wrote:
>> Also, to do this, we will need to update Framework to say the  
>> package error code space is closed and flat and NOT per-package.
>>
>>> The point is one cannot create a generic package error code  
>>> handler. You will have to write an IVR, "What do I do with a 407  
>>> error code" handler AND A SEPARATE "What do I do with a 407 error  
>>> code" handler for MIXER.
>>>
>>> Just assuming they are the same will most likely bit an  
>>> implementer, UNLESS we say there is a closed set of error codes  
>>> (which is OK with me), meaning 407 is the same for ALL packages,  
>>> whether 407 is appropriate or not. Likewise, I would expect a  
>>> bunch of entries in the IANA table that will be for one and only  
>>> one package.  So be it.
>>>
>>>> Without knowing what this is about in detail, I find the last  
>>>> call for unintuitive design not appealing.
>>>>> packages are independent of one another. Assuming error codes  
>>>>> map may be a really, really bad thing. By having the error codes  
>> Checked by AVG - www.avg.com Version: 8.5.287 / Virus Database:  
>> 270.12.4/2081 - Release Date: 04/26/09 09:44:00
>>
>>
>

---

From: Chris Boulton <[email-masked]>
Date: Mon, 27 Apr 2009 14:11:40 +0100

Then I vote not to align.

Chris.

Eric Burger wrote:
> Having response codes SOMETIMES align is a formula for 
> non-interoperation.
>
>
>> While I see small amount of merit in the small number of response 
>> codes aligning I do not think its worth the additional effort of 
>> opening up the specs.  Lets just get them published.  I am not 
>> against aligning the mixer package.
>>
>> Chris.
>>
>>
>> Eric Burger wrote:
>>>> whether 407 is appropriate or not. Likewise, I would expect a bunch 
>>>> of entries in the IANA table that will be for one and only one 
>>>> package.  So be it.
>>>>

---

From: Stéphane Bastien <[email-masked]>
Date: Mon, 27 Apr 2009 06:18:34 -0700

Non-alignment of error codes makes the life of implementers harder, both on the client and the server side. How can making the life of implementers harder lead to a more interoperable protocol?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 27 avril 2009 09:12
To: Eric Burger
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Alligning error codes between msc-ivr and msc-mixer

Chris.

---

From: Eric Burger <[email-masked]>
Date: Mon, 27 Apr 2009 10:08:44 -0400

Because it highlights that it is not easy.  Having the error codes  
SOMETIMES alight is DECEPTIVELY easy, except for when they do not.

Not aligning includes a bad server returning an incorrect error code  
for the package that happens to have an interpretation in another  
package or a bad client that does not take the appropriate action for  
a package when it receives a shared error code.

Again, if the thought is the implementor will write a single result  
code processing module, we should write the specification to reflect a  
single result code processing module. That is, we explicitly state  
there is a single result code space that all packages share.

On Apr 27, 2009, at 9:18 AM, Stéphane Bastien wrote:

> Non-alignment of error codes makes the life of implementers harder,  
> both on the client and the server side. How can making the life of  
> implementers harder lead to a more interoperable protocol?
>
>>>>> bunch
>>>>>>> map

---

From: Chris Boulton <[email-masked]>
Date: Mon, 27 Apr 2009 18:44:13 +0100

> there is a single result code space that all packages share.
[Chris] And my vote was based on Eric's assumption.  If it has to be in 
the Framework which means yanking it - then I am against.  Lets get 
these docs published (Framework and IVR).  We had years of review and 
multiple WGLC for such changes.

Chris.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 27 Apr 2009 14:35:40 -0500

Just to chime in as co-chair, this IS the kind of change that would have 
been good to chat about before sending the framework (and IVR) draft forward 
for publication ... but I'm not seeing it as a discussion about a technical 
flaw in the protocol.

As co-chair, I try not to be authoritarian, but in this case, I may be 
making an exception.

I think it's important for us to correct any technical flaws in the 
protocol, but I'm not seeing a benefit from revisiting framework, plus ivr, 
plus mixer that's been through working group last call, plus the call flows 
draft that has been faithfully kept up to date with protocol specification 
revisions, that's big enough to justify the cost of respinning.

We have to finish our work, in order for people to use it. From my 
perspective, we have an opportunity to finish these protocols, and finish 
MRB, and have that work pop into 3GPP and ATIS specs (to name two 
organizations who I'm told are interested in using MRB), but our window of 
opportunity isn't large. I'd like to see our work used, and not ignored 
because people used something that WAS finished, while we were still 
polishing ... :-(

Thanks,

Spencer

>> Again, if the thought is the implementor will write a single result code 
>> processing module, we should write the specification to reflect a single 
>> result code processing module. That is, we explicitly state there is a 
>> single result code space that all packages share.
>>
> the Framework which means yanking it - then I am against.  Lets get these 
> docs published (Framework and IVR).  We had years of review and multiple 
> WGLC for such changes.