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

[Cuda Alberto <Alberto.Cuda at TILAB.COM>]

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

_______________________________________________
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