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

[Rey Jean-Francois <[e-mail]>]

Hi John and all,

I've been reading the draft-ietf-sipping-qsig2sip-01.txt. The document is very
useful. Please find some minor comments/questions on the draft :

#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 ?

#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.

#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 ?

#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.

#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 ?

#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.

#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 ?

#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.

#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 ?

#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.

#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.

#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) 

--
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 ?

#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 ?

--
And there are some minor editorial bugs :

#1
Page 4 : 
Annex A û Example message sequences..............................40 
	^^_ inconsistent character
Annex B û Change log.............................................53
	^^_ inconsitent character

#2
Page 4 
1 Introduction 
QSIG is twice between double quotes. It is not consistent with the rest of the
document

#3 - Page 7
figure 1 is broken because of it is at the end of the page
+
Figure 1 û Environment
	 ^^^

#4 - Page 9
Figure 2 û Protocol model
	^^^

#5 - Page 13 - 8.2.1.1 Receipt of QSIG SETUP message 
 gateway SHALL initiate QSIG call clearing procedures using cause 
 value 28 ôinvalid number format (address incomplete)ö. 
	 ^^^                                        ^^^
#6 - Page 18 - 8.2.2.2.7 Receipt of a SIP 4xx, 5xx or 6xx final response
The NOTEs are not tagged with a number as anywhere else in the document when
there are more than one of them in a section.

#7 - Page 25
RFC-3261 is usually referred as [10] in the document. No hyphen is used. (idem
in 8.4.2, 8.4.3, 8.4.4)
+
Table 1 û Mapping of QSIG Cause Value to SIP 4xx-6xx responses
        ^^^
+ 
Usually the Table legend is below the table itself (as for figures)

#8 - 10.1 Derivation of QSIG Bearer capability information element
only æaudioÆ then the Bearer capability information element SHALL BE
    ^^     ^^
+
Table 3 û Bearer capability encoding for æaudioÆ transfer 
	^^                               ^^    ^^

#9 - 10.2 Derivation of media type in SDP 
Table 4 û Media type setting in SDP based on Bearer capability
	^^

#10 - 13 Normative References
Networks (PISN) û Addressingö (also published by ECMA as Standard
		^^          ^^
[13] J. Peterson, ôA Privacy Mechanism for the Session Initiation 
		  ^^
        Protocol (SIP)ö, RFC 3323 
                      ^^
[14] C. Jennings, J. Peterson, M. Watson, ôPrivate Extensions to the 
					  ^^
Session Initiation Protocol (SIP) for Asserted Identity within 
Trusted Networksö, RFC 3325 
	        ^^

[17] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)ö,
								^^
 [19] G. Camarillo, A. Roach, J. Peterson, L. Ong, ôMapping of 
						   ^^
        Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap 
        Signalling to the Session Initiation Protocolö, draft-ietf-sipping-
 						     ^^
#11
Annex A (informative) û Example message sequences 
		      ^^
Figure X û Typical message sequence for 
         ^^
#12 - Page 47 - Figure 7
Message #11 should be labelled 4-200 OK as it is the response to 4-PRACK

#13 - Page 48 - Figure 8
Message #7 should be labelled QSIG SETUP ACK
					   ^^
#14 - Page 49 - Figure 9
Indentation problem

#15 
Annex B (temporary) û Change log
		    ^^

Regards,
Jean-Francois.
--
Jean-Francois REY
ALCATEL

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP