However there are implications in the draft that go beyond
ISDN (as defined by ITU-T service descriptions and as represented in the ISO
private network equivalents) in this case. Note that while the stage 1 and stage
2 for the ISDN public networks cover diversion using both forward switching and
redirection, forward switching is the only bit implemented in the public network
due to charging issues. Redirection does occur across the PBX-public network
interface.
In ISDN if A calls B and B redirects to C, then any UUI
that A sends to B is redirected to C.
The draft implies that B is allowed to include its own
personal UUI and that this will be given to C, and I believe this is not covered
in the ISDN case.
My understanding is that while in the ISDN the rerouteing
request contains UUI, it is the original UUI from the A user that is sent back
to the point of redirection as this will not have been preserved at these
intermediate points.
Thus in section 4.3 of the draft, F2 should only contain
UUI if F1 contains the UUI in the first place, and all the redirect server is
doing is reflecting it back.
Note that I do not necessarily have concerns about
extending the ISDN service, but we do need to be clear of the use cases where
this occurs, and also make sure that there are no interworking implications with
the ISDN service. Thus an ISDN user C receiving UUI will have expected this to
have come from the A user. If B happens to be a SIP user and inserting its own
UUI, what occurred to any original UUI from the A user, and how do we tell the C
user that this UUI is now really from user B.
regards
Keith
|
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP