Subject: RE: [Sipping] Service Identification: offerless INVITE case

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

As far as I know, a proxy cannot send a REFER - you would need a B2BUA
;)

Regards,

Christer 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 28. helmikuuta 2007 19:43
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Service Identification: offerless INVITE case
> 
> 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-loo
se-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.
> 
> [email-masked] wrote:
> 
> > 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
> > 
> > _______________________________________________
> > 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
> > 
> 
> -- 
> 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
> 

_______________________________________________
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