Subject: [Sipping] RE: [Sip] Call forwarding feature support

From: [email-masked]
Date: Mon, 2 Jul 2001 14:38:27 -0500

Hate to tell you to move again, but this is really more of
a SIPPING issue.

Forwarding can be effected a variety of ways. The most efficient
one, of course, is to send a 300 response to an INVITE. If the
redirection contains "Contact" which the PSTN gateway can absolutely
determine to be a redirection back to the PSTN, it might just
turn around and re-send the IAM (or whatever) to its new destination.
Depending on the PSTN protocol being used, you might even be able
to do some fancy stuff so the call doesn't trombone through the
PSTN gateway.

Wow. That's a good story. The bad news is that it only works when
all nine planets are in alignment.

Usually, you won't be able to determine 100% that the Contact from
the redirection is a PSTN destination. This means that you get to
send the INVITE back in to the IP network to live its own life.
It might bounce through some variety of servers and eventually
terminate on another PSTN gateway (or even the same one), but -- and
here's the crux of the matter -- the ingress gateway has no way to
determine what will happen until it does (and, even then, it can
get somewhat tricky).

In short, most of the calls which originate in the PSTN, are forwarded
from a SIP network, and terminate in the PSTN will end up tromboning
through the IP network. There's not a whole lot that can be done about
it -- and, the awful truth is that no one is really all that motivated
to find a "solution," because the current situation works just fine.

/a

> -----Original Message-----
> From: Frank W. Miller [mailto:[email-masked]]
> Sent: Monday, July 02, 2001 2:13 PM
> To: [email-masked]
> Subject: [Sip] Call forwarding feature support
> 
> 
> 
> I posted this on the bell-labs list this morning
> but have been advised to move to the IETF list 
> instead.
> 
> I have a question having to do with call forwarding.
> Lets say we have a call that arrives at a SIP user
> agent and call forwarding is active at that user
> agent.  Further, lets assume that part of the call
> is carried over the PSTN.
> 
> There are two possibilities, 1) the call is forwarded
> to another SIP location, and 2) the call is forwarded
> to another phone that is on the PSTN.
> 
> It seems to me that in the first case, only SIP
> redirection is necessary and that this may be
> transparent to the PSTN leg of the call?  In the
> second case, there may be some SS7 interaction
> required.  Has anyone looked at this and if so is
> there any documentation on preferred approaches?
> If not, does anyone have any thoughts on how it
> should be done?
> 
> Thanks,
> FM
> 
> --
> Frank W. Miller, Ph.D.
> Chief Technical Officer
> sentitO Networks, Inc.
> www.sentito.com 
> 
> _______________________________________________
> Sip mailing list  http://www.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
> 

_______________________________________________
Sipping mailing list  http://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: "Frank W. Miller" <[email-masked]>
Date: Mon, 2 Jul 2001 16:28:09 -0400

Thanks for the reply, and I'm moving to the sipping list.

The mechanism you describe is exactly what I was thinking
about.  Was wondering how much this situation is seen in 
current networks, if you or anyone else has experience?

Further, it seems like any non-E164 address must go back
into the IP network by default.  A determination on an
E164 address could be resolved with TCAP query.  You should
be able to garner enough of a clue about whether to
regenerate the INVITE or the IAM.  Seems like these simple
rules might prevent most of the "tromboning" you mention.

Thoughts?
FM

--
Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Networks, Inc.
www.sentito.com 

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Monday, July 02, 2001 3:38 PM
To: 'Frank W. Miller'; [email-masked]
Subject: RE: [Sip] Call forwarding feature support

/a

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 5 Jul 2001 09:24:36 -0400

This really isn't a SIP issue per se.  A signaling network operator can
chose to implement the "forward from SIP UA to other PSTN address" scenario
in a number of ways.

1. (Probably the most likely, as it's easiest) If the subscriber (owner of
the SIP UA) pays, then the operator will simply treat this as a
re-origination.  It would be "good" if the outgoing signaling gateway fills
in the original dialed number, redirecting number, and redirection reason
code.

2. (Not as likely, as harder and also requires the ingress gateway owner to
be the signaling network provider) The ingress gateway effects something
akin to TBCT or RLT with billing info messaging.  Note that this makes the
filling-in of the ISUP fields a lot easier.

In either case, the gateway should be a good "SS7 citizen" and properly
fill-in the redirection information, if possible.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Frank
W. Miller
Sent: Monday, July 02, 2001 3:13 PM
To: [email-masked]
Subject: [Sip] Call forwarding feature support

[snip]

[snip]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 30 Jul 2001 18:34:50 +0300

Hello Frank,

If everything is handled by a single gateway everything is easy.
However, when there are several gateways handling the redirections we
have several problems. For example, the re-direction counter of ISUP
will not be up to date (the limit is usually 5 redirections in the
PSTN).

To solve this, the gateway has to be able to distinguish between an
INVITE with an IAM inside that is fruit of a redirection and an INVITE
with an IAM inside that is fruit of a SIP bridging situation. (this can
be done, for instance, by encapsulating the IAM in the INVITE's body).

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]