Christer Holmberg wrote:
Hi,
Based on the discussions in Dublin, it was agreed to move forward with
199 based on the following assumptions:
- We will not define an option-tag for 199 support.
- We will remove any text talking about adding a sipfrag body into the
199 response (potential future usage of 199 e.g. to solve HERFP would
define such procedures)
- A UAS IS allowed to send 199 (see more in the remaining open issues
section further down).
Please let me know if you have strong objections to any of these.
OPEN ISSUES, which we need to solve are:
1) Is a proxy allowed to send 199 in the first place, or are only UASes
allowed to do it?
2) Assuming proxies are allowed to send 199 (see issue 1), are proxies
allowed to send 199 reliably? It would mean that they need to terminate
the associated PRACK, which is claimed to not be normal proxy behavior.
3) Assuming proxies are allowed to send 199 (see issue 1), are proxies
allowed to send 199 unreliably, even if 100rel is required?
Claims for:
- Since 199 is only an indciation, it can be seen as something similar
to 100 Trying, which is never sent reliably
- Proxies are not affected by the Require header, so even if the
request contains 'Require: 100rel' it does not affect proxies
Claims against:
- It is not normal proxy behvior to trigger and send a non-100 response
in the first place.
4) Is it a MAY/RECOMMENDATION/SHOULD/MUST for UAS to send 199?
IMO it is generally undesirable for the UAS to send the 199.
The whole point of the 199 is to serve as an optimization. In the
absence of forking it is typically redundant, and will increase the
amount of signaling in common cases, and so is counter productive. (My
guess is that some large fraction, maybe more than half, of all calls
are not answered by the intended target.)
It is typically a proxy, or another middle box such as a B2BUA, that is
aware that forking is going on, and thus that there is state the UAC
might want to know that won't otherwise be available to it. So I think
the box that knows this should be the one to send the response.
I don't want to *ban* the UAS from sending the response, because it
might be a middle box, and because even if it is the ultimate endpoint
it *might* know the outcome of the call before it can finally send it.
Regarding *reliable* 199:
*If* the 199 is to be sent by a middle box, rather than by the UAS whose
final response is being anticipated by the 199, then the main issue is
what to-tag is to be used for the 199. The current proposal requires
that the to-tag match that of the final response from the UAS. Things
get very messy if the 199 is sent reliably under those conditions:
- the resulting PRACK will be sent in-dialog and thus will consume
a CSeq value.
- the PRACK will need to be intercepted and handled by the middle box,
rather than being allowed to follow its normal routing. (The UAS
doesn't know the 199 was sent, and so won't expect a PRACK for it.)
- Potentially the middle box won't even be on the routing path for the
PRACK, and so won't see it.
The bottom line for the above is that sending the 199 reliably using the
to-tag of the UAS is a *terrible* ideal. A slightly less bad alternative
would be to send the 199 with a to-tag belonging to the middle box
sending it. But this just complicates things further:
- this new to-tag will create yet another early dialog.
- The 199 response will thus have to terminate both this new one,
and the original one.
- There will have to be some new header to indicate which early dialog
is to be terminated. (In addition to the one created by the to-tag
of the 199 itself.)
So that seems like a bad idea too.
In any case, the 199 is just an optimization. The world will not end if
it is not received. So an unreliable 199 seems to fit the bill just
fine. So, I think the 199 should normally be sent unreliably. It could
be sent reliably in those cases where it is being sent by the UAS
possessing the to-tag of the dialog it pertains to. (Even when it *can*
be sent reliably it is probably a bad idea to do so. It increases the
required signaling, perhaps outweighing the value of this optimization.)
This does mean that some rules need to be relaxed so that it is
permissible to send this unreliably even when Require:100rel has been
specified by the UAC. (Perhaps what we ought to do in this regard is say
that that reliable provisionals are only required when there is
something essential in the message, such as an offer, answer, or target
change.)
Perhaps instead of 199, this should be the 101 response, so that it
appears closer to the 100 response that already gets special treatment.
Thanks,
Paul
Please give your opinions :)
Regards,
Christer
-
------------------------------------------------------------------------
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
