Subject: [Sipping] Supporting Multiple Path Routing

From: "Dale Worley" <[email-masked]>
Date: Sat, 07 Mar 2009 09:02:43 -0500

In our SIP PBX (called "sipXecs"), we consistently run into a problem
when a PBX has two gateway devices into the PSTN -- there's no good way
to configure a SIP proxy to use both gateways as a redundant pair.  Once
you tell the proxy to fork the call serially to both gateways, if the
call gets ring-no-answer or busy when going out the first gateway, the
proxy sends the call out the second gateway, to receive the same
response.  For practical PBX deployments, we need to solve this problem.
So I'm restarting the draft I wrote a while ago that describes the
problem.  I'm interested in hearing from anyone who has suggestions how
to fix the problem.

Dale

A new version of I-D, draft-worley-redundancy-response-04.txt has been successfuly submitted by Dale Worley and posted to the IETF repository.

Filename:        draft-worley-redundancy-response
Revision:        04
Title:           Supporting Multiple Path Routing in the Session Initiation Protocol (SIP)
Creation_date:   2009-03-06
WG ID:           Independent Submission
Number_of_pages: 10

Abstract:
An increasing number of SIP architectures implement multiple path
routing (MPR), which is the providing of more than one path for a
call to reach a destination user agent (UA).  A typical example is a
redundant pair of gateways from a SIP system to the PSTN.  A call
from the SIP system to the PSTN can pass through either gateway to
ultimately reach the destination telephone.  In order to gain the
benefits of redundancy in case one of the gateways fails or reaches
capacity, a proxy forks INVITEs serially to both gateways.

Unfortunately, if the call passes through one gateway but fails at
the destination phone (e.g., ring-no-answer), the proxy will then
fork the call to the other gateway, because the proxy has no way to
know that the call failed at the destination phone rather than at the
first gateway.  The second fork will fail in the same way at the same
destination phone.  This annoys both the caller (because the call
takes twice as long as it should before failing) and anyone within
earshot of the destination phone.  Similar failures plague any other
SIP architecture where a request can reach a destination through
multiple paths.

To gain the benefits of MPR without suffering from this problem, the
proxy which forks a request onto the redundant paths needs to be able
to determine if a fork that failed reached the destination UA and was
rejected by the UA (and so an alternate path should not be tried), or
if the fork failed before reaching the UA (and so an alternate path
should be attempted).  This document is to begin a discussion of
strategies for making this determination.

The IETF Secretariat.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 13:36:09 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dale Worley
> Sent: Saturday, March 07, 2009 9:03 AM
> To: SIPPING
> Subject: [Sipping] Supporting Multiple Path Routing
>

There *are* failure responses already which have the semantic of "don't bother rerouting": the 6xx series.  It's just that they're rarely sent.  The reasons they aren't sent would be the same reasons any new response code with those semantics wouldn't be sent, no?

Also, separating it into "response from proxy" vs. "response from UA" is not that simple, and won't fix that much.  There are plenty of proxies that represent the ONLY path to get to that UA, and plenty of UA's which do NOT represent the only path to get to the user.  I think what you really want to know is if the request got to the domain responsible for the AoR and it got routed within that domain to the UA, or not.  Right?  ISTM the real hard part there is due to the scope of the AoR - if it's an E.164 username, the domain is not relevant and the scope is bigger than SIP (it's semantically a tel URI), so the domain reached doesn't always know if it's really solely authoritative for that user or not globally.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sat, 7 Mar 2009 22:23:01 -0600

> problem.  I'm interested in hearing from anyone who has suggestions  

The problem is either that you're not getting a sufficiently  
descriptive response back from the first gateway so that you can  
decide whether or not to try the second gateway, or that the proxy  
isn't smart enough to tell the difference.

It's not a serial fork, it's a conditional serial fork. The operation  
can be described for some use cases in CPL.

--
Dean

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 13 Mar 2009 18:03:17 -0400

On Sat, 2009-03-07 at 13:36 -0500, Hadriel Kaplan wrote:
> There *are* failure responses already which have the semantic of
> "don't bother rerouting": the 6xx series.  It's just that they're
> rarely sent.  The reasons they aren't sent would be the same reasons
> any new response code with those semantics wouldn't be sent, no?
> 
> Also, separating it into "response from proxy" vs. "response from UA"
> is not that simple, and won't fix that much.  There are plenty of
> proxies that represent the ONLY path to get to that UA, and plenty of
> UA's which do NOT represent the only path to get to the user.  I think
> what you really want to know is if the request got to the domain
> responsible for the AoR and it got routed within that domain to the
> UA, or not.  Right?  ISTM the real hard part there is due to the scope
> of the AoR - if it's an E.164 username, the domain is not relevant and
> the scope is bigger than SIP (it's semantically a tel URI), so the
> domain reached doesn't always know if it's really solely authoritative
> for that user or not globally.

You're right, but I think that there are many cases in which
intermediaries _do_ know what the real situation is but report it in a
way that's ambiguous.  If the intermediate device is a PSTN/SIP gateway,
then in at least some cases it can distinguish between:

      * it has attempted to reach the PSTN number it extracted from the
        SIP request and gotten a response from the PSTN terminal (no
        such number or busy),
or
      * it has encountered an error somewhere before reaching that PSTN
        terminal (gateway is out of channels, trunk busy from the PSTN)

Granted that not all intermediate systems can know for every request
whether what they are returning is an end-to-end response or an
intermediate-to-end response.  But sometimes they do, and when they do
they should be clearer about it than we find them to be today (some
gateways return 486 when they are out of local DSP resources and have
not attempted a PSTN call at all, for example).  When they can't be
sure, that should (I think) be returned as an intermediate failure
(because if it really was intermediate, then alternate routes will be
tried to attempt to get an end-to-end result).

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 16 Mar 2009 18:27:20 -0400

> any new response code with those semantics wouldn't be sent, no?

The semantics of 6xx is (are?) deeply broken, because sending a 6xx back
to mean "don't bother rerouting" may also prevent forks to alternative
destinations that are not alternative routes to the failed destination.
I once wrote an I-D on the subject.

> for that user or not globally.

It's true that the problem in the fully general case is hard.  I allude
to this in the paragraph saying "It can be complicated to determine what
exactly is a set of alternative routes to the same destination."

In practice, a solution to my stated problem is made useful by the fact
that a major case is the "redundant gateways to the PSTN" problem.  It's
also eased by the fact that what we *really* are trying to avoid is
retrying ring-no-answer calls.  Failures that return immediately are a
waste of effort but do not annoy the users.

(Amusing anecdote:  In the system in which we first noticed this
problem, many, many calls to busy PSTN phones were made through the
redundant gateways.  First the call was routed out gateway 1, which
received an ISDN busy indication, which was reflected as a 486, then the
proxy sent the call to gateway 2, which did the same sequence.  So there
was a wasted ISDN call, but everything happened so fast the caller never
noticed.)

Analyzing this situation correctly requires identifying not only the
"splitting point" (the proxy that has to decide whether to try the
alternate path) but also the "joining point" (e.g., the UA where the two
alternate paths rejoin).

But given that PSTN failure codes carefully distinguish endpoint
failures from network failures suggests that segregating failure codes
is useful.  Currently, SIP does a bad job of that.  In the -00 version
of the draft, I identified 6 response codes with this problem.  And it
appears to be just a matter of sloppiness or not considering the
problem, not an intrinsic problem with the protocol.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 16 Mar 2009 18:28:37 -0400

> isn't smart enough to tell the difference.

Yes, in the basic case, the problem is that we're not getting a
sufficiently descriptive response back from the gateway.  In the -00
version of the draft, I went through all the response codes, and there
are 6 whose definition are insufficiently explicit to be troublesome.

Dale

---

From: "Kanumuri, Sreeram" <[email-masked]>
Date: Mon, 16 Mar 2009 19:55:38 -0700

I strongly support the Issue that is addressed in the Draft need to be addressed. With the increase in the SIP Networks in the field this issue will not only be in SIP PBX's but also in SIP Networks.

I feel to address this issue addressing response_from_UA vs response_from_proxy is difficult as it may need change in exsisting proxies to understand the response codes and implement them. so Instead we can create a new header:(like)Entitysource.
This will be inserted in all the response codes. This can have the Values UA/Proxy/token.
Based on that value of the new header the behavior can be determined by the originating UA.
IMHO,this will be better than response codes as we can have this Header optional and so when will not have any impact on the present implementations.

The main problem with the error codes in the SIP is, we cannot determine today directly looking at the response code if it is from the end UA or Proxy and this need to be addressed!!

-Sreeram.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale Worley
Sent: Saturday, March 07, 2009 6:03 AM
To: SIPPING
Subject: [Sipping] Supporting Multiple Path Routing

Dale

Abstract:

The IETF Secretariat.

_______________________________________________
Sipping mailing list  https://www.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: Hisham Khartabil <[email-masked]>
Date: Tue, 17 Mar 2009 15:28:37 +1100

2009/3/14 Scott Lawrence <[email-masked]>:
> not attempted a PSTN call at all, for example).

I would think this should return a 5xx response (503 to be precise).
Aren't those things usually configurable in a GW?

Hisham

> When they can't be

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 17 Mar 2009 15:47:41 +1100

Hi,

Forking at the sip proxy level, I guess, was not intended for
redundancy usage. Can the gw itself forward to another gateway? It
knows best if the failure came from it, the pstn network or the end
point.

Hisham

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 17 Mar 2009 07:22:24 +0000

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hisham Khartabil
> Sent: 17 March 2009 04:29
> To: Scott Lawrence
> Cc: SIPPING
> Subject: Re: [Sipping] Supporting Multiple Path Routing

....
 
> Aren't those things usually configurable in a GW?
[JRE] And for a QSIG gateway 503 is indeed specified in RFC 4497, and likewise in RFC 3398 for ISUP.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 17 Mar 2009 08:29:33 +0100

Hi,

In the gateway case, can't you use the Reason header to provide
additional information?

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Dale Worley
> Sent: 17. maaliskuuta 2009 0:29
> To: Dean Willis
> Cc: SIPPING
> Yes, in the basic case, the problem is that we're not getting 
> a sufficiently descriptive response back from the gateway.  
> In the -00 version of the draft, I went through all the 
> response codes, and there are 6 whose definition are 
> insufficiently explicit to be troublesome.
> 
> Dale
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 17 Mar 2009 16:31:04 -0400

> In the gateway case, can't you use the Reason header to provide

If we need to carry information that can't be carried by existing
mechanisms, the Reason header sounds like a good place to carry it.  But
that solution would still require standardizing how the information is
carried.

Dale

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 17 Mar 2009 21:39:08 +0100

Hi, 

additional information?
mechanisms, the Reason header sounds like a good place to carry it.  But
that solution would still require standardizing how the 
>information is carried.

What do you mean by "how the information is carried"? The spec defining
the Reason header defines that.

If you refer to the PSTN/SIP interworking you may want to take a look at
3GPP TS 29.163, which also describes the interworking of the Reason
header.

Regards,

Christer