Subject: [Sipping] Service Identification: offerless INVITE case

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 11:16:25 -0500

Andrew made a great point in one of his mails which merits promotion 
into its own thread.

I and others have asserted that you should be able to identify the 
service by things naturally in the request, and in particular, SDP has 
come up as a key thing. For example, in a multiplayer game, there might 
be an m-line for the particular proprietary protocol used for game 
moves. Or, if its MSRP, you might have specific content types for game 
moves. When present, those exactly indicate what the service is.

But what do we do about offerless INVITE? In particular, there are cases 
where we need to invoke an application server to handle a request, and 
what if we don't have the SDP in the INVITE? Its too late to insert an 
application server once the INVITE has already passed to the called 
party and the 200 OK is sent.

This is a great point. I'd rather just fix this little problem, the 
define an entire notion of services and service identifiers that are not 
necessary, just because we have offerless INVITEs.

There are lots of ways to handle this problem. My preferred approach 
would be that offerless INVITE contain a capability description, using 
Flemmings new capability framework. The INVITE would contain a body that 
  looks like SDP, but has a different content type and 
content-disposition. It lists the media streams, codecs and other 
capabilities that exist. Based on this, the called party makes the offer 
in a 2xx or 18x like normal, and the answer in the ACK/PRACK as normal. 
It is completely backwards compatible.

Now, a related issue is what happens if a session starts with audio 
only, and then the user wants to turn this into a game? Its too late to 
add new application servers into the call path, which might need to be 
there for games. What can we do?

Here too, there is a simple answer. If a network provider requires app 
servers to get inserted, or a phone requires dispatch to a different 
application, it would receive a re-INVITE to add the gaming stream, and 
then 3xx it. The Contact would contain an embedded Replaces header with 
the dialog IDs for the call in progress. THe originating UA would then 
do a totally new INVITE that replaces the call in progress. This would 
allow the network and/or phone to redispatch, yet provide a seamless 
user experience. Billing can be done however the operators want, since 
the signaling is very clear on exactly what happened and when. 
Furthermore, the replaces mechansim would only get used if there was 
someone in the call path that needed to see it.

I'd rather specify things like this, than invent an entire services 
framework that would lead to balkanization and non-interoperable islands 
of SIP.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Feb 2007 12:19:15 -0500

I too was thinking that INVITE/Replaces would be the way to get a new 
dialog that could include app servers not in the existing call, when 
that is needed. But I hadn't worked out how to know to do that. The 3xx 
does seem like a good way to handle that. The use of 3xx as a response 
to an in-dialog request is not at all well specified. But this could be 
a good motivation to clear that up.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 26 Feb 2007 19:05:34 +0100

Hi, 

>I too was thinking that INVITE/Replaces would be the way to 
>get a new dialog that could include app servers not in the 
>existing call, when that is needed. But I hadn't worked out 
>how to know to do that. The 3xx does seem like a good way to 
>handle that. The use of 3xx as a response to an in-dialog 
>request is not at all well specified. But this could be a 
>good motivation to clear that up.

I agree that the re-INVITE 3xx response would require some thinking.

For example, an initial INVITE 3xx response may not traverse all the way
back to the UA. But, I guess a re-INVITE 3xx would have to be sent all
the way back to the UA, since the UA would create a new dialog.

The question is also what happens to the original dialog. Does the UA
have to send BYE on the original dialog, or is it terminated
"automatically"?

If terminated automatically, what happens to the nodes situated AFTER
the proxy that sent 3xx? They have no clue about the 3xx being sent, and
there is no guarantee the re-INVITE will traverse the same nodes (or
even reach the same remote UA).

Etc etc etc.

Regards,

Christer

