|
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: 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.txtBest
regards, Jeroen van
Bemmel ________________________________ _______________________________________________ Sipping
mailing list https://www1.ietf.org/mailman/listinfo/sippingThis 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 ====================================================================
|