Re: [Sipping] Possible Solution to HERFP

[Rohan Mahy <[e-mail]>]

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