Re: [Sipping] Possible Solution to HERFP

["Jeroen van Bemmel" <[e-mail]>]

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?
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. 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