Subject: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft

From: "Attila Sipos" <[email-masked]>
Date: Thu, 17 May 2007 09:51:43 +0100

What if you want to use sips where possible but don't mind a fallback
to sip?

So, if someone makes a call using sips in request URI and
the called person doesn't have a sips URI registered, I guess the
proxy will return 404 not found.

So then then caller might say, ok, there isn't a sips URI, I will now
try a sip URI and see if that works.

The problem is that the called person might not have registered anything
at all.  So in such cases, the 2nd call attempt using sip is a waste.

Is there a requirement for some kind of new SIP response code which
says something like "no SIPS URI registered but there is a SIP one"?

What are the potential problems with this idea?

Regards,

	Attila

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 May 2007 11:43:13 -0500

> says something like "no SIPS URI registered but there is a SIP one"?

You mean like a 302?

--
Dean

---

From: [email-masked]
Date: Fri, 18 May 2007 22:28:29 -0400

From: Dean Willis <[email-masked]>

   You mean like a 302?

Is a 302 allowed to offer a sip: URI as a contact for a sips:
request-URI?

380 looks like it is intended to have this sort of effect, but its
content has not been standardized:

21.3.5 380 Alternative Service

   The call was not successful, but alternative services are possible.

   The alternative services are described in the message body of the
   response.  Formats for such bodies are not defined here, and may be
   the subject of future standardization.

And 416 seems plausible:

8.1.3.5 Processing 4xx Responses

   If a 416 (Unsupported URI Scheme) response is received (Section
   21.4.14), the Request-URI used a URI scheme not supported by the
   server.  The client SHOULD retry the request, this time, using a SIP
   URI.

But I can't tell if that last sentence is just a nit and should have
read "... this time, using a SIP or SIPS URI."

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 21 May 2007 19:48:51 -0500

416 is ok for "SIPS is not OK, but SIP will work". 

It is NOT ok for "SIP is not OK, but SIPS will works". For that, you can
use 302 or
301. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, May 18, 2007 19:28
> To: [email-masked]
> Subject: Re: [Sip] sips if possible, sip if not. - a question 
> on sip-sips-03 draft
> 
> 380 looks like it is intended to have this sort of effect, 
> but its content has not been standardized:
> 
> But I can't tell if that last sentence is just a nit and 
> should have read "... this time, using a SIP or SIPS URI."
> 
> Dale
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: [email-masked]
Date: Tue, 22 May 2007 13:31:39 -0400

From: "Francois Audet" <[email-masked]>

   use 302 or 301. 

What I like about 380 is that it seems to be designed for situations
where the calling user should be consulted, as opposed to 301/302,
which implementations seem to take as instructions for automatic
redirection.

Dale

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 May 2007 12:38:36 -0500

> which implementations seem to take as instructions for automatic

We've previously issued guidance on consulting users in the case of a  
302. Part of the justification here is that redirecting someone who  
placed a "local" call to a destination for which they would be  
charged "long distance" (or any other situation producing a similar  
differentiation in cost) is something that users would want to be  
informed of and consent to.

Are you suggesting that all such cases might be more appropriately  
dealt with by a 380? If so, how do we prevent malevolent types from  
abusing 302?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 May 2007 12:38:36 -0500

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 22 May 2007 15:32:53 -0500

I don't agree at all with this 380 idea.

To me, 380 basically redirects the request to a resource described
in a message body instead of (or perhaps in addition to) in the Contact
header.
And, it's not standardized yet.

I do not see anything in the description of 380 (section 21.3.5/RFC
3261)
that implies that the Calling user should be consulted.

Furthermore, RFC 3261 does state that for 3XX response that redirects
from
SIPS to SIP, you should consult the Calling party (see 8.1.3.4). 

To top it off, since 380 is not defined today, it will be treated as a
300 by all existing UAs. So it really does not solve anything.

> Sent: Tuesday, May 22, 2007 10:32
> To: [email-masked]
> What I like about 380 is that it seems to be designed for 
> situations where the calling user should be consulted, as 
> opposed to 301/302, which implementations seem to take as 
> instructions for automatic redirection.
> 
> Dale
> 
>