[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Redirect Servers and SDP offer/answer for early media: draft-ietf-sipping-sip-offeranswer-07
Chaney, Charles (NSN - US/Boca Raton) wrote:
> Hello,
>
> This question is in regards to redirect servers and its application to
> the SDP offer/answer model, but applies possibly to other scenarios as
> well. The material seems to be applicable to
> draft-ietf-sipping-sip-offeranswer-07. There are a few related questions
> within the text below to help come to a conclusion - I hope.
>
> The basic underlying question is in regards to redirect servers; are
> they allowed to redirect a UAC once a dialog has been established? I
> believe its allowed but need some reassurance.
There are two very different situations that loosely fit this description:
- a 3xx response to an initial INVITE.
This is the case you seem to be asking about.
- a 3xx response to a request sent within an existing dialog.
In theory this seems to be legal. But its actual meaning and
implications have not, AFAIK, ever been explored. I don't want
to even attempt to discuss that here.
> For example, an Application Server may provide a reliable/unreliable 18x
> response containing an SDP answer. Once a dialog is established, is the
> AS allowed to invoke redirection procedures (3xx) for the INVITE (no
> To-tag) or INVITE early dialog (To-tag) to redirect the UAC to a new
> contact address?
I believe a to-tag is appropriate always, and is only optional for 2543
compatibility. The to-tag may identify an early dialog that has been
announced earlier via an 1xx, or it may be a new one.
> If the behavior is allowed, does the UAC's new INVITE imply it is
> discontinuing any previous INVITE established dialogs or is it
> continuing them, possibly adding new ones due to new contact responses?
The 3xx is a non-2xx class final response to the initial INVITE. As such
there will be no other non-2xx final responses. There *could* still be a
2xx final response, though this should only occur in unusual race
conditions.
I guess the 2xx could be for an established early dialog. Again a weird
case.
> RFC3261 8.1.3 recommends reusing the existing dialog identifiers of the
> original INVITE request, so this seems to imply new dialogs may be
> added, however on the other hand, it also indicates the UAC may choose
> to update the Call-ID, which seems to imply new dialogs may be
> established. In the later behavior, what should happen to the previously
> established dialogs?
This is more or less the same as when you get a 2xx response on one
dialog but have other early dialogs. They eventually time out. Or they
*could* return a 2xx. If so then they become active to you until you
terminate them.
> If the above interpretations are correct, when the UAC sends the new
> INVITE request, the SIP UAC may receive new dialog establishing
> response(s) from the new contact address each having their own SDP
> offer/answer. How the dialogs are processed depends on the UAC's
> behavior and its application of the "recommended", or "may" statements
> above.
Not particularly different than when a downstream proxy does the forking
on the 3xx. Again the UAC may see multiple dialogs that it must manage
somehow - perhaps by terminating them. Or it may decide to keep them
all. (E.g. if it is a conference focus.)
> Additionally section 8.1.3 states that UAC should re-use bodies, e.g.
> SDP of the original request. If the UAC has used a different Call-ID and
> the SDP offer is the same it seems to imply the UAC is still able to
> process confirmations from any previous SDP's as stale and no longer
> desired. should be the same but does not totally exclude the SDP from
> being different.
I think you may do as you wish. I don't know the reason for the should
use the same body - using a different body should not cause any harm.
> All in all, this behavior seems to mimic what would happens in a forking
> Proxy scenario where multiple UAS contacts each establish an early
> dialog including an SDP answer. The UAC has to cope with the
> possibility of multiple SDP answers, one for each early dialog, with the
> possibility that any may possibly require early media or one become the
> dialog that is confirmed.
It is certainly easier to describe, and probably to implement, if you
treat it the same way.
> In the case of early media, how is the UAC able to determine when to
> select the appropriate media stream for rendering to the user and
> responding toward the UAS? It seems that there is a need for coupling
> the SIP response to the early media authorization to give the UAC a
> hint, e.g., RFC5009 using P-Early-Media to authorize/remove early media?
> Is there any other solution, since this seems to be targeted for 3GPP?
This is an ugly problem. It has been discussed from time to time, but
AFAIK no standard approach has ever been agreed to. With a forking proxy
in the path there isn't sufficient info for the UAC to correlate the
incoming media to a particular dialog.
When the UAC is doing the forking itself there is some merit in using
different media addresses and/or ports and/or payload types in order to
correlate the media to the signaling. I believe Rohan once proposed
using a 2nd o/a in the early dialog to put different dialogs on unique
ports for that purpose.
> Are there other methods being considered as the UAC is being put into a
> situation of keep track of a number of unconfirmed dialogs with various
> media requirements, each having the potential to become the confirmed
> dialog. I recall some past activity to define a new 199 response to
> "remove" a dialog as no longer applicable. Has there been any further
> work in this area?
I'm not sure of the current status of the 199 proposal. Nor am I aware
of any other current work on this subject.
Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.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