> > come up as a key thing. For example, in a multiplayer game, there 
> > might be an m-line for the particular proprietary protocol used for 
> > game moves. Or, if its MSRP, you might have specific 
> content types for 
> > game moves. When present, those exactly indicate what the 
> service is.
> > 
> > But what do we do about offerless INVITE? In particular, there are 
> > cases where we need to invoke an application server to handle a 
> > request, and what if we don't have the SDP in the INVITE? 
> Its too late 
> > to insert an application server once the INVITE has already 
> passed to 
> > the called party and the 200 OK is sent.
> > 
> > define an entire notion of services and service identifiers 
> that are 
> > not necessary, just because we have offerless INVITEs.
> > 
> > Flemmings new capability framework. The INVITE would contain a body 
> > that  looks like SDP, but has a different content type and 
> > capabilities that exist. Based on this, the called party makes the 
> > offer in a 2xx or 18x like normal, and the answer in the 
> ACK/PRACK as normal.
> > only, and then the user wants to turn this into a game? Its 
> too late 
> > to add new application servers into the call path, which 
> might need to 
> > be there for games. What can we do?
> > 
> > application, it would receive a re-INVITE to add the gaming stream, 
> > and then 3xx it. The Contact would contain an embedded 
> Replaces header 
> > with the dialog IDs for the call in progress. THe 
> originating UA would 
> > then do a totally new INVITE that replaces the call in 
> progress. This 
> > would allow the network and/or phone to redispatch, yet provide a 
> > seamless user experience. Billing can be done however the operators 
> > want, since the signaling is very clear on exactly what 
> happened and when.
> > framework that would lead to balkanization and non-interoperable 
> > islands of SIP.
> > 
> > -Jonathan R.
> > 
> > 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Feb 2007 13:18:15 -0500

> the way back to the UA, since the UA would create a new dialog.

Needs clarification, but yes that seems to be a corollary.

> have to send BYE on the original dialog, or is it terminated

If the invite is sent w/Replaces, then presumably the receiving end will 
send a BYE on the replaced dialog.

> even reach the same remote UA).

This is a general issue for INVITE/Replaces. The 3xx is simply a way to 
get the UAC to do it. The UAC could decide to do it even without a 3xx. 
In the normal course of routing this any servers that are needed on the 
path will have to be discovered based on the content of the request.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 26 Feb 2007 19:28:10 +0100

Hi, 

>>the proxy that sent 3xx? They have no clue about the 3xx being sent, 
>>and there is no guarantee the re-INVITE will traverse the same nodes 
>>(or even reach the same remote UA).
> 
>This is a general issue for INVITE/Replaces. The 3xx is 
>simply a way to get the UAC to do it. The UAC could decide to 
>do it even without a 3xx. 
>In the normal course of routing this any servers that are 
>needed on the path will have to be discovered based on the 
>content of the request.

My issue was how the proxies in the original dialog will know that a 3xx
has been sent (see picture):

UA A ------------------- Proxy 1 ---------------- Proxy 2
------------------ UA B     UA C

-------------INVITE---------> --------INVITE--------->
--------INVITE---------->
<------------200------------- <-------200-------------
<-------200--------------
-------------re-INVITE------>
<------------3xx-------------
-------------INVITE
(new)-------------------------------------------------------------->

Now, if Proxy 2 will not be traversed by the new INVITE, it will not
know that the dialog has been replaced.

And, if the new INVITE reaches UA C, UA B will have no clue that the
dialog has been replaced.

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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 14:15:00 -0500

I can't follow the figure since CRLFs got inserted by mailers along the 
way. Can you send one whose width is small?

I don't follow the problem though. The 3xx response would be seen by all 
record-routing proxies upstream of the entity that sends the mid-dialog 
3xx. The new INVITE would be seen by all proxies. To make sure it goes 
to the right UA instance you use GRUU. BYE is sent by the entity 
receiving the replaces, as normal. What am I missing?

-Jonathan R.

Christer Holmberg (JO/LMF) wrote:

>>>>>Andrew made a great point in one of his mails which merits
>>>>
>>>>promotion
>>>>
>>>>>into its own thread.
>>>>>
>>>>>I and others have asserted that you should be able to 
>>
>>identify the 
>>
>>>>>service by things naturally in the request, and in
>>>>
>>>>particular, SDP has
>>>>
>>>>>might be an m-line for the particular proprietary 
>>
>>protocol used for 
>>
>>>>>But what do we do about offerless INVITE? In particular, 
>>
>>there are 
>>
>>>>>This is a great point. I'd rather just fix this little 
>>
>>problem, the 
>>
>>>>>There are lots of ways to handle this problem. My preferred
>>>>
>>>>approach
>>>>
>>>>>would be that offerless INVITE contain a capability
>>>>
>>>>description, using
>>>>
>>>>>Flemmings new capability framework. The INVITE would 
>>
>>contain a body 
>>
>>>>>capabilities that exist. Based on this, the called party 
>>
>>makes the 
>>
>>>>>Now, a related issue is what happens if a session starts 
>>
>>with audio 
>>
>>>>>Here too, there is a simple answer. If a network provider
>>>>
>>>>requires app
>>>>
>>>>>servers to get inserted, or a phone requires dispatch to a
>>>>
>>>>different
>>>>
>>>>>application, it would receive a re-INVITE to add the 
>>
>>gaming stream, 
>>
>>>>>seamless user experience. Billing can be done however the 
>>
>>operators 
>>
>>>>>Furthermore, the replaces mechansim would only get used if
>>>>
>>>>there was
>>>>
>>>>>I'd rather specify things like this, than invent an 
>>
>>entire services 
>>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 26 Feb 2007 15:08:17 -0500

Is it not possible that in some cases SDP could also be encrypted?

Mike

> -----Original Message-----
> From: Jonathan Rosenberg (jdrosen) 
> Sent: Monday, February 26, 2007 11:16 AM
> To: IETF Sipping List
> Subject: [Sipping] Service Identification: offerless INVITE case
> 
> promotion into its own thread.
> 
> identify the service by things naturally in the request, and 
> in particular, SDP has come up as a key thing. For example, 
> in a multiplayer game, there might be an m-line for the 
> particular proprietary protocol used for game moves. Or, if 
> its MSRP, you might have specific content types for game 
> there are cases where we need to invoke an application server 
> to handle a request, and what if we don't have the SDP in the 
> INVITE? Its too late to insert an application server once the 
> INVITE has already passed to the called party and the 200 OK is sent.
> 
> problem, the define an entire notion of services and service 
> identifiers that are not necessary, just because we have 
> offerless INVITEs.
> 
> approach would be that offerless INVITE contain a capability 
> description, using Flemmings new capability framework. The 
> INVITE would contain a body that
> content-disposition. It lists the media streams, codecs and 
> other capabilities that exist. Based on this, the called 
> party makes the offer in a 2xx or 18x like normal, and the 
> answer in the ACK/PRACK as normal. 
> Now, a related issue is what happens if a session starts with 
> audio only, and then the user wants to turn this into a game? 
> Its too late to add new application servers into the call 
> path, which might need to be there for games. What can we do?
> 
> requires app servers to get inserted, or a phone requires 
> dispatch to a different application, it would receive a 
> re-INVITE to add the gaming stream, and then 3xx it. The 
> Contact would contain an embedded Replaces header with the 
> dialog IDs for the call in progress. THe originating UA would 
> progress. This would allow the network and/or phone to 
> redispatch, yet provide a seamless user experience. Billing 
> can be done however the operators want, since the signaling 
> is very clear on exactly what happened and when. 
> there was someone in the call path that needed to see it.
> 
> I'd rather specify things like this, than invent an entire 
> services framework that would lead to balkanization and 
> non-interoperable islands of SIP.
> 
> -Jonathan R.
> 
> 
> --

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 26 Feb 2007 22:13:28 +0100

Hi, 

>I can't follow the figure since CRLFs got inserted by mailers 
>along the way. Can you send one whose width is small?

I'll try again :)

UAa    P1    P2    UAb   UAc
 -INV-> -INV-> -INV->
 <-200- <-200- <-200-
 -INV->
 <-3xx-
 -INV--------------------->

>I don't follow the problem though. The 3xx response would be 
>seen by all record-routing proxies upstream of the entity 
>that sends the mid-dialog 3xx.

Yes, but what about all record-routing proxies downstream?

>The new INVITE would be seen by all proxies.

Assuming the new INVITE traverses the same set of proxies (if
Service-Route is used, that set of proxies will be the same), yes, but I
don't think we can assume that.

>To make sure it goes to the right UA instance you use GRUU. 
>
>BYE is sent by the entity receiving the replaces, as normal. What am I
missing?

What if the new UA is NOT the same as the original? What if the original
UA doesn't support the new capability/media being added in the
re-INVITE, and is routed to another UA? Shall such scenario not be
allowed?

Regards,

Christer

> simply a way 
> >>to get the UAC to do it. The UAC could decide to do it even 
> without a 
> >>3xx.
> >>In the normal course of routing this any servers that are needed on 
> >>the path will have to be discovered based on the content of the 
> >>request.
> > 
> > 
> > My issue was how the proxies in the original dialog will 
> know that a 
> > 3xx has been sent (see picture):
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 17:35:19 -0500

inline.

>>along the way. Can you send one whose width is small?

They won't see the 3xx, but they'll see the BYE. Thats enough.

> don't think we can assume that.

Not clear they really need to.

> re-INVITE, and is routed to another UA? Shall such scenario not be

I think you'd need to do that as a transfer.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 17:36:54 -0500

Well, that depends on whether you think we'll ever see S/MIME or not. If 
it ever happens, the problem is easily remedied by including select 
portions of the actual SDP in the body. But its a problem in theory 
right now, like it or not.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Feb 2007 18:20:59 -0500

> has been sent (see picture):

There should be no reason for any of the proxies to take note of the 
3xx. It is simply a way to tell the UAC to do an INVITE/Replaces. It 
could decide to do an INVITE/Replaces without receiving a 3xx, so 
anything that depends on seeing the 3xx is broken.

The new invite will need be routed to application servers in whatever 
way is appropriate for it, independent of what application servers had 
been involved in the old session. If the new invite simply adds on 
additional features to what was used before, then presumably any app 
servers needed before will be included again, and any new servers needed 
because of additions to the invite will be included as well.

If some server that had been included is no longer included on the new 
invite, then it will drop out when the BYE is sent on the old session.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Feb 2007 18:22:48 -0500

> Is it not possible that in some cases SDP could also be encrypted?

If it is, then we start to get into the subject of e2m policy. But I 
think IMS already assumes the SDP is not encrypted, so its not a problem 
for them.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 27 Feb 2007 06:54:18 +0100

Hi,

Assuming the new UA (UA_C) is the same as the original (UA_B), I agree
there should be no problem as far as the BYE is concerned.

It is important to note, however, that this solution requires the
support of both GRUU and Replaces by all UAs involved.

One question is whether a proxy can send the mid-dialog 3xx, or if it
some B2BUA behavior is required. 

For example, there is always a chance that the remote UA (UA_B) is
sending a new offer at the same time, which may reach UA_A before the
3xx. The proxy that sent 3xx most likely doesn't have to care about this
(UA_A should handle it, and return 491), but it's just something we
would need to be aware of since the offer/3xx will not be end-to-end in
this case.

And, of course the scenario where the new INVITE is rejected (or not
even sent) - for whatever reason - be supported, and the old dialog

Another problem may be that UA_A is required (until it receives BYE on
the original dialog) to maintain resources (including codecs) for TWO
dialogs - the original dialog, and the new - which may cause problems in
some cases. From a codec perspective that could be solved by putting the
original dialog on hold (by sending a hold re-INVITE, without the new
capabilities/medias) before sending the new invite.

Regards,

Christer

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 27. helmikuuta 2007 1:21
> To: Christer Holmberg (JO/LMF)
> Cc: Jonathan Rosenberg; IETF Sipping List
> Subject: Re: [Sipping] Service Identification: offerless INVITE case
> 
> 
> 
> >>> If terminated automatically, what happens to the nodes situated 
> >>> AFTER the proxy that sent 3xx? They have no clue about 
> the 3xx being 
> >>> sent, and there is no guarantee the re-INVITE will 
> traverse the same 
> >>> nodes (or even reach the same remote UA).
> >> to get the UAC to do it. The UAC could decide to do it 
> even without a 
> >> 3xx.
> needed on 
> There should be no reason for any of the proxies to take note 
> of the 3xx. It is simply a way to tell the UAC to do an 
> INVITE/Replaces. It could decide to do an INVITE/Replaces 
> without receiving a 3xx, so anything that depends on seeing 
> the 3xx is broken.
> 
> The new invite will need be routed to application servers in 
> whatever way is appropriate for it, independent of what 
> application servers had been involved in the old session. If 
> the new invite simply adds on additional features to what was 
> used before, then presumably any app servers needed before 
> will be included again, and any new servers needed because of 
> additions to the invite will be included as well.
> 
> If some server that had been included is no longer included 
> on the new invite, then it will drop out when the BYE is sent 
> on the old session.
> 
> 	Paul
>

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Tue, 27 Feb 2007 07:18:29 +0100

Hi,

On this topic, doesn't this rely on the session-id making it to the Peer
UA, in my understanding there are a number of entities along the way
that may change the session id - any B2BUA such as an SBC .... (they may
be BAD BAD BAD, but they are THERE THERE THERE).

Steve.

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]

Sent: Monday, February 26, 2007 10:13 PM
To: Jonathan Rosenberg
Cc: Paul Kyzivat; IETF Sipping List
Subject: RE: [Sipping] Service Identification: offerless INVITE case

Hi, 

I'll try again :)

UAa    P1    P2    UAb   UAc
 -INV-> -INV-> -INV->
 <-200- <-200- <-200-
 -INV->
 <-3xx-

>I don't follow the problem though. The 3xx response would be seen by 
>all record-routing proxies upstream of the entity that sends the 
>mid-dialog 3xx.

missing?

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 27 Feb 2007 08:31:38 +0100

And, if you don't take Stephen's WORD WORD WORD for it, have a look at
the slides from the San Diego SPEERMINT session. There was one slide
with so many SBC boxes init that there was no room for anything else at
the slide... :)

Regards,

Christer 

> From: Stephen Terrill (MI/EEM) [mailto:[email-masked]] 
> Sent: 27. helmikuuta 2007 8:18
> To: IETF Sipping List
> On this topic, doesn't this rely on the session-id making it 
> to the Peer UA, in my understanding there are a number of 
> entities along the way that may change the session id - any 
> B2BUA such as an SBC .... (they may be BAD BAD BAD, but they 
> are THERE THERE THERE).
> 
> Steve.
> 
> Service-Route is used, that set of proxies will be the same), 
> yes, but I don't think we can assume that.
> 
> What if the new UA is NOT the same as the original? What if 
> the original UA doesn't support the new capability/media 
> being added in the re-INVITE, and is routed to another UA? 
> Shall such scenario not be allowed?
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> > 
> > -Jonathan R.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Feb 2007 09:03:21 -0500

> there should be no problem as far as the BYE is concerned.

If the new UA is *different* from the original UA then INVITE/Replaces 
will fail.

> support of both GRUU and Replaces by all UAs involved.

Yup.

Frankly, there are many features that require these things in order to 
work properly. Why do you suppose they have been worked on for so long?

> some B2BUA behavior is required. 

Yes, there may be some issue with that. It is of course legal for a 
proxy to send a 3xx for an out of dialog request. And there is no 
technical issue in doing so for an in dialog request. Its only a matter 
of whether it is legal.

I suppose one could make an argument that a 3xx should only be returned 
by something responsible for the domain of the R-URI. But I don't think 
there is currently any such restriction.

> would need to be aware of since the offer/3xx will not be end-to-end in

Again, I think this has nothing to do with the 3xx. It only has to do 
with the UAC and the INVITEs it sends. The 3xx just tells the UAC to do 
an INVITE/Replaces.

There is probably some behavior that has never been documented about 
what a UAC should do after it has decided (because of 3xx or whatever) 
that it wants to send an INVITE/Replaces to establish a new session 
replacing one it already has. After it has started down that path it may 
want to reject reinvites on the old session. But I think this is a 
second order issue.

> even sent) - for whatever reason - be supported, and the old dialog

Well, or course. There is nothing that requires the UAC to send a new 
invite upon receiving a 3xx to a reinvite. Just like any failed 
reinvite, it leaves the session as is. There is nothing new or 
surprising here.

> capabilities/medias) before sending the new invite.

This is just like using INVITE/Replaces for transfer. If there is need 
to put the session on hold first then of course that may be done.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Feb 2007 09:09:42 -0500

> be BAD BAD BAD, but they are THERE THERE THERE).

I presume you mean dialog-id.

One would hope that a B2BUA isn't trying to totally break SIP. 
INVITE/Replaces if fundamental to many features. If some middlebox is 
going to change the dialog-id for the dialog, then it has the 
responsibility to patch of the damage that causes. If it can't do that 
then it has no business being there.

This is analogous to a NAT that screws up address and port, and thus 
breaks things that reference those. We don't want to go down that path 
again.

Nor, IMO, do we want to reduce ourselves to features that can work in 
the presence of such damage.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Feb 2007 10:04:17 -0500

If they are present, they would need to properly support handling of 
Replaces, and patch up the dialog IDs that are in them. Whether they do 
that for Replaces embedded in 3xx Contacts, I don't know (probably not), 
but this is just a matter of making sure they do if you want to support 
those flows.

As Paul said, we should not stop using or specifying new SIP extensions 
because someone might have an SBC deployed that won't work with it. Its 
a consideration, of course, but this issue with SBCs is exactly why so 
many in the community have complained about them, and the burden falls 
on the deployers and implementors to get them upgraded to support the 
functions they need.

-Jonathan R.

Stephen Terrill (MI/EEM) wrote:

>>>>>If terminated automatically, what happens to the nodes
>>
>>situated AFTER
>>
>>>>>the proxy that sent 3xx? They have no clue about the 3xx
>>
>>being sent,
>>
>>>>>and there is no guarantee the re-INVITE will traverse the
>>
>>same nodes
>>
>>>Now, if Proxy 2 will not be traversed by the new INVITE, it
>>
>>will not
>>
>>>And, if the new INVITE reaches UA C, UA B will have no clue
>>
>>that the
>>
>>>>>>>come up as a key thing. For example, in a multiplayer
>>
>>game, there
>>
>>>>>>>content-disposition. It lists the media streams, codecs
>>
>>and other
>>
>>>>>>>would allow the network and/or phone to redispatch, yet
>>
>>provide a
>>

---

From: [email-masked]
Date: Tue, 27 Feb 2007 17:19:24 -0500

Most of this is good, but the use of an in-dialog 3xx is a really bad
idea for re-routing a dialog.  Primarily because it's not specified
how such a thing is processed, and also because it has to be inserted
in-dialog (whereas the controller of this little dance may not be in
the signalling path).

Let me suggest some alternatives:

You can send a REFER to a UA, which will cause it to replace an
existing dialog with a new one.  If you phrase it correctly, it
replaces both ends:

	REFER UA-A-gruu
	Target-Dialog: call-id...
	Refer-To: UA-B-gruu?Replaces=call-id...?Route=new-app-server

A B2BUA exploit INVITE/Join to insert itself into an existing dialog;

	send:
	INVITE UA-A-gruu
	Join: call-id...

	then send:
	INVITE UA-B-gruu
	Replaces: call-id...

Since these mechanisms are already defined, we know that cleaning up
the original dialog is properly specified, etc.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2007 12:42:39 -0500

The 3xx came up because the trigger for this is that the UAC sends a 
re-INVITE, say, one that adds a new media stream, and a proxy in the 
terminating side decides that a new element needs to be on the dialog path.

So, the proxy could reject the 4xx and then send a REFER, but the UAC is 
not going to know how to construct that INVITE properly. Namely, it 
won't know that this REFER-triggered INVITE is really a retry of the 
just-failed request, and should look the same more or less (besides 
being a new dialog forming request). Add another to your list of REFER 
uses, with a big missing semantic here.

So, while I agree that mid-dialog 3xx is kind of new territory (note it 
is partially treated in 
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt), 
its less new territory than the use of REFER for the problem at hand. I 
think 3xx is much closer to the desired semantic.

-Jonathan R.