[Sipping] Redirect Servers and SDP offer/answer for early media: draft-ietf-sipping-sip-offeranswer-07

["Chaney, Charles (NSN - US/Boca Raton)" <charles.chaney at nsn.com>]

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.

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? 

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

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.

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. 

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.

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?

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?


Thanks in advance for your response,

Chuck Chaney
_______________________________________________
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