Re: [straw] draft-straw-sip-traceroute-00

[Paul Kyzivat <[e-mail]>]

On 7/15/13 10:12 PM, Hadriel Kaplan wrote:
>
> On Jul 15, 2013, at 5:45 PM, Paul Kyzivat <[e-mail]> wrote:
>> OK, I guess we did have some discussion on that.
>>
>> By that argument it must be something *existing* in SDP that is never messed with. That is a high bar.
>>
>> You have a product that messes with SDP. When you do so, do you mess with the version? (It seems like you *ought* to, since you are changing it.)
>
> Sometimes yes, sometimes no.  But I'm not too worried about my product - it's more the *other* B2BUAs and SBCs I'm worried about.

Well, the fact that you say "sometimes yes" already suggests problems.

>> Do you think that a new return code would cause trouble this way?
>> I would think that to be fairly innocuous. But there are no guarantees when going through a B2BUA.
>
> I honestly have no idea.  I don't know what most vendor products would do with a previously-unknown response code number coming back.
>
> It feels like the right thing to do from a protocol perspective, but I don't know what would happen.
>
> We could also, in the same 205 response, insert a Reason header with "SIP;cause=483" as the value.  That way even if it's converted to a 200 OK response, the Reason
> header might make it back. (ugly hack, but the whole problem is ugly)

I like it!

I thought about the Reason header, but couldn't think of a way to use it 
without introducing a new reason namespace. What you suggest does it 
with existing ones. I don't see it as a bad hack.

	Thanks,
	Paul