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

From: "Chaney, Charles (NSN - US/Boca Raton)" <[email-masked]>
Date: Mon, 14 Apr 2008 11:31:40 -0600

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Apr 2008 14:57:14 -0400

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

> To-tag) or INVITE early dialog (To-tag) to redirect the UAC to a new

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.

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

> established. In the later behavior, what should happen to the previously

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.

> behavior and its application of the "recommended", or "may" statements

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.)

> desired. should be the same but does not totally exclude the SDP from

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.

> dialog that is confirmed.

It is certainly easier to describe, and probably to implement, if you 
treat it the same way.

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

> "remove" a dialog as no longer applicable. Has there been any further

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

---

From: [email-masked]
Date: Thu, 24 Apr 2008 18:15:36 -0400

From: "Chaney, Charles (NSN - US/Boca Raton)" <[email-masked]>

I've heard some discussion of this idea, but I've never heard of it
being used in practice.  The semantics would be quite difficult to
define cleanly.

On the other hand, one UA in a dialog can send a REFER to the other,
which has an effect that is quite similar to what one would expect an
in-dialog 3xx to have.

Dale