Subject: RE: [Sipping] Comments on draft-elwell-sipping-qsig2sip

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 28 May 2002 18:41:13 -0500

Periodically, we have discussed undertaking a draft in SIP[PING] that would
detail Q.931-SIP mappings. I think it is a sufficiently distinct problem
that it merits its own consideration, independently of ISUP, though I would
still group this work under the rubric of SIP-T. I think some work on QSIG
is also required, especially in light of the fact that a QSIG MIME type for
tunneling is defined in RFC3204, but I don't have strong feelings about
bundling this with Q.931 work or not. I do feel it is critical that we
decide definitively whether or not we need to tunnel Q.931 in SIP messages
(in the past I've argued that we do not), and a number of small issues about
mapping. To my knowledge there isn't any Internet-Draft today that
recommends even the simplest message-level mapping (INVITE -> SETUP, 180 ->
ALERTING, etc) despite the widespread interest in PRI-based SIP gateways.
The record needs to be set straight (or, as Douglas Adams quipped, "firmly
crooked") on this so we can move on - this is one of the few remaining major
gaps in the SIP-T story. I know I've collected a couple of issues for
consideration in this work - maybe now, since the majority of the previous
SIP-T work is on the brink of completion, would be a good time to get
started on it.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 7:35 AM
> To: Vautz Rolf (SYS/HDD)
> Cc: [email-masked]'; [email-masked]';
> [email-masked]';
> [email-masked]'; [email-masked]
> Subject: Re: [Sipping] Comments on draft-elwell-sipping-qsig2sip
> 
> 
> Regarding a new work item:
> 
> Would all Q.SIG/Q.931 like protocols be included?
> 
> Is this sufficiently similar/different that it could/couldn't be merged 
> into the ISUP-SIP mapping draft?
> 
> Mike
> 
> 
> At 01:34 PM 5/27/2002 +0200, Vautz Rolf (SYS/HDD) wrote:
> >Dear All,
> >
> >Please receive below some questions on 
> draft-elwell-sipping-qsig2sip for
> >which I am looking for clarification.
> >
> >Question 1:
> >Subject: QSIG-SIP interworking: mandating 100rel
> >
> >draft-elwell-sipping-qsig2sip mandates support for 100rel 
> and in 8.3.1
> >rejects an INVITE that does not indicate support for 100rel 
> and does not
> >contain an SDP offer. Is this a reasonable constraint?
> >
> >Question 2:
> >Subject: Handling of 2xx in qsig2sip
> >
> >In section 8.2.1.4 of the qsig2sip draft, there is a 
> different treatment for
> >a 200 response and a 2xx (not 200) response. Only 200 maps 
> to a QSIG CONNECT
> >message. Would it not be appropriate to map all 2xx 
> responses to a CONNECT
> >message?
> >
> >Question 3:
> >Subject: Overlap sending between QSIG and SIP
> >
> >The behaviour of overlap sending in 
> draft-elwell-sipping-qsig2sip appears to
> >delay cancellation of an earlier INVITE that has not received a final
> >response when sending a new INVITE with additional digits 
> (see section
> >8.2.2.2.10). This appears to be in line with overlap sending 
> between SIP and
> >ISUP as described in draft-ietf-sipping-overlap-00. However, 
> is there any
> >real advantage in this?
> >
> >Question 4:
> >Subject: re-INVITES when interworking QSIG-SIP
> >
> >The statement in 8.5 of the QSIG-SIP draft seems 
> unnecessarily restrictive.
> >Although a re-INVITE seeking to change the media 
> characteristics in such a
> >way that they would no longer be compatible with the 
> negotiated QSIG bearer
> >capability clearly has to be rejected, other re-INVITES 
> might be acceptable
> >(e.g., hold, change of codec). Should this constraint be relaxed?
> >
> >Question 5:
> >Subject: SIPPING work item on interworking between QSIG and SIP
> >
> >The SIPPING WG already has a work item on interworking 
> between ISUP and SIP.
> >Would it be appropriate to have a complementary work item on 
> interworking
> >between QSIG and SIP? I-D draft-elwell-sipping-qsig2sip 
> could form the
> >basis. Has there been any check for compatibility between 
> the QSIG-SIP draft
> >and the ISUP-SIP draft?
> >
> >I look forward to receiving your opinion. Thanks in anticipation.
> >
> >Regards,
> >
> >Rolf
> >
> >Rolf Vautz
> >PN-SYS/HDD
> >Tenovis, Kleyerstr. 94, D-60326 Frankfurt
> >T +49 69 7505-3480
> >F +49 69 7505-53480
> >[email-masked]
> >www.tenovis.com
> >
> >
> >_______________________________________________
> >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
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Subhodeep Sarkar" <[email-masked]>
Date: Wed, 29 May 2002 09:02:26 +0530

I suppose it's a good idea to extend the RFC3204 to support tunneling of
Q.931. And as far as dealing with the
asymmetrical nature of the Q931 protocol - we can come with a draft with
network interface specification
with a deviation marked out wherever necessary for user interface (the
reason been the network side will mostly
interface with a PRI-SIP gateway). Following this we have to dealt with
the supplementary services separately if 
we want to extend those support to the PRI-SIP gateway.

Subhodeep Sarkar
Wipro Technologies  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Peterson, Jon
Sent: Wednesday, May 29, 2002 5:11 AM
To: 'Michael Hammer'; Vautz Rolf (SYS/HDD)
Cc: [email-masked]'; [email-masked]';
[email-masked]';
[email-masked]'; [email-masked]
Subject: RE: [Sipping] Comments on draft-elwell-sipping-qsig2sip

Periodically, we have discussed undertaking a draft in SIP[PING] that
would
detail Q.931-SIP mappings. I think it is a sufficiently distinct problem
that it merits its own consideration, independently of ISUP, though I
would
still group this work under the rubric of SIP-T. I think some work on
QSIG
is also required, especially in light of the fact that a QSIG MIME type
for
tunneling is defined in RFC3204, but I don't have strong feelings about
bundling this with Q.931 work or not. I do feel it is critical that we
decide definitively whether or not we need to tunnel Q.931 in SIP
messages
(in the past I've argued that we do not), and a number of small issues
about
mapping. To my knowledge there isn't any Internet-Draft today that
recommends even the simplest message-level mapping (INVITE -> SETUP, 180
->
ALERTING, etc) despite the widespread interest in PRI-based SIP
gateways.
The record needs to be set straight (or, as Douglas Adams quipped,
"firmly
crooked") on this so we can move on - this is one of the few remaining
major
gaps in the SIP-T story. I know I've collected a couple of issues for
consideration in this work - maybe now, since the majority of the
previous
SIP-T work is on the brink of completion, would be a good time to get
started on it.

Jon Peterson
NeuStar, Inc.