Subject: [Sipping] RE: Comments on draft-ietf-sipping-qsig2sip-01.txt

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 Aug 2003 12:47:17 +0100

Jean-Francois,

Thanks for your comments. I have dealt with most of the editorials. My
responses to your technical comments:

<SNIP>
#1 - Page 4 - Introduction

The document states :
"This document specifies signalling interworking for basic services 
that provide a bi-directional transfer capability for speech, DTMF, 
facsimile and modem media"

There are different drafts and RFCs dealing with DTMF, facsimile and modem
media. It's not really explained further down in the text. What about
clarifying
it or removing it ?
[JRE]Good point, because there are other aspects of DTMF, fax and modem that
are deliberately outside the scope of this specification. On the other hand
the same is true of speech, e.g., the use of RTP is not covered in this
document. I propose to add "Other aspects of interworking, e.g., the use of
RTP and SDP, will differ according to the type of media concerned and are
outside the scope of this specification."

#2 - Page 10 - 7 General requirements

"In addition, the gateway SHALL support SIP TU behaviour for a UA in
accordance
with [10] except where stated otherwise in this specification."

Where are the parts of the document where the behaviour is different ? If
there's no difference, the "except..." part of the sentence should be
removed.
[JRE] I believe all the requirements of sections 8 to 10 apply at the TU
level. Will clarify.

#3 - Page 10 -  7 General requirements
"SIP methods not defined in [10], [11], [13] or [14] are outside the"

Do [13] and [14] define SIP methods ?
[JRE] No - will clarify.

#4 - Page 10 -  7 General requirements
"As a result of DNS look-up by the gateway in order to determine where 
to send a SIP INVITE request, a number of candidate destinations can 
be attempted in sequence. The way in which this is handled by the 
gateway is outside the scope of this specification. However, any 
behaviour specified in this document on receipt of a SIP final 
response SHOULD apply only when there are no more candidate 
destinations to try."

Does it mean that the ingress gateway SHOULD try the next retrieved
addresses if
the first one responded 484 for instance ? I guess that rfc3263 narrows the
scope to "network" or "component" failures.
[JRE] I guess when overlap signalling applies in the SIP network the
statement is not quite true, so I will make an exception. Also I believe the
statement is not applicable to 3xx or 6xx responses, so I will limit it to
4xx and 5xx responses. Does this cover all the situations you had in mind?

#5 - Page 13 - 8.2.1.1 Receipt of QSIG SETUP message
"If information in the QSIG SETUP message is unsuitable for generating 
any of the mandatory fields in a SIP INVITE request (e.g., if a 
Request-URI cannot be derived from the QSIG Called party number 
information element)"

I agree in theory, but what could prevent from deriving a R-URI in the real
world ?
[JRE] It depends what method the gateway uses for mapping a number to a
R-URI. It might do it via look-up (e.g., ENUM), in which case if there is no
entry for the number concerned this might apply. Obviously it would not
apply to a gateway that algorithmically converts any number to a URI.

#6 - Page 14 - 8.2.1.3 Receipt of SIP 18x provisional response
"NOTE 2. Media streams are established as a result of receiving SDP 
answer information in a reliable provisional response and can be "

I agree that reliable provisional response are better, but why use reliable
here
? If a UA that does not support PRACK sends a 183 with a SDP body, the media
stream is established too.
[JRE] You are correct. However, the text concerned talks about SDP answer
but media streams can also be established at this time by means of SDP offer
in a provisional response. The text fails to mention this. According to
RFC3261 section 13.2.1 an unreliable provisional response cannot be used for
SDP offer. I will clarify the statement. Also subsequent modification of the
session by means of UPDATE applies only after a offer has been received in a
reliable message and answer has been sent, so this too would need
qualifying. However, it is not really necessary to mention UPDATE so perhaps
that part can be deleted.

#7 - Page 15 - 8.2.1.4 Receipt of SIP 2xx response
"If the gateway receives a SIP 2xx response other than 200 (OK), the 
gateway SHALL send a SIP ACK request."

What happens on the QSIG side ?
[JRE] The intention was to take no action. Will clarify.

#8 - Page 23 - 8.3.9
"If a gateway receives a SIP INVITE request with the same Call-ID as 
        an existing call for which the QSIG state is overlap sending and
with 
        updated Request-URI and To fields from which a called party number 
        with a superset of digits can be derived, it SHALL"
I think that it should read "same Call-ID and the same From header field
including the tag, and no tag in the To header field". 
BTW, the To header field is not so important anyway, since it's not used
(9.2.1).

Same remark for 7 of figure 5 and for 8 of figure 8.
[JRE]I agree. Will clarify.

#9 - Page 24 - 8.3.9
"If a gateway receives a SIP INVITE request for a new dialog with the 
        same Call-ID as an existing SIP INVITE request for which the gateway

        has not yet sent a final response and failing to meet the other 
        conditions above concerning overlap sending, the gateway SHALL 
        respond to the new request with a SIP 485 (Ambiguous) response."
It's not very important, but could you explain the motivation of this
sentence.
Is it related to the merged requests ?
[JRE] Its purpose is to prescribe behaviour if the gateway receives an
INVITE request that in all respects looks like overlap sending but fails to
meet the criterion of the derived called party number being a superset of
the previously derived called party number. I will change the wording
slightly to complement the changes I made to address comment #8, so see if
that helps. Concerning how it arises, I guess merged requests are one
possibility.

#10 - Page 24 - 8.4.1 
"as specified in table 1."
Why aren't some status codes symetric in table 1 and table 2. For instance 
- 408 Request timeout maps 102 Recovery on timer expiry and 
- 102 Recovery on timer expiry maps 504 Server time-out.
BTW, I like the way table 2 is similar to what RFC3398 describes.
[JRE] 504 also maps to 102, but it is not possible to make 102 map to both
408 and 504 - we had to pick one. This illustrates the point that there is
not a 1:1 correspondence between SIP responses and Q.850 causes and
therefore there will be some asymmetries and some rather questionable
mappings. Cause mapping was discussed long and hard for ISUP interworking
and again for QSIG interworking (resulting in some changes to ISUP
interworking to keep alignment). It is not perfect and it never will be, but
I would be reluctant to open up the discussion again. I hope you can live
with what we have.

#11 - Page 24- 8.4.1
Very minor comment. It's obvious that the 200 responses are related to the
INVITE transaction, but this is not written.
[JRE] Will clarify.

#12 - Page 27 - 8.4.4
What is the meaning of () in table 2 
     403 Forbidden                       21 (Call rejected) 
     404 Not found                       1 (Unallocated number) 
[JRE] Deleted.

--
And some remarks regarding other SIPPING drafts

#1 draft-ietf-sipping-overlap-04.txt
It says :
   "However, overlap signalling adds a requirement to this process. As a
   general rule, a media stream corresponding to the response to an
   INVITE with a greater number of digits should be given more priority
   than media streams from responses with less digits."

Is this requirement applicable here ?
[JRE] I remember this was discussed and we thought it best not to try to
give guidance in this tricky situation.

#2  draft-ietf-sipping-pstn-call-flows-02.txt 2.2, 4.2

I know that qsig2sip deals with QSIG only, but don't you think that people
might
get confused by the slight difference in the mapping of the messages of the
"ISDN PBX" examples of the call-flow draft ?
[JRE] There are of course some differences between QSIG and Q.931 that can
have impact on the mapping. Also I am not sure of the status of the
call-flows draft and in particular the two examples showing Q.931 mapping,
because I thought the group had decided not to work on SIP-Q.931 mapping.

</SNIP>

Regards,

John ([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: Jean-Francois Rey <[email-masked]>
Date: Thu, 07 Aug 2003 18:37:58 +0200

Hi John,

I agree with your replies to my comments. More details in-line.

regards,

Jean-Francois.

<SNIP>
> 4xx and 5xx responses. Does this cover all the situations you had in mind?

I guess that this behaviour is not specific to qsig2sip, so I'm not sure it is a
good idea to mention it. 

<SNIP>
> that part can be deleted.

[JFR] I agree that it would be better to remove it.
<SNIP>

> the previously derived called party number. 
<SNIP>
[JFR] OK. Now, I undertand what you meant. No need to change anything.

> I would be reluctant to open up the discussion again. I hope you can live

[JFR] You are correct. Since it is not a 1:1 mapping, a choice must be made. It
suits me.

<SNIP>
> give guidance in this tricky situation.
[JFR] OK.

> because I thought the group had decided not to work on SIP-Q.931 mapping.

[JFR] I'll check with the authors. Anyway a call-flow draft is not normative.