Subject: [Sipping] RE: WGLC for draft-ietf-sipping-qsig2sip-01

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

Francois,
 
Thanks for your comments. I will address the editorials. Concerning the
technical comments:
 
<SNIP>
- Section 8.3.1, page 19 
  
  5th paragraph: Add ", unless the gateway is aware that in-band information

  will not be used" to the end of the paragraph. The reason for this is that

  there are cases where the gateway may have a priori-knowledge that in-band

  tones and announcements are not used; and out-of-band ALERTING or 
  fast connection (i.e., no PROGRESS and no ALERTING) is always 
  used for example. In that case, there is no reason to reject the call with

  488 if the SDP was not included in the INVITE. 
[JRE] I agree that if there is a priori knowledge that in-band tones and
announcements will not be used, then what you propose is reasonable. I am
rather doubtful that the gateway will have sufficient knowledge to determine
this. The 4th and 5th paragraphs of 8.3.3 mandate the connection of media
streams if relevant QSIG progress indicators are present in a PROGRESS or
ALERTING message. The presence of these progress indicators is outside the
control of the gateway. So how can the gateway have a priori knowledge that
these progress indicators will not be received?

- Section 8.3.5, page 21 

  This section mandates the inclusion of SDP in 18x response. This may not
be 
  possible, or even required. For example, it is very common for PBXs not to

  know at the time of rigning where a call will be terminated (i.e., which 
  user): this applies to features such as "hunt group", as well as "multiple

  line appearances". In those cases, it may be impossible for the gateway 
  to include an SDP in the 18x, because it does not know yet whitch media 
  gateway resource will be used. Furthermore, it is against the spirit of 
  the offer-answer model and SIP to mandate that the SDP must be included 
  in the 18x response (it could be in 200 OK for example). 

  Paragraphs 3 and 4 shall thus be modified as follows: "...SDP answer 
  information SHOULD be included in the SIP 18x provisional response if 
  the SDP information is available." 

[JRE] This clause was primarily intended to cover the case where an in-band
tone or announcement is to be sent. I propose changing it to say the rules
SHALL apply if an in-band  tone or announcement is available and MAY apply
otherwise.

</SNIP> 
 Regards,

John ([email-masked] <mailto:[email-masked]> )

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Aug 2003 10:45:31 -0700

Thanks John, see below:

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, August 06, 2003 04:48
To: Audet, Francois [SC100:4K02:EXCH]; [email-masked]'
Subject: RE: WGLC for draft-ietf-sipping-qsig2sip-01

Francois,

<SNIP>
- Section 8.3.1, page 19 

I'm talking about the gateway RECEIVING the SETUP, not the one sending it.
The case I am thinking of is then the Gateway is an IP PBX (with SIP on one
side, QSIG on the other). If the call terminates on a local phone, it may
use out-of-band ringing (our PBXs work that way). 
 
If we want to be picky about the meaning of  Gateway, and dissociate the
gateway from the actual QSIG PBX, then it can still happen. The gateway may
decide to map the INVITE to SETUP anyways and forward it to the QSIG PBX. If
the PBX responds with the ALERTING indicating out-of-band, everything is
fine (which is why I would like this change). If on the other hand, the
ALERTING indicates in-band, then the gateway could decide to do as per your
procedure and send the 488. But I wouldn't want to mandate 488 everytime the
SDP is not in the INVITE, especially since it is a very normal occurence in
SIP.
 
Even for the second case, where the call ultimately terminates on a line
with an in-band signalling, I am not convinced at all that the qsig2sip
draft should mandate that the call be terminated. To me this should be a
design option. An implementer may decide that it prefers to go through with
the call, and provide some sort of indication to the user that the call is
"progressing" instead of failing the call (I expect that a proper SIP
implemenation would do something like that).
 
I would prefer that the paragraph does not mandate the 488 as other options
are doable, and probably much less drastic than call failure (as an
out-of-band progress indication would be).

- Section 8.3.5, page 21 

I'm OK with your proposed text.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 07 Aug 2003 16:09:43 +0100

Francois,

In-line.

Regards,

John

- Section 8.3.1, page 19 

 
[FA]I'm talking about the gateway RECEIVING the SETUP, not the one sending
it.

[JRE]You referred originally to 8.3.1, which deals with receiving INVITE /
sending SETUP, not receiving SETUP. From the rest of your remarks below I
assume you really do mean 8.3.1 and the gateway receiving the INVITE /
sending the SETUP.

[FA]The case I am thinking of is then the Gateway is an IP PBX (with SIP on
one side, QSIG on the other). If the call terminates on a local phone, it
may use out-of-band ringing (our PBXs work that way).

[JRE] I would not want to send 488 after receiving a QSIG ALERTING or
PROGRESS message indicating in-band information, because by then the called
user in the QSIG network might already be being alerted and it would not be
good practice to cancel the call at this stage.

[FA]Even for the second case, where the call ultimately terminates on a line

[JRE] On reflection I can see some merit in allowing the call to proceed,
even though we cannot guarantee that in-band information will be passed to
the caller. If the caller is a user of a SIP device of some sort, even if we
pass in-band information back through the SIP network, there is no guarantee
that the SIP device will play it to the user. On the other hand, if there is
another legacy network on the originating side of the SIP network, it will
of course be able to pass in-band information and the SIP network (using
unreliable provisional responses) would be the sole cause of failure to pass
in-band information end-to-end. In the case of another QSIG network we have
mandated support for 100rel (see 8.2.1.1) anyway. So on balance I think I
could agree to relax the rules concerning a 488.
I propose making it a SHOULD and including the text: "A gateway that has a
priori knowledge that essential in-band information will not need to be sent
before answer can choose to proceed with the call in these circumstances."

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Thu, 7 Aug 2003 10:11:59 -0700

I'm OK with your new wording.

> Sent: Thursday, August 07, 2003 08:10
> [JRE] I agree that if there is a priori knowledge that 
> in-band tones and announcements will not be used, then what 
> you propose is reasonable. I am rather doubtful that the 
> gateway will have sufficient knowledge to determine this. The 
> 4th and 5th paragraphs of 8.3.3 mandate the connection of 
> media streams if relevant QSIG progress indicators are 
> present in a PROGRESS or ALERTING message. The presence of 
> these progress indicators is outside the control of the 
> gateway. So how can the gateway have a priori knowledge that 
> [FA]I'm talking about the gateway RECEIVING the SETUP, not 
> the one sending it.
> 
> [JRE]You referred originally to 8.3.1, which deals with 
> receiving INVITE / sending SETUP, not receiving SETUP. From 
> the rest of your remarks below I assume you really do mean 
> 8.3.1 and the gateway receiving the INVITE / sending the SETUP.
> 
> [FA]The case I am thinking of is then the Gateway is an IP 
> PBX (with SIP on one side, QSIG on the other). If the call 
> terminates on a local phone, it may use out-of-band ringing 
> (our PBXs work that way).
> 
> If we want to be picky about the meaning of  Gateway, and 
> dissociate the gateway from the actual QSIG PBX, then it can 
> still happen. The gateway may decide to map the INVITE to 
> SETUP anyways and forward it to the QSIG PBX. If the PBX 
> responds with the ALERTING indicating out-of-band, everything 
> is fine (which is why I would like this change). If on the 
> other hand, the ALERTING indicates in-band, then the gateway 
> could decide to do as per your procedure and send the 488. 
> But I wouldn't want to mandate 488 everytime the SDP is not 
> in the INVITE, especially since it is a very normal occurence in SIP.
> 
> [JRE] I would not want to send 488 after receiving a QSIG 
> ALERTING or PROGRESS message indicating in-band information, 
> because by then the called user in the QSIG network might 
> already be being alerted and it would not be good practice to 
> cancel the call at this stage.
> 
> [FA]Even for the second case, where the call ultimately 
> terminates on a line with an in-band signalling, I am not 
> convinced at all that the qsig2sip draft should mandate that 
> the call be terminated. To me this should be a design option. 
> An implementer may decide that it prefers to go through with 
> the call, and provide some sort of indication to the user 
> that the call is "progressing" instead of failing the call (I 
> expect that a proper SIP implemenation would do something like that).
> 
> I would prefer that the paragraph does not mandate the 488 as 
> other options are doable, and probably much less drastic than 
> call failure (as an out-of-band progress indication would be).
> 
> [JRE] On reflection I can see some merit in allowing the call 
> to proceed, even though we cannot guarantee that in-band 
> information will be passed to the caller. If the caller is a 
> user of a SIP device of some sort, even if we pass in-band 
> information back through the SIP network, there is no 
> guarantee that the SIP device will play it to the user. On 
> the other hand, if there is another legacy network on the 
> originating side of the SIP network, it will of course be 
> able to pass in-band information and the SIP network (using 
> unreliable provisional responses) would be the sole cause of 
> failure to pass in-band information end-to-end. In the case 
> of another QSIG network we have mandated support for 100rel 
> (see 8.2.1.1) anyway. So on balance I think I could agree to 
> relax the rules concerning a 488. I propose making it a 
> SHOULD and including the text: "A gateway that has a priori 
> knowledge that essential in-band information will not need to 
> be sent before answer can choose to proceed with the call in 
> these circumstances."
>