Subject: RE: [Sipping] Re: draft-petrie-sipping-xfer-issues-00.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Oct 2003 08:46:20 +0000

Dan,

This paper raises some interesting issues.

I think the problem of routing the consultation call via the same gateway
(if the potential transfer target is in the same legacy network as the
transferee) would be a useful problem to solve. On the other hand, care
should be taken to ensure that the consultation call doesn't egress via the
wrong gateway because of this. For example, the first call has come in via a
QSIG gateway. The consultation call is to an address in the legacy domain
but which is best reached via an ISUP gateway. If the call gets routed back
to the QSIG gateway, it depends on routing intelligence in the QSIG gateway
to ensure that it is onward routed in the SIP network (to an appropriate
ISUP gateway) rather than going back into the QSIG network and perhaps
taking a non-optimal route to the ISUP destination (perhaps even coming back
into the SIP network first). In fact the gateway would be required to act as
proxy.

I also have concerns about carrying anything in the INVITE request that
indicates too strongly that the call is a consultation call linked to a
particular existing call / transferee with an intention to transfer. Does
the transferor UA necessarily know this? The user interface may not allow
the transferor to indicate this. The transferor may not even know at this
stage - he may just wish to consult with somebody and then, after talking,
decide to do transfer rather than revert to the original call or form an ad
hoc conference. So indicating this to the callee (e.g, by the Subject
header), unless the caller has explicitly indicated that transfer will
follow, is somewhat dangerous.

If the transferor has two or more held calls, which one does the
consultation call relate to? I guess UAs will tend to have their own rules
about which one is applicable if transfer is invoked, in which case that
could be used for ensuring routing via the same gateway. However, if other
manipulations occur between establishment of the consultation call and the
eventual transfer, this "guess" could be wrong. It should work in the
majority of cases, so it is probably still worth doing.

Finally I am concerned about the transition from consultation to blind
transfer. Although maintaining ringing for an extra few seconds after CANCEL
would help to solve problems, particularly at a gateway, I can imagine there
would be a lot of cases where the callee answers and finds nobody there
because the blind transfer does not in fact occur. This might be because the
caller has given up and decides to revert to the original call, because a
proxy has invoked call forwarding no reply, or because a proxy has used
parallel forking and another UAS has answered.

I question why Replaces to replace an early dialog will not work. The
transferor should not normally try to invoke transfer until a 180 has been
received on the consultation call, which means that the consultation call is
relatively stable, so there is a good chance that it will be allowed to
alert for several seconds and therefore a good chance that REFER with
Replaces will work in this situation. Yes, there will be times when, due to
forking actions of the proxy, this will not work, but I don't think the
alternatives work either.

John Elwell ([email-masked])

_______________________________________________
Sipping mailing list  https://www1.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