Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

["Bart Wensley" <[e-mail]>]

Gonzalo,

I have put together some comments on the "Best Current Practice for ISUP to
SIP mapping" internet draft:

Section 1 - Introduction

The statement "Maintenance messages are outside the scope of this document."
is not very clear. Since there is no fixed identifier (i.e. CIC) for
SIP-BCP-T "trunks", the concept of ISUP maintenance (e.g. blocking,
unblocking, etc...) does not make sense. The draft should state that ISUP
maintenance messages are not used for SIP-BCP-T.

Section 3 - Scenarios

Although the concept of "SIP bridging" is mentioned in this section, it is
not discussed at all in the remainder of the document. In subsequent
sections of the document, it would be useful to discuss the inclusion of the
ISUP message within the body of the SIP message.

Section 5 - Mapping

It would be useful to include message sequence charts showing call flows for
SIP to ISUP and ISUP to SIP. Now that draft-johnston-sip-call-flows-00.txt
has been released, you may want to refer to it.

Section 6.6 - ACM is received

In the PSTN, the nearest exchange to the called party (not the caller)
generates the ringback tone and may send voice announcements.

Section 6.9 - CPG with status 'alerting' is received

The procedures in section 6.6 (not section 6.5) should be followed in this
case.

Section 7.1 - Address received

The use of a timer to force enbloc signaling is not acceptable. In the case
of SIP bridging, subscribers originating calls from the PSTN will not accept
an artificial post-dial delay (even if it is just a few seconds long).
Overlap signaling must be supported. It is essential that the overlap
process takes place within the context of a single session - using the
suggested INVITE/CANCEL/INVITE approach would result in multiple abortive
calls being delivered to the terminating agent, which would not be
acceptable.

Why not send an INVITE message when the ISUP IAM is received and then send
subsequent INFO messages for each ISUP SAM? I understand that "pure" SIP
agents will expect the INVITE to contain the complete address of the called
party. This could be handled by including support for overlap in the
"Require" extensions (draft-roach-mmusic-sip-pstn-require-header-00.txt). If
the terminator did not support the PSTN extensions, the originator could
then switch to enbloc and wait for the full address to be collected.

Details should be provided to specify how the various fields in the header
of the INVITE message are filled in. What should be provided in the "From:"
and "To:" fields? Is there a recommendation for the generation of Call-IDs?

Bart Wensley ([e-mail])
Nortel Networks