Re: [Sipping] Possible Solution to HERFP

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

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

Well, I could think of the following scenario:

1. INVITE
2. proxy forks
3. an UAC receives: 100
4. 180 ringing
5. User presses 'cancel' (does not want to be disturbed) -> 486 Busy here 
[ maybe some implementations would send 603 decline instead though ]

You could argue that 486 is not a repairable error. In the draft you mention 
"400-class or 500-class response other than a 503, 487, or 408" as 
repairable responses that should trigger a 130, aren't there more cases that 
can potentially cause problems?
Perhaps it would be good to explicitly list those codes that are classified 
as 'repairable', and consider everything else as non-repairable. In 
particular, I think codes in the 4xx-5xx range that are currently undefined 
should be treated as unrepairable.

I am not sure if it would be a problem if the UAC received 2 to tags, 1 from 
the UAS (or UAC) and one from the proxy. If so then perhaps you could 
specify that in case a provisional response other than trying was received 
on the branch, then 130 should not be sent

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

I'll admit I didn't give it much thought yet but a question popped up about 
the case where the UAS would send a provisional response with its own 
to-tag, which would create an early dialog at the caller. The 130 from the 
proxy would generate a second early dialog, what happens to them?

I have a second question regarding section 5 : client should send CANCEL to 
acknowledge reception of the 130. Normally CANCEL should have the same 
request URI as the original request, so this usage of CANCEL seems a bit out 
of the ordinary to me. Could an ACK not be used instead?

For my understanding: if the proxy would generate a final response for each 
repairable error instead, each time generating a new to-tag, then that would 
require modifications to the UAC transaction state machine, right? 
(exception for final error code xxx)


> thanks,
> -rohan
>
>> Jeroen
>>
>> ----- Original Message ----- From: "Rohan Mahy" <[e-mail]>
>> To: "'sipping' WG" <[e-mail]>
>> Cc: "Rohan Mahy" <[e-mail]>
>> 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 [e-mail] for questions on current sip
>>> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP