Re: [Sipping] Possible Solution to HERFP

[Rohan Mahy <[e-mail]>]

On Jul 24, 2005, at 7:00, Jeroen van Bemmel wrote:

> Rohan,
>
> OK, I will work on that. For clarification: you have not abandoned the 
> HERFP fix draft, right?
>
> In section 4.1 you define a repairable response as a '400-class or 
> 500-class response other than a 503, 487, or 408'. Did you perhaps 
> mean 403 Forbidden instead of 503 here?

no, I meant 503.

> And perhaps this range is too broad? e.g. consider the case where a 
> called user presses 'cancel' on his phone to refuse an incoming call 
> which generates a '486 Busy here'; it would be annoying when the phone 
> rings again.

Francois Audet already made a similar comment.  I'm not sure I want to 
enumerate all the response codes that are repairable, but I agree the 
486 is not repairable in the traditional sense.

note though that, a user pressing a button on a phone has a semantic 
closer to 603 Decline, but I understand that the user may want to 
trigger voicemail or an attendant or something.

thanks,
-rohan

> Such "try again later" responses should IMO be communicated to the 
> caller, but any Retry-After headers should be honored. And a 486 
> without a Retry-After should probably not result in a second attempt
>
> Jeroen
>
> ----- Original Message ----- From: "Rohan Mahy" <[e-mail]>
> To: "Jeroen van Bemmel" <[e-mail]>
> Cc: "Rohan Mahy" <[e-mail]>; "Paul Kyzivat" 
> <[e-mail]>; "sipping" <[e-mail]>
> Sent: Wednesday, July 20, 2005 1:16 AM
> Subject: Re: [Sipping] Possible Solution to HERFP
>
>
>> Hi Jeroen,
>>
>> Rather than design on the fly on the SIP WG mailing list, I suggest 
>> if you have additional ideas about how to solve HERFP, you instead 
>> write a draft explaining how your proposed mechanism works.  The 
>> action of writing such a proposal usually uncovers a large number of 
>> problems.  I have abandoned what I thought was a "great idea" after 
>> writing a draft explaining the idea uncovered fatal flaws.  Even when 
>> I have an idea that works well, I usually uncover new aspects I had 
>> not specified or understood.
>>
>> On Jul 19, 2005, at 15:31, Jeroen van Bemmel wrote:
>>> Hi Rohan,
>>>
>>> We are talking about the INVITE client transaction state machines at 
>>> intermediaries here, right?
>>
>> well, i was actually thinking of the UAC state machine, but it would 
>> affect the intermediaries as well.
>>
>>> Would it really make a difference to them? 300-699 takes them into 
>>> the completed state,
>>
>> if you send a final response to indicate a recoverable error, there 
>> is no way to forward another response later from another branch (for 
>> example a 200).
>>
>>> 2xx terminates the transaction. In either case they are already 
>>> required to pass on responses with no matching transaction upstream 
>>> statelessly (section 16.7)
>>
>> forwarding non-matching responses was deprecated with the approval of 
>> draft-sparks-sip-nit-actions
>>
>>> What about the Route idea?
>>
>> most UAs that I know will reject a request if there are any Routes 
>> left.
>>
>> thanks,
>> -rohan
>>
>>> Jeroen
>>>
>>> ----- Original Message ----- From: "Rohan Mahy" <[e-mail]>
>>> To: "Jeroen van Bemmel" <[e-mail]>
>>> Cc: "Rohan Mahy" <[e-mail]>; "Paul Kyzivat" 
>>> <[e-mail]>; "'sipping' WG" <[e-mail]>
>>> Sent: Wednesday, July 20, 2005 12:12 AM
>>> Subject: Re: [Sipping] Possible Solution to HERFP
>>>
>>>
>>>> Hi Jeroen,
>>>>
>>>> This would be a dramatic change to the INVITE transaction state 
>>>> machine which would certainly break many intermediaries.  I don't 
>>>> think that would be advisable.
>>>>
>>>> thanks,
>>>> -rohan
>>>>
>>>>
>>>> On Jul 19, 2005, at 14:14, Jeroen van Bemmel wrote:
>>>>
>>>>>>> Could an ACK not be used instead?
>>>>>>
>>>>>> ACKs aren't used with 1xx responses, so this would also be out of 
>>>>>> the ordinary.
>>>>>>
>>>>>
>>>>> I was thinking about the proxy sending a final response (perhaps 
>>>>> with no to-tag) instead of the 130, then the UAC could send an ACK 
>>>>> as usual which the proxy could use as a signal to exclude that 
>>>>> branch from consideration as a 'best response'. This would 
>>>>> probably require a change to the UAC transaction state logic, i.e. 
>>>>> not only be prepared to receive multiple 2xx responses but also 
>>>>> multiple of such not-quite-final responses. To avoid such a change 
>>>>> a code in the 2xx range could be chosen, but that seems not right 
>>>>> semantically (unless you consider it a success to have located a 
>>>>> repairable responder)
>>>>>
>>>>> About the new INVITE that is supposed to fix the repairable error: 
>>>>> should you not make sure that it follows the exact same path as 
>>>>> the original, avoiding forks along the way? What if the proxy 
>>>>> would form the Contact header with a list of Route headers 
>>>>> corresponding to the path calculated from the INVITE it got 
>>>>> originally, possibly extended with a Route entry that points to 
>>>>> the UAS that responded with an error? I think this would make sure 
>>>>> that any forking proxies along that path don't try their forking 
>>>>> trick again, making the fix very targeted
>>>>>
>>>>> Regards,
>>>>>
>>>>> jeroen


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP