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

From: "Vautz Rolf (SYS/HDD)" <[email-masked]>
Date: Mon, 27 May 2002 13:34:15 +0200

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 27 May 2002 15:48:18 +0100

Rolf,

See my responses to your comments in-line.

Regards,

John

--------------------------------------------------------------
John Elwell ([email-masked])
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.

> -----Original Message-----
> From: Vautz Rolf (SYS/HDD) [mailto:[email-masked]]
> Sent: 27 May 2002 12:34
> To: [email-masked]'; [email-masked]';
> [email-masked]';
> [email-masked]'
> Cc: [email-masked]
> Subject: [Sipping] Comments on draft-elwell-sipping-qsig2sip
> 
> 
> Dear All,
> 

[JRE] I think so, because if in-band tones or announcements need to be
conveyed back to the caller before the SIP final response to the INVITE, the
SDP offer will have to be sent in a provisional response. If the provisional
response is not sent reliably, there is a danger it will be lost. The caller
will then not hear the tone or announcement, which may be important. We
could not think of a way around this.

> message. Would it not be appropriate to map all 2xx responses 
[JRE] A 2xx response other than 200 should not arise in response to INVITE.
If the gateway does receive one, it is presumably an error situation. The
choices available seem to be:

a) Treat it as an error and abort the call - seems a little harsh.
b) Treat it as a 200 response
c) Accept it as a valid SIP response but don't map it to the CONNECT. If a
forking proxy is in use, a 200 response may still arrive from a different
UAS.

We decided in favour of c), but it was a close call. Any other opinions?

> ISUP as described in draft-ietf-sipping-overlap-00. However, 
[JRE] The advantage seems to be that the QSIG call initiated by the previous
INVITE when it arrived at an egress from the SIP network to a QSIG network
will remain in place, awaiting more digits, until the new INVITE arrives.
The new INVITE can cause further digits to be sent in a QSIG INFORMATION
message. If the previous transaction were to be cancelled as soon as the new
INVITE is sent, there is a danger the CANCEL could reach the egress gateway
before the new INVITE arrives, causing the gateway to clear the QSIG call.
Although this should still work (the new INVITE will establish a new QSIG
call), it is less efficient from the QSIG viewpoint. Also QSIG resources
released as a result of the CANCEL may be taken by some other call and
therefore not be available when the new INVITE arrives. These are minor
advantages of the approach we took, and the decision to go this way was
based on the fact that the overlap draft says the same for ISUP
interworking. However, there is a drawback - the fact that the new INVITE
might go to a different egress gateway, thereby leaving the original QSIG
call in place in parallel with the new QSIG call from the new gateway.

> (e.g., hold, change of codec). Should this constraint be relaxed?
[JRE] Good point - perhaps we need to reword this so that re-INVITES are
allowed provided they remain compatible with the QSIG bearer.

> basis.
[JRE] I would support this if there is sufficient interest in the SIPPING
group.

> Has there been any check for compatibility between the 
> QSIG-SIP draft
> and the ISUP-SIP draft?
[JRE] The ISUP draft (older version) was used as a starting point, but the
two may have diverged slightly over time. I guess we need to check again,
but any input from the ISUP-SIP interworking experts would be good.

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 27 May 2002 17:29:51 +0200

Hello John,

A minor comment inline

Regards,
Denis

> call in place in parallel with the new QSIG call from the new gateway.

Section 3.7 "INVITEs reaching multiple gateways" of the overlap draft proposes solution for this problem by the cost of the services in the SIP network.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 28 May 2002 10:35:20 -0400

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

---

From: Michael Hammer <[email-masked]>
Date: Tue, 28 May 2002 10:47:48 -0400

Denis,

The text you cite says that it is proposed that INVITEs be routed to the 
same gateway when overlap signaling is used.  Should this be strengthened 
to a SHOULD or a MUST?  Otherwise, it is possible that different gateways 
will route parallel calls into the TDM network until a complete digit 
sequence succeeds from one of those gateways.

If so, then the primary justification behind using INVITEs over INFOs has 
just been negated, since the only advantage of the INVITEs was the fact 
that they could be routed differently in the SIP network, and potentially 
triggering additional services.

Mike

At 05:29 PM 5/27/2002 +0200, Alexeitsev, D wrote:
>Section 3.7 "INVITEs reaching multiple gateways" of the overlap draft 
>proposes solution for this problem by the cost of the services in the SIP 
>network.
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 May 2002 16:16:00 +0100

Alex,

Thanks for the comment. However, it is not clear to me how to force the
second INVITE to follow the same path as the first. At this point in time,
the only response from the first INVITE is likely to be a 100 from the first
proxy, so the complete path will not be known to the ingress gateway.

Regards,

John

> From: Alexeitsev, D [mailto:[email-masked]]
> Sent: 27 May 2002 16:30
> To: [email-masked]
> Cc: [email-masked]
> Subject: AW: [Sipping] Comments on draft-elwell-sipping-qsig2sip
> 
> 
> Hello John,
> 
> A minor comment inline
> 
> Regards,
> Denis
> 
> > Question 3:
> Section 3.7 "INVITEs reaching multiple gateways" of the 
> overlap draft proposes solution for this problem by the cost 
> of the services in the SIP network.
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 May 2002 16:27:53 +0100

Michael,

You wrote: "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?"

The message and information element names in ISUP are quite different from
those in QSIG and Q.931. Although there is quite a lot of synergy, this
different naming and other technical differences might make it difficult to
include ISUP.

Concerning combining QSIG and Q.931, the problem is that QSIG is symmetrical
(being a networking protocol) and Q.931 is asymmetrical (being an access
protocol). To write an interworking specification for Q.931 one would need
to consider:

1. Do we specify interworking for the user side or the network side of
Q.931, or both?
2. Does the SIP network act as an extension of the access protocol or as a
network protocol? In the latter case the gateway is not only performing
protocol interworking but also providing interworking between the access and
the network.

So my answer is that a combined specification may not be as attractive as it
sounds.

Regards,

John

> From: Michael Hammer [mailto:[email-masked]]
> Sent: 28 May 2002 15:35
> To: Vautz Rolf (SYS/HDD)
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]
> Subject: Re: [Sipping] Comments on draft-elwell-sipping-qsig2sip
> 
>

---

From: [email-masked]
Date: Wed, 29 May 2002 08:56:53 +0200

Michael,

I agree that it would be better to mandate that these INVITEs be routed
to the same gateway. However, I do not see how this could be enforced.
INFO is not necessarily any help here.

Regards,

Frank

Denis,

Mike

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 29 May 2002 09:53:39 +0200

Hello Mike,

Well, this is my understanding as well, but with SHOULD there is still a chance of getting services (even by the cost of reliability). The main argument so far: if you don't need services, why are you using SIP anyway.

P.S. What about UPDATE method - could it be used for overlap?

Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Michael Hammer [mailto:[email-masked]]
Gesendet am: Dienstag, 28. Mai 2002 16:48
An: Alexeitsev, D
Cc: [email-masked]; [email-masked]
Betreff: Re: AW: [Sipping] Comments on draft-elwell-sipping-qsig2sip

Denis,

Mike

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 29 May 2002 10:02:35 +0200

Hello John

The Note in the section 3.3 "Sending overlap signalling to the SIP network" of the overlap draft says 

        Note that it is possible to receive a response to the first
        INVITE before having sent the second INVITE. In this case, the
        response received would contain a To tag and information
        (Record-Route and Contact) to build a Route header field

It is my understanding as well, that the e2e response for the initial INVITE can only be received only after sending the second INVITE, so it is a good question about how to get the routing information for the second INVITE from the 100 response.

Probably the overlap draft authors could explain this note.

Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]]
Gesendet am: Dienstag, 28. Mai 2002 17:16
An: 'Alexeitsev, D'
Cc: [email-masked]
Betreff: RE: [Sipping] Comments on draft-elwell-sipping-qsig2sip

Alex,

Regards,

John

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 29 May 2002 05:29:58 -0500

This note in 3.3 only suggests that before a SAM arrives at a gateway in an
overlap dialing scenario, a response could be received for the initial
INVITE transaction (the one corresponding to the original IAM received by
the gateway). Since presumably the call cannot be answered (because the
address is incomplete), this INVITE could only receive a provisional (1xx)
response, not a success (2xX) response. 

It is however possible to establish an early dialog (see RFC3261 section
12.1) with a 1xx response - the 1xx can contain a Contact header, To tags,
i.e. the required protocol apparatus for a dialog. This note merely says
that if you happen to receive such a response in time, you shouldn't use
that Contact header, those To tags, and so on in any INVITE you will send
based on a SAM, since this would force requests to go to the same
destination. Since there is no guarantee either way that you will receive an
usable 1xx response in time to send a second INVITE after a SAM arrives, it
would be tough to rely on this behavior if you were, for whatever reason,
interested in forcing requests to go to the same destination.

Then again, if you're only interested in sending requests to the same
destination, that would seem to miss the point of collecting more address
digits from SAMs in the first place, since presumably the dialed number
tells you how to direct the call (and the originating gateway will most
likely have no idea whether the destination is a gateway or not). To be
clear, speaking to the note that kicked off this thread, section 3.7 of the
overlap draft does not recommend any practices that sacrifice services in
order to route calls to the same gateway - quite the contrary. The
conclusion to that section reads:

   If sending multiple IAMs to the PSTN is not
   acceptable in a particular domain, overlap signalling should not be
   used.

Jon Peterson
NeuStar, Inc.

> Sent: Wednesday, May 29, 2002 1:03 AM
> To: [email-masked]
> Cc: [email-masked]
> The Note in the section 3.3 "Sending overlap signalling to 
> the SIP network" of the overlap draft says 
> 
> It is my understanding as well, that the e2e response for the 
> initial INVITE can only be received only after sending the 
> second INVITE, so it is a good question about how to get the 
> routing information for the second INVITE from the 100 response.
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 May 2002 14:30:30 +0100

Jon,

Sure you can have an early dialog as a result of a 1xx (other than 100), but
in the situation where the destination QSIG network is awaiting more digits,
it will not normally send back a message that would cause the egress gateway
(SIP to QSIG) to send a 1xx. So I don't think this helps. I imagine this is
true also for ISUP.

The status quo seems to be that by delaying the cancellation of a previous
INVITE, the new INVITE with additional digits will most likely arrive at the
same egress gateway, can be associated with the existing QSIG/ISUP call and
can result in the sending of an INFO/SAM message. In the (less likely?) case
that it is routed to a different gateway, then we suffer the inefficiency
that the original QSIG/ISUP call is left waiting for more digits that it
will not receive and will be cancelled only when another INVITE receives a
final response. This disadvantage is probably outweighed by the greater
efficiency obtained in the (more likely?) case where the same gateway is
used.

One further thought. Receipt of a 1xx response that implies that sufficient
digits have been received (e.g., 180 Ringing) could be used to cancel any
previous INVITEs - it should not be necessary to wait for 200, which could
be many seconds later.

Regards,

John

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 29 May 2002 11:30
> To: 'Alexeitsev, D'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] Comments on draft-elwell-sipping-qsig2sip
> 
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 May 2002 15:20:24 +0100

Denis,

See below.

Regards,

> Sent: 29 May 2002 15:13
> Some comments inline
> Thanks,
> Gesendet am: Mittwoch, 29. Mai 2002 15:31
> An: 'Peterson, Jon'
> Cc: [email-masked]
> [DA] Does it mean, that there is no guarantee at all for the 
> equal routing of subsequent INVITES?
[JRE] That appears to be the case.

> [DA] The INVITEs can only be ended by final responses, so it 
> will require to change the SIP state machine 
[JRE] No. On receipt of a 180, say, in response to INVITE, the UAC (ingress
gateway) can issue a CANCEL request on any previous INVITES that have
received a 100 response but have not received a final response. I don't
believe this changes the SIP state machine.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 30 May 2002 10:37:51 -0400

Jon,

I would like to make one suggestion:  Can we have only one of the
drafts define the mapping of SIP response codes to Q.850 Cause codes and
vice versa?  The other drafts can refer to that one.  As the
SIP-ISUP mapping draft was out first, I would also suggest that it be
used as the baseline.

Mike

At 06:41 PM 5/28/2002 -0500, Peterson, Jon wrote:

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.

> Sent: Tuesday, May 28, 2002 7:35 AM

> >Please receive below some questions on

> draft-elwell-sipping-qsig2sip for

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

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

> >The behaviour of overlap sending in

> draft-elwell-sipping-qsig2sip appears to

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

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

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

> >Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping

> Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 31 May 2002 19:59:29 -0500

Off the bat, I'm not sure why a subsequent Q.931-SIP draft could not
reference the existing ISUP-SIP (with its current limited set of
ISUP-specific cause codes) draft as needed, making additions and possibly
revisions to the mapping when appropriate. I am even aware of a few
potential behavioral conflicts (for example, the overloaded cause code 26
which I mentioned in an earlier mail). It's possible that an ISUP-SIP
implementation might want to handle things differently than a Q.931-SIP
implementation on any number of fronts. No question that your solution would
be cleaner - certainly, the consolidated ITU cause code document (i.e.
Q.850) sets a good example for modular specmanship. But we also need to
close out the ISUP-SIP mapping draft, which is past WGLC and is now already
a little late for IETF last call, and I feel comfortable that a forthcoming
Q.931-SIP document should not affect how we map ISUP, anyway.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, May 30, 2002 7:38 AM
To: Peterson, Jon
Cc: Vautz Rolf (SYS/HDD); [email-masked]';
[email-masked]'; [email-masked]';
[email-masked]'; [email-masked]
Subject: RE: [Sipping] Comments on draft-elwell-sipping-qsig2sip

Jon,

I would like to make one suggestion:  Can we have only one of the drafts
define the mapping of SIP response codes to Q.850 Cause codes and vice
versa?  The other drafts can refer to that one.  As the SIP-ISUP mapping
draft was out first, I would also suggest that it be used as the baseline.

Mike

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.

> From: Michael Hammer [ mailto:[email-masked] <mailto:[email-masked]>
]
> > www.tenovis.com <http://www.tenovis.com/> 
> >
> >
<https://www1.ietf.org/mailman/listinfo/sipping> 
> >Use [email-masked] for new developments of core SIP
<https://www1.ietf.org/mailman/listinfo/sipping>