Subject: RE: [Sipping] Possible Solution to HERFP

From: "Francois Audet" <[email-masked]>
Date: Sat, 9 Jul 2005 12:10:36 -0500

Phone rings, then somehow call is aborted.

I think it is a common scenario.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rohan Mahy
> Sent: Saturday, July 09, 2005 03:01
> To: Jeroen van Bemmel
> Cc: Rohan Mahy; 'sipping' WG
> Subject: Re: [Sipping] Possible Solution to HERFP
> 
> 
> 
> On Jul 9, 2005, at 2:10, Jeroen van Bemmel wrote:
> 
> > Hi Rohan,
> >
> > Section 3 picture at the end: what happens if UAS1 sends some
> > provisional response (with a to-tag) before sending the 415?
> 
> Why would UAS1 send any provisional response (other than a 
> 100 Trying) 
> before figuring out there was an error?  I've never seen an 
> implementation do this, and the spec is pretty clear that you 
> immediately send these error before you get the the processing stage 
> where you would normally send a 18x.
> 
> > If the proxy generates a to-tag of its own for the 130, wouldn't the
> > UAC get confused?
> 
> are you asking this in general, or only after the UAS sent its own 
> to-tag?
> 
> thanks,
> -rohan
> 
> > Jeroen
> >
> > ----- Original Message ----- From: "Rohan Mahy" <[email-masked]>
> > To: "'sipping' WG" <[email-masked]>
> > Cc: "Rohan Mahy" <[email-masked]>
> > Sent: Saturday, July 09, 2005 4:41 AM
> > Subject: [Sipping] Possible Solution to HERFP
> >
> >
> >> Hi Folks,
> >>
> >> I just submitted a new individual I-D that describes a possible
> >> solution to the Heterogeneous Error Response Forking 
> Protocol.  Until 
> >>  it appears in the archives, you can find it here:
> >>
> >> 
> https://scm.sipfoundry.org/rep/ietf-drafts/rohan/herf-fix/draft-mahy-
> >> sipping-herfp-fix-00.txt
> >> 
> https://scm.sipfoundry.org/rep/ietf-drafts/rohan/herf-fix/draft-mahy- 
> >> sipping-herfp-fix-00.html
> >>
> >> thanks,
> >> -rohan
> >> (as an individual)
> >>
> >>
> >> _______________________________________________
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments of core SIP
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 

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

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 9 Jul 2005 12:11:39 -0500

> And a couple of tiny nits that you can completely ignore:
> 
>     * I think I would call 130 something more like "Branch Error"
>       instead of "Reparable Error." Most errors conveyed 
> won't be reparable.
> 
>     * Appendix A is certainly useful for describing the problem, but I
>       can already imagine the confused emails on the sip implementors
>       list asking about the 155 error response code, and the use of
>       COMET. I would suggest removal of section A.2.

I support both suggestions.

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 9 Jul 2005 12:45:09 -0500

> > currently RFC 3261 requires an offer or an answer to be in 
> the first 
> > reliable message after an INVITE.  If we can change the 
> behavior in a 
> > reasonable way then great, but right now that is best 
> behavior that I 
> > could come up with that doesn't violate the core spec.  suggestions 
> > are welcome here.
> 
> 
> I might be missing the lore, but my reading of the first two 
> bullets in 
> the rules regarding offer/answer is:
> 
>     * The initial **OFFER*** must be in either an invite or 
> in the first
>       reliable non-failure message.
>     * If the initial offer is in in invite, the answer must be in
>       ***A*** reliable non-failure message.
> 
> Thinking through this, it appears place a requirement on proxies 
> supporting herf to send offers in reliable provisionals if the invite 
> didn't contain one -- and I think that's fine. However, it 
> doesn't seem 
> to require placement of an answer in the *first* reliable non-failure 
> message, simply in one of them (presumably before the 
> transaction succeeds).
> 
> Given this reading, I could build a client compliant with 
> 3261 and 3262 
> that, upon receipt of an INVITE with SDP, sent its first "180 
> Ringing" 
> message reliably without SDP, and then followed up later with 
> a reliable 
> 180 containing SDP. If, for some reason (e.g. the user 
> presses a "do not 
> disturb" button), the transaction ends before the second 180 is sent, 
> then no answer to the offer ever crosses the wire.

Interesting, I had tought initially that the offer had to be in the
first
reliable response, but I believe your reading is right. This is good as
it does alleviate the problem significantly.

In the case where the INVITE included the offer, if there is a branch
that fails
(say 4XX), then it allows the forking proxy to send a 130 w/4XX reliably
without
adding an answer in it. This is half of the problem solved (and also the
most
common scenario). We should probably explain this explicitly in the
document.

I believe however that we still have a problem if there is no offer in
the INVITE.
If a branch fails in this case (say 4XX), then the forking proxy which
is sending
the 130 w/4XX has the problem that if it wants the 130 to be sent
reliably, it has
to insert some "bogus" SDP in it. I see the following alternatives:

1- The proxy adds some sort of "null" Offer in the 130 (maybe port 0,
or something
   else). Kind of ugly...

2- Don't allow for reliable 130 in this case. Kind of ugly as well, and
doesn't work if
   100rel was Required.

3- Allow for reliabe 130 to NOT have an SDP. That would violate existing
spec, and is 
   probably not doable.

The least bad seems to be 1. Other ideas?

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 20 Jul 2005 01:00:05 +0200

On second thought..

In completed state these intermediaries would filter out subsequent HERFP 
responses (consider them as retransmissions), and it's not sure what they 
would do to a 2xx response arriving after a 300-699 response (likely block 
it too). So a special 2xx code would probably be better than a final non-2xx 
code

JvB

> Hi Rohan,
>
> We are talking about the INVITE client transaction state machines at 
> intermediaries here, right? Would it really make a difference to them? 
> 300-699 takes them into the completed state, 2xx terminates the 
> transaction. In either case they are already required to pass on responses 
> with no matching transaction upstream statelessly (section 16.7)
>
> What about the Route idea?
>
> Jeroen
>
> To: "Jeroen van Bemmel" <[email-masked]>
> Cc: "Rohan Mahy" <[email-masked]>; "Paul Kyzivat" <[email-masked]>; 
> "'sipping' WG" <[email-masked]>
> Sent: Wednesday, July 20, 2005 12:12 AM
>> 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
>>
>