Subject: Re: [sipcore] [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 13:27:05 -0400

I was just reminded that conversation stopped when the token was 
probably with me to respond.

I'm taking it to the sipcore list.

On 7/30/13 3:13 AM, Hadriel Kaplan wrote:
>
> On Jul 29, 2013, at 11:06 AM, Paul Kyzivat <[email-masked]> wrote:
>
>> Hadriel,
>>
>> As sipcore co-chair, I also think sipcore will ultimately be the right place for this. But it may be valuable to leave it on dispatch for awhile. My main concern is that we talk through whether the decision to use 205 is well defined, and if introducing this will solve any problems. (And I say this in spite of this having been (IIRC) my suggestion in the first place.)
>>
>> It is far from clear to me whether there can be clear rules for when to use 205.
>> - Should it be used whenever a call has been forwarded?
>
> By "call forwarded", you mean the call/dialog is answered/established at a SIP layer, but then the UAS makes a separate second call to another UA and ultimately bridges the media together?

When I wrote this I was thinking of a target change while routing the 
original INVITE. Of course, it makes no sense to do for every one of 
these, since that includes mapping an AOR to a registered contact.

So that rule is too simple. But can a clear rule be defined?

This starts to smell like the rules used to tag H-I entries. :-(

>> - Should a VM server use it? (In some sense the VM server is an agent
>>   of the callee, and is entitled to use 200.)
>
> You used the phrase "entitled to use 200",

IMO the spec should give some guidance for when to use this. The cases 
where is must or may use it are "entitled", while others are not.

I think the guidance is something like "this is not the intended 
destination for the call".

> but the way I tried writing the 205 draft was not to mandate VMs to use 205 - it was to *allow* them to use 205.  In other words, a VM (or its operator) can decide whether to send a 205 or not, based on what it wants the UAC to do.  The rationale for sending a 205 would be to save resources on the VM, because in theory the UAC can know it's been redirected to voicemail and can hang up immediately. (I'm not saying the draft is good enough yet to make the distinction that it's reached a VM, but that can be worked on...)

Its fair enough to give discretion over when to use this.
But then there must be some expectation for what will be different if I 
use 205 rather than 200, to drive my decision.

In the case of VM, I think there can be some debate whether the VM 
server is one of the legitimate intended destinations of a call or not. 
Whether that is justification for discretion on the part of the server 
depends on whether you think that server is the right place to decide 
that. It may be that we should just decide once and for all.

>> It is also not clear to me that it will solve the traceroute problem.
>> - what if the call is forwarded. Then it might get a 205, but not for
>>   the right reason. Will that be sufficient to stop the traceroute?
>
> Yes - the Reason header will have a cause code of 483 when it's answered by the B2BUA for the traceroute purpose.  Once the testing UAC increases Max-Forwards, the next 205 would have a different Reason code.

OK.

	Thanks,
	Paul