Subject: RE: To header for a proxied call

From: Jörgen Björkner <[email-masked]>
Date: Fri, 9 Jul 1999 11:13:17 +0200

Hello,
If a dialed number is redirected by the PSTN network to another phone number
that ends up in a gateway working as Shail describes, which of the numbers
should be
carried in the to and from fields? We have three nubers which all can be of
interest for a
routing intelligence in a proxy. To avoid confusion I explain this below:

A (5125551212) dials B (7771212121) which is redirected to C (9195551212) in
the PSTN network.
All three numbers will be presented to the PSTN/SIP gateway, the question is
how to carry all of them
within the SIP header? From a user point of view it might make most sense to
put tel:5125551212 (A) in the
From: field and tel:9195551212 (C) in the To:field. Assuming that the
routing intelligence is in a
proxy (P) the gateway (G) forwards all incoming calls to P. In traditional
PSTN world (at least in Sweden,
and I don't say that it has to be like this forever) B is responsible for
the redirected part of the call
(charged for it), and therefore it makes sense that B's routing preferences
are used by P, and therefore
B's number has to be in the message arriving to P.

How can B's number be carried?? Either with require: that uses a new field
to carry the redirection number,
or a VIA field could be inserted by the gateway containing a tel: url of the
redirecing party.

A drawback with a new field is that there is a need  for a matching pair of
gateway and proxy,
ie. I can't use any random SIP proxy together with a gateway that adds the
redirected number, even though the proxy
won't use this information.

If the number is carried in the Via: field any proxy could be used, it just
ignores the via field. If the
redirected number is needed for certain routing logic, you choose a server
parsing the Via: field. This
is illustrated below:

            PSTN              |            IP
                              |    
   A  ------->  B ----------> G--------> P -------(Server/gateway cloud)-->
C
                              |
                              |

Invite sent from G to P:

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP 1.2.3.3
Via: tel:7771212121
To: sip:[email-masked]
From: sip:[email-masked]

Logically is the PSTN redirection equal to a SIP Proxy, which inserts itself
as a Via:field
Does it make sense?? Will it break current implementations? Should a new
field in the header be used instead??

/Jorgen

-----Original Message-----
From: Shail Bhatnagar [mailto:[email-masked]]
Sent: den 8 juli 1999 21:27
To: Adam B. Roach
Cc: [email-masked]
Subject: Re: To header for a proxied call

My gateway is a gateway - it can talk to PSTN and the IP world. You can
assume that in the example I quoted, the routing intelligence is in the
proxy server - he will figure out where the phone number is located. 
 
Any interoperability issues with using the tel: URL ?

Thanks,
Shail

"Adam B. Roach" wrote:
> 
> >If a gateway is generating an INVITE message ( it is configured to send
> >all INVITEs to a proxy), what should be the value of To header ??
> >The request-URI looks like this  ( it is calling the number 9195551212
> >and proxy's IP address is 1.2.3.4)
> >
> >INVITE sip:[email-masked] SIP/2.0
> 
> It sounds like you're trying to describe a firewall proxy or something
> similar (where all requests from a given client go through the same
> proxy). If so, your example is incorrect.
> 
> In this case, let's assume you're trying to call [email-masked],
> and your proxy is set as 1.2.3.4. Your request would look something
> like:
> 
> INVITE sip:[email-masked] SIP/2.0
> From: Shail Bhatnagar <sip:[email-masked]>
> To: Socks Clinton <sip:[email-masked]>
> 
> BUT you would send this request to the machine 1.2.3.4. The request
> will not reflect this value anywhere.
> 
> I can't tell if this is the answer to your question, or if the "proxy"
> you described above is more of a PSTN gateway.  In any case, the
> value of "To:" is not terribly important except for message
> correlation. The real destination on any given machine is taken
> from the request-URI.
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
L-04
> [email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081
USA

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 9 Jul 1999 10:51:27 -0500 (CDT)

>B's number has to be in the message arriving to P.

It seems to me that the obvious way to code this would be:

INVITE tel:9195551212 SIP/2.0
From: tel:5125551212
To: tel:7771212121

The role of the "To:" field in SIP has always been somewhat akin
to the role of the B number in PSTN. It's what I call to get
ahold of a party, not (necessarily) their physical device.

There is an additional level of complexity here, though. Beyond the
A, B, and C numbers you describe, there's a redirecting number field
in ISUP which is used for the purpose of billing responsibility.
It carries the number most recently responsible for redirecting
the call (but not *all* the numbers that have redirected along the
way). I'll put together a fairly complicated example to show my point.

Let's say my number is 214-555-0000. I am calling a friend at
972-555-1234. He has his phone forwarded to a "find me" service
at 500-234-2345. The "find-me" service determines that he should
be in his Houston office at 713-444-9876. Finally, he has forwarded 
his Houston office phone to his IP phone at 212-765-4321 (which 
terminates on an IP gateway).

By the time this message arrives, it will have an A number of
214-555-0000, a B number of 972-555-1234, a redirecting number
of 713-444-9876, and a C number of 212-765-4321. The 500 number
does not appear in the ISUP message, having been overwritten
by the 713 number. In this scenario, the 713 number is used for
billing purposes, not the 972 number or the 214 number.

So, you're not really as interested in the B number (for billing
purposes at least) as you are in the redirecting number. The B
number could, however, be useful in determining, for example, whose
voice-mailbox to access.

I believe the question, then, is "how do we make the *redirecting*
number availble to SIP nodes?" I don't think a Via header would
be appropriate; any handling of this special-purpose Via header
would have to be at a node which understands your proposed extension.
Under these circumstances, the implications for adding a new header
are no different than encoding the redirecting number as a Via, and
a new header is much less confusing.

This is, of course, assuming that transit of the redirecting number
in a format understood by SIP nodes is even useful. I haven't thought
about it at length.

>Logically is the PSTN redirection equal to a SIP Proxy, which inserts itself

Not really. I'd contend that it's more like a redirect server, which
(currently) leaves no trace in SIP.

/a