There are unresolved issues here. It is indeed the case that there are
important call flows, for common features, that won't work right if a
reinvite doesn't complete right away. And yet there are cases where it
seems useful for the reinvite to delay while it alerts again.
My preference would be to require reinvite to complete immediately, and
for UAs to do all the time consuming stuff when there isn't a
transaction depending on it.
For instance, in the case Dale describes, when the reinvite comes in
offering to add video, the UAS could accept it, but with recvonly or
inactive status, assuming it is even capable of doing video. Then it
could alert its user, and if that succeeds, it could reinvite again,
offering sendrecv on the video.
Having said that, I don't think that says anything about 100rel on
reinvite. There are still uses for it, in particular for preconditions.
If you want to add video to your call, and you want QoS with that video,
then you use the 100rel to negotiate the preconditions.
Paul
[EMAIL PROTECTED] wrote:
> From: "Sarkar, Uttam" <[EMAIL PROTECTED]>
>
> 100rel does not make sense in re-INVITE as session is already
> established. UAS is expected to send final response (2XX/4XX/5XX etc ).
> It can send 100 trying to stop retransmission of INVITE while it's
> preparing the final response.
> It's not recommended for UAS to send 1XX response for the re-INVITE.
>
> One can imagine scenarios where a re-INVITE might not be
> instantaneous, and so 100rel might be a useful mechanism. For
> instance, if one endpoint wishes to upgrade an audio call to an
> audio-and-video call, the other endpoint might want to ask its user
> before activating the video camera.
>
> Dale
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
