Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy

From: <[email-masked]>
Date: Wed, 3 Nov 2010 10:55:41 +0100

I understand that the usage of DNS to provide alternate server is a way to ensure redundancy. In such solution, to be able to handle SIP requests inside a SIP dialog and for which the proxy need to be "dialog statefull", there is a need to implement a mechanism that would allow the "alternate" server to share the same SIP dialog contexts.

My idea is in case of unavailability of the next hop and in case no alternate server is returned by DNS (or alternate servers are unreachable too), instead of rejecting the request (which would make the call/session fails), the SIP Proxy may send it to the hop after the unreachable one in the Route. This alternative would be authorized only if the Proxy knows that it's better to bypass the unreachable node instead of rejecting the request. The SIP proxy may get this information via a URI parameter in the Route entry of the "unreachable" node for example

Best regards,

Youssef

-----Message d'origine-----
De : Worley, Dale R (Dale) [mailto:[email-masked]] 
Envoyé : vendredi 29 octobre 2010 20:22
À : CHADLI Youssef RD-CORE-ISS; [email-masked]
Cc : [email-masked]
Objet : RE: [sipcore] Bypassing out-of-service intermediate Proxy

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]

I understand that the intention of this text in RFC 3261 is to fail over to an alternate server that serves the same function. Though, it's not explicitly stated.

However, I did not find any text in RFC 3261 that would make forbidden failing over to a proxy further down the path.  Moreover, I did not see any problem to such behaviour.
________________________________

If a particular URI is included in a Route header, then there is some important function the server with that URI is to perform.  If one element ignores this URI and sends the request to the next URI in the Route header, presumably the function of the skipped server will not be performed.

In all cases that I have heard about, the correct way to provide alternate servers for a failed server is to construct a DNS SRV name which maps to the primary and alternate server as is desired.

For instance, if functionA is to be serviced by serverA but in an emergency the request can be routed to serverB, and if functionB is serviced by serverB, then we construct two SRV names:

functionA    SRV   serverA  priority=1
functionA    SRV   serverB  priority=2

functionB    SRV   serverB priority=1

and use this Route header:

Route:  sip:functionA, sip:functionB

If an element has a request with this Route header, it will send the request to sp:functionA using the RFC 3263 rules, viz., attempt to send to serverA, and if that fails, attempt to send to serverB.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Nov 2010 09:57:38 -0400

This idea seems analogous to the auto assembly line deciding to bypass 
the broken station where the engine is inserted into the car, and just 
send the car on to the next station without its engine. The consumer who 
receives this car may be less than satisfied. :-(

	Thanks,
	Paul

On 11/3/2010 5:55 AM, [email-masked] wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: <[email-masked]>
Date: Fri, 5 Nov 2010 19:44:58 +0100

I don't think this analogy is correct.

If you take the example of a SIP Server which is inserted in the SIP path only to provide a supplementary service in case this latter is requested by the user ( e.g. call transfer), I think that the user will not be satisfied if it's call does not succeed just because the network is not able to provide this service...

Youssef

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Paul Kyzivat
Envoyé : mercredi 3 novembre 2010 14:58
À : [email-masked]
Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy

This idea seems analogous to the auto assembly line deciding to bypass the broken station where the engine is inserted into the car, and just send the car on to the next station without its engine. The consumer who receives this car may be less than satisfied. :-(

	Thanks,
	Paul

On 11/3/2010 5:55 AM, [email-masked] wrote:
> My idea is in case of unavailability of the next hop and in case no 
> alternate server is returned by DNS (or alternate servers are 
> unreachable too), instead of rejecting the request (which would make 
> the call/session fails), the SIP Proxy may send it to the hop after 
> the unreachable one in the Route. This alternative would be authorized 
> only if the Proxy knows that it's better to bypass the unreachable 
> node instead of rejecting the request. The SIP proxy may get this 
> information via a URI parameter in the Route entry of the 
> "unreachable" node for example
>
> Best regards,
>
> Youssef
>
> De : Worley, Dale R (Dale) [mailto:[email-masked]] Envoyé : 
> vendredi 29 octobre 2010 20:22 À : CHADLI Youssef RD-CORE-ISS; 
> [email-masked] Cc : [email-masked] Objet : RE: [sipcore] Bypassing 
> out-of-service intermediate Proxy
>
> From: [email-masked] [[email-masked]] On Behalf Of 
> [email-masked] [[email-masked]]
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 06 Nov 2010 07:37:32 -0400

> If you take the example of a SIP Server which is inserted in the SIP path only to provide a supplementary service in case this latter is requested by the user ( e.g. call transfer), I think that th…

Sure, the analogy *might* not always be correct, though it surely will 
be correct in some / many cases.

How can the element doing the skipping know? In general it has no idea 
of the importance of an element in the route.
Its at the time of insertion into the route that the importance is 
known, so that is when such decisions should be made.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Tue, 16 Nov 2010 18:01:18 +0100

> How can the element doing the skipping know? In general it has no idea of the importance of an element in the route.
> Its at the time of insertion into the route that the importance is known, so that is when such decisions should be made.

I see two ways: at the moment of insertion into the Route, as you mentionned, via a URI parameters ( the element which inserts itself into the Route knows whether it's could be sikpped) or via a static configuration ( which is of course less flexible solution)

Best Regards, 

Youssef  

-----Message d'origine-----
De : Paul Kyzivat [mailto:[email-masked]] 
Envoyé : samedi 6 novembre 2010 12:38
À : CHADLI Youssef RD-CORE-ISS
Cc : [email-masked]
Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy

> If you take the example of a SIP Server which is inserted in the SIP path only to provide a supplementary service in case this latter is requested by the user ( e.g. call transfer), I think that th…

Sure, the analogy *might* not always be correct, though it surely will be correct in some / many cases.

How can the element doing the skipping know? In general it has no idea of the importance of an element in the route.
Its at the time of insertion into the route that the importance is known, so that is when such decisions should be made.

	Thanks,
	Paul
> De : [email-masked] [mailto:[email-masked]] De la 
> part de Paul Kyzivat Envoyé : mercredi 3 novembre 2010 14:58 À : 
> [email-masked] Objet : Re: [sipcore] Bypassing out-of-service 
> intermediate Proxy
>
> send the car on to the next station without its engine. The consumer 
> who receives this car may be less than satisfied. :-(
>
> 	Thanks,
> 	Paul
>
>> the unreachable one in the Route. This alternative would be 
>> authorized only if the Proxy knows that it's better to bypass the 
>> unreachable node instead of rejecting the request. The SIP proxy may 
>> get this information via a URI parameter in the Route entry of the 
>> [email-masked] Cc : [email-masked] Objet : RE: [sipcore] 
>> Bypassing out-of-service intermediate Proxy
>>
>> From: [email-masked] [[email-masked]] On Behalf 
>> Of [email-masked] 
>> [[email-masked]]
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Nov 2010 08:44:18 +0800

Well, if the server knows it can be skipped it could simply not 
record-route.

Or, as Dale suggested, it could record-route with a DNS name that 
prefers to include it, but that names the predecessor as a lower 
priority alternative.

You are the first person I have ever heard ask for this functionality, 
so I expect it would be a hard sell to add any new mechanism to the 
specs to permit this in some other way. If you think it is important, 
start trying to make a case for it.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 18 Nov 2010 15:30:19 -0500

If we are considering how Route is handled, the question is not the failure of the call to be connected, but rather once the call is established, if the server fails, ensuring that later in-dialog requests (e.g., REFER, BYE) succeed.

But in practice, devices that provide supplementary services are usually B2BUAs (even if they could be implemented as proxies, or nearly so), and the proposed mechanism will not rescue a call from a failed B2BUA.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Nov 2010 00:08:54 +0100

Hi,

>start trying to make a case for it.

Not exactly the same case that Youssef is talking about, but every now and then I have had discussions that it would be useful to be able to re-negotiate the route set (not only the local/remote targets, but also the record-routes) during a dialog. E.g. in Outbound cases it could be used to move ongoing dialogs from a failed flow to another (it is not always possible to achieve it by using domain names and DNS).

A problem is of course backward compability, becuase you would need to ensure that every intermediary that wants to remain in the route set inserts Record-Route in every re-INVITE/UPDATE (or whatever request is used to re-negotiate the route set).

No, I did not suggest that we start work on such functionality :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 28 Nov 2010 21:56:39 -0500

> No, I did not suggest that we start work on such functionality :)

We already have a way to do that: INVITE with Replaces.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Nov 2010 07:42:54 +0100

Hi,

>>Not exactly the same case that Youssef is talking about, but every now and then I have had discussions that 
>>it would be useful to be able to re-negotiate the route set (not only the local/remote targets, but also the 
>>record-routes) during a dialog. E.g. in Outbound cases it could be used to move ongoing dialogs from a 
>>failed flow to another (it is not always possible to achieve it by using domain names and DNS).
>>
>>A problem is of course backward compability, becuase you would need to ensure that every intermediary 
>>that wants to remain in the route set inserts Record-Route in every re-INVITE/UPDATE (or whatever 
>>request is used to re-negotiate the route set).
>>

Sure, but that requires the establishment of a new session. 

Because I don't think it's allowd to send a re-INVITE, in order for a session to replace "itself", is it?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Nov 2010 07:31:40 -0500

> Because I don't think it's allowd to send a re-INVITE, in order for a session to replace "itself", is it?

Yes, it requires establishment of a new session. But the new session 
could be identical to the old one. (E.g. the exact same media addresses, 
ports, and formats could be offered.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Nov 2010 13:53:26 +0100

Hi, 

>>>>Not exactly the same case that Youssef is talking about, 
>>>>but every now and then I have had discussions that it would be useful to be 
>>>>able to re-negotiate the route set (not only the local/remote 
>>>>targets, but also the record-routes) during a dialog. E.g. in Outbound cases it 
>>>>could be used to move ongoing dialogs from a failed flow to 
>>>>another (it is not always possible to achieve it by using 
>>>>domain names and DNS).
>>>>
>>>>A problem is of course backward compability, becuase you would need 
>>>>to ensure that every intermediary that wants to remain in the route 
>>>>set inserts Record-Route in every re-INVITE/UPDATE (or 
>>>>whatever request is used to re-negotiate the route set).
>>>>
>>Because I don't think it's allowd to send a re-INVITE, in 
>>order for a session to replace "itself", is it?
> 
>Yes, it requires establishment of a new session. But the new 
>session could be identical to the old one. (E.g. the exact 
>same media addresses, ports, and formats could be offered.)

I guess it would be useful to e.g. have a response code which would trigger the new INVITE, so that it doesn't have to be done by a B2BUA in the network.

For example, if a registrar detects that it cannot forward a mid-session request on an outbound flow, it could send an error response back to the UA in order to trigger a new INVITE, which would then be forwarded on another outbound flow.

Regards,

Christer