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.
>> + 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
Right.
>> + 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.
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'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?
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 constructed
>for one-time usage.
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.
>> + 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?
Yes, I agree it should work.
Cheers.
Alberto.
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
====================================================================