Subject: [Sipping] Comments on Overlap-04

From: [email-masked]
Date: Wed, 19 Feb 2003 22:41:05 EST

Comments on draft-ietf-sipping-overlap-04:

General:

The ability of one call to result in multiple IAMs being sent into the PSTN 
continues to be a serious problem for overlap which must be solved.

Section 3.1:

All references to one number being a "prefix" of another should be deleted. 
This text indicates that overlap can not be used where this "prefix" 
situation can occur, however, one of the purposes of overlap is to handle the 
situation in which there are varying lengths of numbers in some destination 
area, something that would naturally exist if one number really could be a 
"prefix" of another. This creates a major contradiction. However, there is 
still no identified case in the world-wide numbering plan in which one number 
is a "prefix" of another. If there were, overlap signaling to get to it would 
certainly be allowed just as it would be in the existing PSTN. If one 
believes that this "prefix" situation really exists, then the overlap 
procedures defined in this draft must correctly support it.

Section 3.3 contains the statement:

   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.

This continues to be a problem, since it is not always the case. If the 
originator dialed more digits than were needed when overlap was being used, 
the media stream corresponding to the response with the fewer digits would be 
the one to use. The PSTN had no problem with this. SIP is going to have to 
figure out a way to correctly handle it.

Section 3.5 contains the statement:

   If the gateway is attached to the PSTN in an area where en-bloc
   signalling is used, a REL for the previous IAM and a new IAM should
   be generated.

This causes confusion since all areas would allow en-bloc, although some do 
not allow overlap, for example, an area where US SS#7 according to T1.113 is 
used. In those areas, since overlap is not allowed, the gateway or switch 
which provides interworking into that non-overlap area must perform the 
overlap to en-bloc procedures (by time outs, detecting enough digits, etc.) 
There can not be a "previous IAM" sent to the PSTN, since the gateway or 
switch would not have sent one until it knew it had enough digits to send a 
complete IAM, after which it would stop accepting or sending any further 
digits.

This paragraph should be worded as:

   If the gateway is attached to the PSTN in an area where overlap signalling
   is not allowed, it must not send an IAM until it determines that it has 
   received the full number in one or more INVITEs, using a process similar 
to  
   that described in Section 2. It must not send SAMs or additional IAMs after
   that one IAM.

Mike Pierce

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 24 Feb 2003 14:23:13 -0500

Some responses below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 19, 2003 7:41 PM
To: [email-masked]
Subject: [Sipping] Comments on Overlap-04

General: 

<JFP> This concern has been the subject of whole libraries of previous mail;
I think we need to agree to disagree on this point. As we've said in the
past, the draft allows this condition to arise only if operators choose to
configure their networks in a fashion that allows it. </JFP> 

Section 3.1: 

All references to one number being a "prefix" of another should be deleted.
This text indicates that overlap can not be used where this "prefix"
situation can occur, however, one of the purposes of overlap is to handle
the situation in which there are varying lengths of numbers in some
destination area, something that would naturally exist if one number really
could be a "prefix" of another. This creates a major contradiction.  
 
<JFP> Not necessarily a contradiction, actually. There are varying lengths
of numbers in some numbering plans. That does not entail, however, that one
number can necessarily be a prefix of another. The numbers +9990123 and
+99912345 could exist in the same numbering plan without creating any
problems for overlap signaling. The concern is if the numbers +9990123 and
+99901234 were to exist in the same numbering plan.    
 
 However, there is still no identified case in the world-wide numbering plan
in which one number is a "prefix" of another. If there were, overlap
signaling to get to it would certainly be allowed just as it would be in the
existing PSTN. If one believes that this "prefix" situation really exists,
then the overlap procedures defined in this draft must correctly support it.

<JFP> We can't necessarily verify that it's the case, but people keep
telling us that this happens in practice in the PSTN. As usual, it is tough
to provide a counter-existence proof. I think we still need this text.
</JFP>

