Subject: [Sipping] New I-D: A solution for the HERFP caused by forked SIP INVITE requests

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 2 Sep 2005 19:36:38 +0200

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 2 Sep 2005 20:14:43 +0200

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 
  To: sipping 
  Sent: Friday, September 02, 2005 7:36 PM
  Subject: [Sipping] New I-D: A solution for the HERFP caused by forked SIPINVITE requests

  All,

  Best regards,

  Jeroen van Bemmel

------------------------------------------------------------------------------

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 3 Sep 2005 23:14:20 +0200

Hi Cuda,

Thank you for your extensive comments. Let me try to respond to them, please see inline below

Best regards,

Jeroen
  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;

The reason why things got complicated, is that I originally felt that the modified INVITE should have the same CSeq number such that any proxies in the path between the UAC and the HERFP proxy (and the UAC itself) would not see strange responses with wrong CSeq headers. However, I now think that perhaps it isn't such a big deal if that happens, since CSeq in responses is rarely touched (perhaps used to match response to its request, but the transaction also does that and if the UAC knows what's happening it can accomodate). In that case simply incrementing the CSeq for the modified INVITE would solve this issue.

Regarding sending a FIX with an INVITE as body versus sending a new INVITE: It seemed appropriate to me to send something else than an INVITE, since it's not a new call attempt but a tweak to an existing one. However, that can also be said e.g. for an INVITE after a challenge. Another reason why INVITE could be more convenient, is in case of a proxy that is performing identity services. A modified INVITE could be passed to the same proxy as the original INVITE, a FIX with an INVITE body would complicate the identity service at the proxy (as it must then understand FIX and pick it from the body first). Downside of INVITE would be a spurious ACK from the UAC to the proxy, but since it would only be needed in case user interaction is used (or identity service is required) this could be acceptable.

  + Making the proxy change the From-Tag and behave as a B2BUA.
   
Downside of that would be that it would have to stay in the loop and tweak each request that comes by

  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;

Interesting idea, but if the UAS would apply this it would be aware of this HERFP solution, right? So it could issue a FIX itself rather than hope that a proxy along the path understands its policy and the HERFP-Disposition header. Regarding the 3rd point, the current intention is to never let the HERFP proxy send a repairable error, to avoid duplicate FIXes. I'll make this explicit in the text

  + 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;

I would say that since semantically it does the same thing (notify the UAC of a repairable response), a different name would be confusing. I thought about some other means to make the distinction (perhaps some header, or UAS always with to-tag and proxy not) but then again: who needs to know?

A FIX sent by the UAC is slightly different (notify the proxy/UAS of a modification to the original INVITE), so perhaps that should be called differently (or be replaced with an INVITE, see above). On the other hand, we already have so many SIP method names...

Other people have an opinion on this?

  + 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;

The intention was to always send 408 instead of the repairable response that was received, if there is no better alternative. So the proxy does not always respond with a 408. This avoids the proxy sending back a repairable response, hence (at least for this issue) the disposition is not nescessary. Perhaps some other code would be better, to distinguish a "repairable response that was not fixed" from a real timeout. It would still need to be declared "not repairable"; how about "410 Unfixed Response" (maybe even with all content of the response that was received, and a Reason with the original code) ? 

  + 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;

You're right, it should be done only in case they do know each other (or at least the proxy knows the UAC)

  + 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;

I agree that it's confusing, things occur before a session has been setup so "not in session nor out of session" is correct. I would say "the requests are in the context of a call attempt". 
A FIX sent by a UAC would only be in session (have a to-tag) when the repairable response contained one. This would happen when the UAS sent a provisional response with a to-tag, before sending a repairable response. The text now says that the UAS should generate a to-tag if not already existing, but that may not be a good idea.

The proxy sending the FIX is acting as a UAC. The route-set construction is actually copied from RFC3261 section 12.2.1.1, replacing "UAC" with "UAC/UAS/proxy", it's like a dialog is being constructed for one-time usage.

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

The draft currently says "everything minus the Via headers, but with the one the UAC added (so it can match the response with an INVITE client transaction)"; I think that would allow your scenario of alternative repair?

