[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] New I-D: A solution for the HERFP caused by forkedSIPINVITE requests
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: sipping-bounces at ietf.org 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:jbemmel at zonnet.nl>
To: sipping <mailto:sipping at ietf.org>
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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
MailAdmin at tilab.com. Thank you
====================================================================
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP