Subject: RE: [Sipping] New I-D: A solution for the HERFP caused by forkedSIPINVITE requests

From: Cuda Alberto <[email-masked]>
Date: Sat, 03 Sep 2005 20:10:40 +0200

Hi, Jeroen and all,
I think that option (1) won't work because according to RFC3261:12.2.2 the UAS most
probably will respond 481. Personally, I don't like neither option (2): it
adds an artificial delay, it is not safe (T4 is actually >= 5s), and may
not work with many implementations (I'm thinking of challenge-response 
transactions, many UAS may expect the CSeq to increase when receiving the
authenticated request). I'm not saying it contraddicts some RFC, but it 
behaves "strange" from the UAS' perspective.
The other options I see are:
+ Issuing a re-INVITE, using the Record-Route headers learned in the FIX
  request. This looks like Rohan's solution, and probably ihnerits the
  best from the two;
+ Making the proxy change the From-Tag and behave as a B2BUA.
 
Apart from that, I've some other comments on the draft:
+ I think the UAS too should be able to indicate whether an error code
  is reparaible or not, by using some header (e.g. HERFP-Disposition):
     - It is useful for error codes the proxy is not aware of (the UAS
       is the one that knows its meaning for sure);
     - It may contain some policy the UAS would like to apply;
     - It is needed in case two HERFP-aware proxies are in the signalling
       path: the downstream proxy needs to ask the upstream proxy not
       to treat the error response it is sending as a repairable error;
     - It can be used by UAS HERFP-aware to tell the proxy they don't mind 
       receiving two requests that look like they are merged, so the 
       proxy does not need to apply the workaround for the issue you
       outlined;
+ I'd prefer the proxy generated FIX method to have a different name 
  from the one generated by the UAS: it is a possible source of confusion
  for intermediate elements, endpoints (in case they behave as UAS and
  proxies) and human beings;
+ It is not clear how the best response selection algorithm will be
  affected: from paragraph 4.1 it looks like an HERFP proxy always
  responds 408. This might break service logics on upstream proxies:
  I think the best reponse sent should be the best response received 
  excluding those that were accepted by the UAC. Note also that
  when sending that response back, the HERFP-Disposition header 
  should be set accordingly;
+ It is not clear how the authentication described in paragraph 5 should
  work: it is very unlikely the proxy and the UAC know each other;
+ I find rather confusing the construction of the two FIX requests:
  they are not in session nor out of session. In particular, if the
  FIX request sent by the UAC is in session, a provisional response
  should be sent be the proxy beforehand. The FIX request sent
  by the proxy should probably be described by splitting the proxy
  into a [proxy] and an [UA]. The [proxy] does not record-route and
  send the request to the [UA], which constructs the request using 
  the procedures described un RFC3261 and its possible updates;
+ You should point out which headers MUST be present in the sipfrag
  body sent in the FIX request sent by the proxy. I think all the
  headers describing options supported by the UAS must be present
  (I mean Allow, Allow-Events, Supported and the like). This allows
  to repair in alternative ways (for instance 486 with Allow-Events
  set to dialog can be repaired by subscribing to the UAS).
 
     Cheers.
        Alberto.

________________________________

From: [email-masked] on behalf of Jeroen van Bemmel
Sent: Fri 9/2/2005 8:14 PM
To: sipping
Subject: Re: [Sipping] New I-D: A solution for the HERFP caused by forkedSIPINVITE requests

To start off:
 
For an unreliable transport the INVITE server transaction at the UAS remains in the CONFIRMED state for T4 (default : 5sec) after receiving an ACK. If the modified INVITE arrives within that time, according to section 8.2.2.2 the UAS will see it as a looping request (since it will have the same CSeq, from-tag and Call-ID)
 
What would be the least painful workaround?
1. Have the UAC or proxy select a to-tag, such that 8.2.2.2 processing is skipped
2. Have the proxy delay if less than 5sec has passed since the ACK was sent
3. Other options?
 
(all only in case an unreliable transport is used)
 
Regards,
 
Jeroen

	----- Original Message ----- 
	From: Jeroen van Bemmel <mailto:[email-masked]>  
	To: sipping <mailto:[email-masked]>  
	Sent: Friday, September 02, 2005 7:36 PM
	Subject: [Sipping] New I-D: A solution for the HERFP caused by forked SIPINVITE requests

	All,
	 
	I have submitted a new Internet Draft regarding HERFP to the IETF. While it is being processed, a copy of the document can be found here to start discussions: http://home.versatel.nl/jbemmel/draft-jbemmel-herfp-solution-00.txt
	 
	Best regards,
	 
	Jeroen van Bemmel

________________________________

	_______________________________________________
	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

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

_______________________________________________
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