Perhaps the MIME type should be message/sip instead of message/sipfrag, what do you think?

       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:

   
   
  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,

  Best regards,

  Jeroen van Bemmel

  ________________________________

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 4 Sep 2005 00:09:08 +0200

All,

With apologies for the monologue, I'd like to share a thought I had after submitting the draft:

Instead of sending the modified INVITE back to the proxy and merge it with the ongoing call attempt, a new (second) call attempt by the UAC would be much simpler. The proxy could provide the Request URI it used in a Contact header (perhaps along with other information that resulted from consulting the location service) and send the response in a FIX body as described. The UAC can accept it or not, the proxy considers the branch failed regardless. The second INVITE will not follow the same route as the original, but the question is: is that really a problem?

UAS would be similar: FIX with Contact header (as it would provide in a 2xx response to the INVITE)

Regards,

Jeroen

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

  All,

  Best regards,

  Jeroen van Bemmel

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 4 Sep 2005 18:42:03 +0200

Hi Alberto,

I appreciate your comments. I am reworking the draft to use an INVITE rather than a FIX from the UAC, I've come to the conclusion that it simplifies things greatly (e.g. no merging at the proxy) which IMO outweighs the concern that it would not follow the same route. I briefly considered a new '411 FIX attempted' response code instead of a received repairable error, but I am now thinking to have the proxy add a 'FIX-Status: nnn' header when it selects a repairable error as best response (nnn being the UAC's answer to its FIX request).

So: To HERFP-enable a forking proxy one would make 2 modifications:
1. Send a FIX request for repairable errors (the set of repairable errors being a configuration setting) if allowed by the UAC
2. If the response selection algorithm selects a repairable error, it adds a 'FIX-Status: <code>' with <code> being the UAC's response to the FIX request

I think this will not break existing service logic, while allowing HERFP proxies to detect when a FIX was already attempted (and not try one of their own unless the code was something like timeout or transport error). This will work for the scenario you give below, an 'old' PX2 will still redirect-on-busy.

I'll try to refer as much as possible to RFC3261 without too much copying.

Regarding the RPC-like exchange that is needed in many scenarios: as you state yourself, keeping the protocol "strongly typed" is a good thing. Any generic mechanism with a method like "DO" or "SERVICE" goes against that principle. What could be useful is to standardize the interaction patterns, and have new method definitions refer to those. For example, the pattern I was proposing before where the UAC would put its answer in the response unless that took too long, in which case it would respond with a '202' and generate a request of its own later. 

Regards,

jeroen

  Hi Jeroen, thanks for your answers, please see comments inline.

  >The reason why things got complicated, is that I originally felt that the modified INVITE should have the same CSeq number such that any proxies in the path between the UAC and the HERFP proxy (and 
  >the UAC itself) would not see strange responses with wrong CSeq headers. However, I now think that perhaps it isn't such a big deal if that happens, since CSeq in responses is rarely touched (perhaps 
  >used to match response to its request, but the transaction also does that and if the UAC knows what's happening it can accomodate). In that case simply incrementing the CSeq for the modified INVITE 
  >would solve this issue.
  I'd rather try not to touch the CSeq header, since that would make them overlap
  with new requests (e.g. BYE) sent by the UAC (if I understand your sentence correctly).

  >Regarding sending a FIX with an INVITE as body versus sending a new INVITE: It seemed appropriate to me to send something else than an INVITE, since it's not a new call attempt but a tweak to an 
  >existing one. However, that can also be said e.g. for an INVITE after a challenge. Another reason why INVITE could be more convenient, is in case of a proxy that is performing identity services. A 
  >modified INVITE could be passed to the same proxy as the original INVITE, a FIX with an INVITE body would complicate the identity service at the proxy (as it must then understand FIX and pick it from 
  >the body first). Downside of INVITE would be a spurious ACK from the UAC to the proxy, but since it would only be needed in case user interaction is used (or identity service is required) this could 
  >be acceptable.
  Yes, I think it's the most promising way.

  >Downside of that would be that it would have to stay in the loop and tweak each request that comes by
  Right.

  >Interesting idea, but if the UAS would apply this it would be aware of this HERFP solution, right? So it could issue a FIX itself rather than hope that a proxy along the path understands its policy 
  >and the HERFP-Disposition header. 
  I was thinking of an UAS that did not want to implement the full mechanism for
  instance due to complexity or bandwidth constraints, or to explictly request 
  not to repair an error while still giving a signficative error response.

  >I would say that since semantically it does the same thing (notify the UAC of a repairable response), a different name would be confusing. I thought about some other means to make the distinction 
  >(perhaps some header, or UAS always with to-tag and proxy not) but then again: who needs to know?
  Sorry, that was a typo: I meant the UAC, not UAS. 

  >A FIX sent by the UAC is slightly different (notify the proxy/UAS of a modification to the original INVITE), so perhaps that should be called differently (or be replaced with an INVITE, see above). On 
  >the other hand, we already have so many SIP method names...

  Well, IMHO keeping the protocol "strongly typed" is a valuable asset, so
  if INVITE is not used, I'd prefer a couple of new methods. Besides I've
  seen a similiar RPC-like exchange also in other scenarios, when endpoints
  need to exchange some extra information, or one of them needs to ask the 
  other to perform an operation and report its results. This is typically
  achieved with SUBSCRIBE/NOTIFY or MESSAGE/MESSAGE transactions, and it
  is often quite awkard. Long time ago there was a proposal to use SOAP
  (using the SERVICE method) for similar purposes. I wonder if it could
  be a good idea to specify a base mechanism for UA to UA exchanges
  and make all these scenarios work as an application of it. 

  >The intention was to always send 408 instead of the repairable response that was received, if there is no better alternative. So the proxy does not always respond with a 408. This avoids the proxy 
  >sending back a repairable response, hence (at least for this issue) the disposition is not nescessary. Perhaps some other code would be better, to distinguish a "repairable response that was not 
  >fixed" from a real timeout. It would still need to be declared "not repairable"; how about "410 Unfixed Response" (maybe even with all content of the response that was received, and a Reason with the 
  >original code) ? 
  Suppose the following scenario: UA1->Px1->Px2->UA2. 
  Px2 implements something like call forwarding on busy condition, but
  UA1 knows the HERFP extension: Px2 has no chance to redirect the call.
  I think that UA1 should have a chance to tell it is not willing to
  repair the error but to keep it as a candidate response.

  >The proxy sending the FIX is acting as a UAC. The route-set construction is actually copied from RFC3261 section 12.2.1.1, replacing "UAC" with "UAC/UAS/proxy", it's like a dialog is being constru…
  Ok. My suggestion was to break the HERFP proxy into two base entites described
  in the RFC3261 in order to substitute this sentence with a pointer to that
  paragraph, just to keep it forward compatible with possible extensions.

  >The draft currently says "everything minus the Via headers, but with the one the UAC added (so it can match the response with an INVITE client transaction)"; I think that would allow your scenario…
  Yes, I agree it should work. 

      Cheers.
           Alberto.

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 07 Sep 2005 16:07:41 -0400

On Fri, 2005-09-02 at 20:14 +0200, Jeroen van Bemmel wrote:
> 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)
>  

I've been told (and I agree) that it is impossible for a proxy to
determine accurately whether a request is looping or not, since a
request may legitimately loop through a proxy if it is "different", and
the proxy really can't judge what differences will be significant to the
destination UAS or not.  So best current practice is for a proxy to not
do loop detection at all, but rather leave it to the UAS.

When a UAS receives an INVITE with the same dialog identifiers as it has
already received, it needs to judge whether this INVITE is "different"
from the previous one.  Assuming that the new one is "fixed" so that the
UAS will respond to it differently, it should not flag it as a duplicate
of the previous INVITE.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 07 Sep 2005 15:54:25 -0500

> do loop detection at all, but rather leave it to the UAS.

YMMV.  I agree that looping in the 3G/IMS world with the request
being shuttled between various servers is problematic and best
turned off.  However, loop detection as envisioned in rfc3261 (and
rfc2543), at the very least, stops a spurious request from chewing
up further network and endpoint resources as it was routed multiple
times to its destination.

But insofar as it is the job of the proxy to route requests, it
should be able to factor in those headers that aid in routing to
determine whether a request has looped or legitimately spiraled.

Now merged request is another matter.  If I correctly recall from
the mists of time, we argued during rfc2543-bis whether proxies
should detect merged requests or not and reached the conclusion
that they should not.

- vijay

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 7 Sep 2005 23:13:45 +0200

Dale, Vijay,

Thanks for bringing this up. As I tried to sketch in a later email to the 
list, the proposal is now to send a completely new INVITE to fix a 
repairable error, independent of the original INVITE transaction / dialog. I 
believe that would be safest, I imagine that even though a UAS should not 
flag a 'fixed' (thus modified) INVITE request as a duplicate, if it has the 
same CSeq, from-tag and Call-ID (and no to-tag) I fear that many current UA 
will see it as duplicate anyway, in particular when they strictly follow 
RFC3261.

A potential issue is that this new INVITE will follow a different route (it 
won't go through the forking proxy again, unless the proxy record-routes), 
but I think the alternative (merging the new with the 'old' INVITE and 
trying to work around duplicate detection anomalies and other issues) is 
worse.

Would you agree?

Regards,

Jeroen

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 08 Sep 2005 16:52:42 -0500

Jeroen van Bemmel wrote:
> Dale, Vijay,
> 
> Thanks for bringing this up. As I tried to sketch in a later email to 
> the list, the proposal is now to send a completely new INVITE to fix a 
> repairable error, independent of the original INVITE transaction / 
> dialog. I believe that would be safest, I imagine that even though a UAS 
> should not flag a 'fixed' (thus modified) INVITE request as a duplicate, 
> if it has the same CSeq, from-tag and Call-ID (and no to-tag) I fear 
> that many current UA will see it as duplicate anyway, in particular when 
> they strictly follow RFC3261.

I don't see how for rfc3261 at least; the topmost via branch of the
fixed INVITE will be different than the original one.  Older user
agent servers (rfc2543 compliant) may detect this as a duplicate
(see Section 10.1.1 of rfc2543) since they only took in account
the Call-ID, To, From and CSeq.  Newer ones should not.

> A potential issue is that this new INVITE will follow a different route 
> (it won't go through the forking proxy again, unless the proxy 
> record-routes), but I think the alternative (merging the new with the 
> 'old' INVITE and trying to work around duplicate detection anomalies and 
> other issues) is worse.
> 
> Would you agree?

Yes, sending the new INVITE is a little better.  But all these
compromises and issues simply point to the basic fact that
fixing HERFP cleanly is non-trivial.

With your updated proposal, the call flow is now:

UAC        Proxy
INV--->
...
        <---FIX
200 OK FIX--->

INV------------------> To the real UAS
...

The call flow for Rohan's I-D is:

UAC        Proxy
INV--->
...
        <---130
PRA--->          ----\ PRACKs are optional
        <---200 OK ---/
INV--->
...

Both will get the job done.  I think some more discussion needs
to be done in the WG to list out the pros and cons of each
to reach an optimal solution by fine-tuning them.

- vijay

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 9 Sep 2005 00:09:16 +0200

Vijay,

>> if it has the same CSeq, from-tag and Call-ID (and no to-tag) I fear that 
>> many current UA will see it as duplicate anyway, in particular when they 
>> strictly follow RFC3261.
>

Sorry, my mistake, the correct term is "merged request", not duplicate. I 
was talking about section 8.2.2.2 in RFC3261, which says a UAS should 
generate a '482 loop detected' in such a case. The assumption is that the 
same request arrived via different paths (hence different top Vias), due to 
forking, which is not correct here

> INV------------------> To the real UAS

Right, with both the FIX and the fixed INVITE possibly passing through other 
proxies that record-routed the original INVITE or the FIX respectively. 
"real UAS" can also be a proxy, and "proxy" could be a UAS too, but the 
above is the typical case

> to reach an optimal solution by fine-tuning them.

Any and all suggestions are most welcome. I put the latest version here: 
http://home.versatel.nl/jbemmel/draft-jbemmel-herfp-solution-01.txt

Regards,

jeroen