This continues to be a problem, since it is not always the case. If the
originator dialed more digits than were needed when overlap was being used,
the media stream corresponding to the response with the fewer digits would
be the one to use. The PSTN had no problem with this. SIP is going to have
to figure out a way to correctly handle it. 
 
<JFP> Our text satisfies particular early-media concerns, and is valid, in
my opinion. If fewer digits than the minimum length of a number in the
numbering plan are dialed, a gateway could still attempt to pass backwards
media to the UAC in order to provide early media data. The behavior that
occurs when more digits are dialed than necessary is, no doubt, specific to
different nationalities, but it seems reasonable to assume that superfluous
digits will be discarded. No one, to date, has asserted anything to the
contrary anyway. </JFP>

 
<JFP> First of all, if you send an incomplete number into an en-bloc
signaling network, that are ISUP failure responses (REL with cause 28) that
will be sent in response. Our text identifies what one should do if the call
has not already been rejected. Gateway very well might be stupid enough to
send incomplete addresses into a network that cannot accept them, and it
seems dangerous to assume otherwise. </JFP>

  is not allowed, it must not send an IAM until it determines that it has 
  received the full number in one or more INVITEs, using a process similar
to   
  that described in Section 2. It must not send SAMs or additional IAMs
after 
  that one IAM. 

Mike Pierce

---

From: [email-masked]
Date: Thu, 27 Feb 2003 10:38:07 EST

In a message dated 2/24/2003 2:23:44 PM Eastern Standard Time, 
[email-masked] writes:

> [MIke's] Comments on draft-ietf-sipping-overlap-04: 
> 
> General: 
> 
> <JFP> This concern has been the subject of whole libraries of previous 
> mail; I think we need to agree to disagree on this point. As we've said in 
> the past, the draft allows this condition to arise only if operators choose 
> to configure their networks in a fashion that allows it. </JFP>

<MP>Yes, that's why I didn't go into detail. We'll just agree that we 
disagree on this and will never convince the other.</MP>

> <MP>However, there is still no identified case in the world-wide numbering 
> plan in which one number is a "prefix" of another. If there were, overlap 
> signaling to get to it would certainly be allowed just as it would be in 
> the existing PSTN. If one believes that this "prefix" situation really 
> exists, then the overlap procedures defined in this draft must correctly 
> support it. </MP}
>  
> to provide a counter-existence proof. I think we still need this text. </JFP
> >

<MP> One doesn't have to come up with a "counter-existence proof" for 
unsubstantiated claims. But anyone who claims that this situation exists 
should be able to come up with an existence proof. However, my point is, if 
you believe this situation exists, and the text of the draft says it does, 
then the overlap procedures must handle it properly. They can not say that 
overlap can't be used in this case. Note that any gateway trying to decide 
not to use overlap would be unaware that this situation exists.</MP>

> digits will be discarded. No one, to date, has asserted anything to the 

<MP>Yes, superfluous digits are discarded. In the overlap case, they are 
discarded by the destination exchange that doesn't need them. Any previous 
exchange or gateway would not know they were superfluous. It would give 
"precedence" to the wrong call setup (with more digits) and release the 
desired one, which the called party has actually answered. I don't think this 
issue is related to "early media".</MP>

> not allow overlap, for example, an area where US SS#7 according to T1.113 
> is used. In those areas, since overlap is not allowed, the gateway or 
> switch which provides interworking into that non-overlap area must perform 
> the overlap to en-bloc procedures (by time outs, detecting enough digits, 
> etc.) There can not be a "previous IAM" sent to the PSTN, since the gateway 
> or switch would not have sent one until it knew it had enough digits to 
> send a complete IAM, after which it would stop accepting or sending any 
> further digits. 
>  
> will be sent in response. Our text identifies what one should do if the 
> call has not already been rejected. Gateway very well might be stupid 
> enough to send incomplete addresses into a network that cannot accept them, 
> and it seems dangerous to assume otherwise. </JFP>
> 

>   that described in Section 2. It must not send SAMs or additional IAMs 

<MP>My comment stands.</MP>