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

From: "Daniel G. Petrie" <[email-masked]>
Date: Wed, 22 Oct 2003 13:06:06 -0400

Thanks Dave for these really great comments.  My comments
are below.
Dan

"David R. Oran" wrote:

> Some initial comments and queries on
> draft-petrie-sipping-xfer-issues-00.txt. In most cases I think there are
> easier fixes than the ones you suggest in the document.
>
> 1. Isn't your "Consultative Transfer to Lost Target" exactly the sort of
> problem GRUU fixes? If TT' returns a GRUU in the 200OK contact of the
> Invite, the TC just puts this GRUU in the Refer-with-replaces to the TE,
> and the TE->TT' Invite is guaranteed to go to the right place.
>

Yes.  Alhough it perhaps was not explicit or clear that is what is intended
as the approach proposed in section 3.6 Use a Target URI

>
> 2. For "Consultative Call Prompting" and other similar advisory notices
> about the purpose of a call, just like for email, isn't the "Subject:"
> header exactly what's called for?

Yes.  I unfortunately missed this before I submitted the draft.  This
helps for prompting, however there is still a need for a symantic
purpose which probably does not make sense in the Subject header
as the syntax is freeform text.

>
>
> 3. For "Consultative Turned Blind Double Ring" I think we could easily give
> the right hint by putting a "Reason: replacement dialog coming" in the
> reason header of the CANCEL. This is exactly the sort of thing the reason
> header was created for.
>

Yes.  This is an excellent solution to the approach indicated in
section 3.2.  Adding an extension to the Reason header to
contain the associated dialog information would be useful
as well.

>
> 4. "Coerce Gateway Hairpins" is the first of these scenarios for which
> reasonably obvious use of existing protocol features doesn't seem to hold a
> solution. I have a suggestion though, which might have wider applicability,
> and now that we have GRUUs may be just the ticket. Define a new header
> field called "Dialog Affinity: <gruu>". The semantics would be for the
> proxy in the destination user's domain to attempt if possible to route the
> request to the same UA (in this case gateway) as is indicated by the
> corresponding Contact: address of the referenced GRUU. Finer granularity to
> the trunk level could be achieved if the subject gateway manufactured GRUUs
> which contained grid values identifying the appropriate trunk.
>

This is a little different from how GRUUs are to be used elsewhere.
Effectively the dialog affinity GRUU is more of a routing URI as
it is not the final distination.  The transfer target is URI (e.g.
dialed digits part of the URI initicating the transfer target).

So just to explore this a little further and make sure I understand
what you mean:
The gateway provides a dialog affinity GRUU for every call in or
out of the gateway.  Should the other end of the dialog decide to
do a transfer it copies the dialog affinity GRUU into the consultative
INVITE.  The URI cannot change from what is done today as the
URI contains the transfer target which the dialog affinity GRUU
could not have contained.  The proxy(s)/location server(s) do a kind
of loose route with the dialog affinity GRUU (or perhaps the
transferor does the loose route?)?  This avoids the normal routing
decisions made by the proxy(s)/location server(s) which might send
it to a different gateway.

I think that the proxy(s)/location servers need to be aware of the
dialog affinity GRUU as the location server(s) may still need to
perform transformations on the target URI (e.g. add/remove digit
prefixes, etc.).  I am not sure the loose route can work as it is not
clear when or which location server (where there are multiple that
transform the URI) should insert the loose route.

>
> 5. For "Consultative Turned Blind Gateway Glare" I don't see how we could
> ever fix that, given the inherent glare scenarios present on the PSTN due
> to the single TDM channel mapping property of calls. The entire SIP
> architecture exploits the ability to have parallel and overlapping dialogs
> to the same destination.

I think that you can fix it if the gateway disallows consultative transfer.  In
the blind transfer case, there are no overlapping dialogs unless someone
is play more than one of the three roles in transfer (e.g. transferee is the
transfer target).  In that case it is reasonable for the transfer to fail or to
land on a different target.  If there were multuple targets e.g. boss/admin
or user/voicemail, this is probably desirable anyway.

I think it may be possible to fix the consultative case if the gateway
requires that it stay pure consultative.  The gateway can probably not
put the tranfer on to the non-SIP side.  However it could handle the
overlapping dialogs for the consultation and target dialogs to the transfer
target and associate the two IP media streams to a single call leg out the
non-SIP side.

> Dave.
> ------------------------
> David R. Oran
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720
> Office: +1 978 264 2048
> VoIP: +1 408 571 4576
> Email: [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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 27 Oct 2003 00:01:50 -0500

Some thoughts inline.

> as the syntax is freeform text.

One idea here is to have a registry of well-known subjects, which can 
always be rendered and are meaningful in that way, but for which an 
automata can look out for, and do something different with, if it sees it.

>>which contained grid values identifying the appropriate trunk.

Yet another reason, btw, why unique gruus are a good idea.

> it to a different gateway.

This is what I was thinking as well. In particular, I didnt see a need 
for a separate header at all. The transferor would verify that its 
peer in the original call (the gateway) supports gruus (based on 
Supported: gruu in INVITE/200). Then, to initiate the consultative 
INVITE, it would literally use loose routing:

INVITE sip:[email-masked] SIP/2.0
Route: sip:[email-masked]

Where the Route header contains the gruu. This causes the consultative 
transfer to always hairpin through the transferee. We would probably 
need an additional Supported header field value that allows the 
transferee to say "I support routing of consultative transfers through 
me", so that the transferor would know whether it could construct an 
INVITE as above.

> transform the URI) should insert the loose route.

I think the transferor inserts it. It will get the call routed to the 
gateway. If the target of the call requires some kind of digit 
analysis from there, the gateway should take care of that, or contact 
a location server to do it. In the latter case, it can use an INVITE 
with a Request-Disposition that forces a redirect.

As an additional issue, the behavior of a proxy on seeing a Route 
header with an AOR or gruu in it, is far from clear. I believe the 
appropriate behavior is to actually perform the location lookup on the 
Route header, and take the results and push those into another Route 
header. Basically, instead of normal proxy processing which transforms 
the R-URI, it would transform the Route header. That allows for some 
very interesting call routing behaviors.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com