Subject: RE: [Sipping] Tunnelling Q.931 (was Comments on draft-elwell-sipp ing-qsig2sip)

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 6 Jun 2002 12:33:03 +0100

Given that Q.931 is a user to network access protocol, and therefore asymmetrical, under what configurations would you want to tunnel it. 

If you want to make the network side implementation remote from the network access, then SIGTRAN already provides mechanism for doing that.

I can think of no reason why you would want to tunnel the protocol to something where you are not sure at the time of sending whether it is Q.931 or SIP aware.

If you want to make it a networking protocol, then it becomes symmetrical. If you make it symmetrical, it effectively becomes QSIG.

Keith

> -----Original Message-----
> From: Subhodeep Sarkar [mailto:[email-masked]]
> Sent: 29 May 2002 04:32
> To: 'Peterson Jon'; '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
> 
> 
> 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.
> 
> > -----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
> 
> 
> _______________________________________________
> 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