Subject: RE: [Sipping] Service Identification: mid-dialog 3xx

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 1 Mar 2007 12:47:05 +0100

Hi,

Based on the mid-dialog 3xx discussion, I have collected a couple of
issues (they may also be valid for the REFER solution proposed by Dale):

1. Who sends 3xx?

The entity which sends 3xx must know that the application server(s) in
the current dialog path cannot handle the new media (or whatever the
user wants to "add" to the dialog).

So, the 3xx could be sent by some of the applicaton server, or by some
entity which has knowledge that new application servers are needed. As
seen in the second bullet, in some cases that may mean that the entity
sending the 3xx also needs to have knowledge about the new application
server. 

2. What Contact in the 3xx?

If a service URN based mechanism is used (see Jonathan's draft), on
issue is how the UA is going to build the Request-URI and Route
header(s) based on the 3xx, e.g. IF a service URN is used. This is of
course related to the fact that the usage of mid-dialog 3xx is not
specified.

And, if the 3xx Contact would contain a service URN, the one sending the
3xx would of course need to have knowledge about that URN value. So, if
the AS sends the 3xx, does it mean that the AS would need to know the
capabilities of other ASs?

If a service URN is NOT used, and routing to the AS is done using other
mechanisms, I guess the 3xx Contact could contain the same value as in
the initial INVITE (the Request-URI and Route headers of the new INVITE
should be identical to the old one), and the network will then make sure
(as for any initial INVITE) that the new INVITE is routed to the correct
application server. In this case the one sending the 3xx does not need
to have knowledge about where the new INVITE will be routed.

Regards,

Christer

_______________________________________________
Sipping mailing list  https://www1.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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 1 Mar 2007 15:37:36 +0100

Hi,

I a few issues regarding the mid-dialog 3xx, together with GRUU and
Replaces.

As Jonathan indicated earlier, the solution would require support of
both GRUU and Replaces.

I still would like to consider cases where GRUU and/or Replaces are not
used, and where the new INVITE may reach a new remote UA.

First, assume that the originating UA sends a re-INVITE with some new
media, and some entity in the network returns a mid-dialog 3xx response,
because a new application server must be added to the dialog. The entity
sending the 3xx has no clue whether the terminating UA supports the new
media type or not.

Second, if GRUU is used, the new INVITE will reach the old terminating
UA. Now, if the terminating UA does not support the new media, it will
most likely put the port value to zero in the SDP answer. So, the adding
of the new media fails, and the new AS has been inserted without any
reason.

However, if GRUU is NOT used, the new INVITE may reach a different
terminating UA, which does support the media. In this case the
originating would have to terminate the old dialog by sending BYE, since
the new terminating UA has no knowledge about it. Jonathan said that
this case should be solved using transfer, but I am not sure how it
would work. Who would initiate the transfer?

Third, if Replaces is used, and the new INVITE reaches the old
terminating UA, everything should work fine.

However, if GRUU is NOT used, the new INVITE may again reach a different
terminating UA. I don't have the replaces spec in front of me, but maybe
it could accept the INVITE and indicate to the originating UA that it
had no knowledge about the dialog to be replaced. Also in this case the
originating UE could terminate the old dialog by sending BYE.

Fourth, if GRUU is used, but Replaces is NOT used, I guess the
terminating UA would either return busy to the new INVITE, or accept the
new INVITE (if it can handle multiple sessions simultanously).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2007 10:03:43 -0500

inline.

	Paul

> sending the 3xx also needs to have knowledge about the new application

Note: it could be that the reinvite is *removing* some aspect of the 
session, and the server might do a 3xx in order to get *out* of the 
call. (E.g. changing from PoC to regular voice.)

> course related to the fact that the usage of mid-dialog 3xx is not

I think the assumption here is that the existing UAC is to stay in the 
call. Assuming all the servers in the call are proxies, then if the 3xx 
is 300...302, the Contact in it must identify the UAS, or at least the 
AOR of the UAS.

To fit a service URN into this, I think you must either use 305, or else 
include the service URN as a Route header parameter (?Route=) on the 
Contact URI. Both of these are rather blunt instruments. I find it 
unlikely that either could plausibly be used to get the right result.

(Note that it gets more complicated if one or more servers in the path 
are B2BUAs, because in that case there are a sequence of two or more 
connected dialogs, each with their own Contact addresses. Whichever 
element sends the 3xx will presumably choose the Contact that is present 
in the dialog it is observing. This could get very messy, but it is a 
problem to be solved by those that put B2BUAs into this picture.)

> capabilities of other ASs?

Yeah. I think the above just doesn't work. The following makes more sense.

> the initial INVITE (the Request-URI

Well - the GRUU that is the contact for the dialog seems to be the 
correct choice here.

> and Route headers of the new INVITE
> should be identical to the old one),

Its an out of dialog request, so it should start out with whatever Route 
headers are normally used for a new call - not the ones in use for the 
current call, that were discovered as a result of Record-Route.

> and the network will then make sure
> application server.

Using a GRUU will cause routing back to the recipients home proxy, and 
from there eventually to the proper UAS. Whatever logic chooses 
application servers to include in the call can work on this request as well.

> In this case the one sending the 3xx does not need

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2007 10:31:24 -0500

> of the new media fails, and the new AS has been inserted without any

That is kind of annoying. It could potentially be solved by having the 
UAS simply refuse the new invite. It might do so because it already has 
a good call with the same media that will be used in the new call. But 
because there are multiple reasons for INVITE/Replaces it is pretty much 
impossible for the UAS to know this is a good thing to do.

This might be solved using some of the new media capability stuff that 
is being worked on - so that the UAC can know in advance whether the UAS 
supports the changes that it is going to request.

This subject could stand further consideration.

> the new terminating UA has no knowledge about it.

IMO this behavior would be a *bug*, not a feature. If I am in a call 
with you, and I attempt to add video, I will be very surprised if I end 
up talking to your wife.

> Jonathan said that

Continuing the above scenario...

If I tried adding video, and your phone doesn't support video, then my 
attempt will fail. So then I ask you if you can get on a video phone so 
we can see each other. You then initiate a transfer of me to your video 
phone. At the time of the transfer, video may get included automatically 
(because you have it enabled on your phone), or not. If not, then after 
the transfer either end can attempt to add video, and it should succeed.

> originating UE could terminate the old dialog by sending BYE.

Replaces is supposed to fail if you don't have the corresponding dialog. 
Lots of useful call flows (including important fallbacks when gruu isn't 
available) depend on this, so you don't want to change it.

> new INVITE (if it can handle multiple sessions simultanously).

Yes, it could always be treated as a new call. (E.g. to a 2nd line, or 
call waiting.) But the user experience would be bad.

(All this just so that application servers can insinuate themselves into 
places they don't belong.)

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 1 Mar 2007 18:16:45 +0100

Hi, 

>Note: it could be that the reinvite is *removing* some aspect of the
session, and the server might do a 3xx in order to 
>get *out* of the call. (E.g. changing from PoC to regular voice.)

Yes. Whatever requires a change of application server (change of dialog
path).

(Then it is of course a question whether you can use the same SIP
application for PoC and regular voice, but that's a separate issue.)

>>header(s) based on the 3xx, e.g. IF a service URN is used. 
>>This is of course related to the fact that the usage of mid-dialog 3xx
is not 
>>specified.
> 
>I think the assumption here is that the existing UAC is to 
>stay in the call. Assuming all the servers in the call are 
>proxies, then if the 3xx is 300...302, the Contact in it must 
>identify the UAS, or at least the AOR of the UAS.

Yes, since the R-URI is taken from the 3xx Contact.

>To fit a service URN into this, I think you must either use 
>305, or else include the service URN as a Route header 
>parameter (?Route=) on the Contact URI. Both of these are 
>rather blunt instruments. I find it unlikely that either 
>could plausibly be used to get the right result.

I agree.

>(Note that it gets more complicated if one or more servers in 
>the path are B2BUAs, because in that case there are a 
>sequence of two or more connected dialogs, each with their 
>own Contact addresses. Whichever element sends the 3xx will 
>presumably choose the Contact that is present in the dialog 
>it is observing. This could get very messy, but it is a 

I guess it would be good to be able to send a 3xx without a Contact URI
- simply to trigger a new initial INVITE.

Of course, there is always a chance that the entity, instead of sending
3xx, rejects the re-INVITE. For example, an application server which
realizes it can't handle the new media offered in the re-INVITE could do
that...
 
>>And, if the 3xx Contact would contain a service URN, the one sending
the 3xx would of course need to have knowledge 
>>about that URN value. 
>>So, if the AS sends the 3xx, does it mean that the AS would need to
know the capabilities of other ASs?
>>If a service URN is NOT used, and routing to the AS is done using
other mechanisms, I guess the 3xx Contact could 
>>contain the same value as in the initial INVITE (the Request-URI
> 
correct choice here.
> 
>>and Route headers of the new INVITE should be identical to the old
one),
> 
>Its an out of dialog request, so it should start out with 
>whatever Route headers are normally used for a new call - not 
>the ones in use for the current call, that were discovered as 
>a result of Record-Route.

Exactly.

>>and the network will then make sure (as for any initial INVITE) that
the new INVITE is routed to the 
>>correct application server.
>Using a GRUU will cause routing back to the recipients home 
>proxy, and from there eventually to the proper UAS. Whatever 
>logic chooses application servers to include in the call can 
>work on this request as well.

Yes, for example a scenario where the network routes the INVITE to an AS
based on Require, Accept-Contact and/or the SDP.

Regards,

Christer