Subject: [Sip] (no subject)

From: [email-masked]
Date: Wed, 5 Dec 2001 17:36:10 EST

Following are some comments on draft-ietf-sip-overlap-01

Sorry if these issues have been discussed, but I could not find evidence on 
the list of any recent discussion.

I believe it is the right approach to avoid overlap signaling. It might be 
possible to completely rule it out, given that the areas of the world with 
non-uniform length numbers are being reduced and the originating side can 
have the ability to make more intelligent decisions about how many digits are 
needed in special cases and to apply timeouts only in a few cases.

Section 3.2 (Nit)

2nd paragraph is worded wrong. Should be: "In this case, when T10 expires, an 
INVITE with ..."" 

Section 3.3

In the 3rd paragraph, when a SAM is received, it should be made clear that 
the new INVITE contains all received digits, not just the new ones.

Section 3.4

In the second paragraph, the reference to en-bloc is confusing. En-bloc 
requires that the full number contained in the signaling identify exactly one 
destination, therefore, this situation (one number being a prefix of another) 
could not occur. Overlap, as dialed by the originating party, has this 
problem. For example, in the past, some areas of the US used a dialing plan 
that required a timeout after the 1+7-digit dialing to distinguish between a 
7-digit number and a 1+10-digit number. In fact, this dialing plan is being 
abandoned (or maybe all gone). In any case, it should be the responsibility 
of the initial network element (or the originating IP device) to resolve this 
type ambiguity since it is part of the local dialing plan, not a function of 
the destination numbering. One destination number can never be a "prefix" of 
another. True, a private number could be part of (or same as) a E.164 number, 
but they are always differentiated in other ways.

Suggest the paragraph to be:

"Within some dialing plans in the PSTN, a phone number might be a prefix of 
another one. This situation is not common, but it can certainly occur. Where 
en-bloc signaling is used, this ambiguity must be resolved before the digits 
are placed in the en-bloc signaling. If overlap signaling is used in this 
situation, a different user than the one the caller intended to call might be 
contacted if the timer expires when not intended."

In fact, this issue would seem to invalidate the statement in Section 3.7 
about multiple INVITEs that says that "one of the IAMs has an incomplete 
number". If one number really could be the prefix of another, both IAMs might 
have a complete (but different) number. This better not be possible.

On the other hand, the procedures for multiple INVITEs needs to deal with the 
case in which the earlier INVITE with fewer digits is the right one and the 
latter INVITE simply has extra unneeded digits dialed in error. The 
destination interworking would likely result in receiving a 200 OK for both 
IAMs.

Section 3.6

It isn't clear how the CANCEL of other INVITEs should occur when a 200 OF is 
received. The gateway doesn't really know which ones "did not contain enough 
digits". If it did, it should not have sent them. Also, it needs to CANCEL 
all other INVITEs, not just all "previous" ones.

Section 3.7

The 2nd paragraph addresses why the INVITEs should not be forced to all 
follow the same path. The desire is to allow different "routing" to possibly 
activate different services. However,  as described in Section 3.1, overlap 
always begins by waiting for "the minimum amount of digits to route". Because 
of this, and the apparent minimal use of overlap within SIP, it should be 
acceptable to force all INVITEs containing more than this minimum to follow 
the same route if this simplifies the operation.

Section 4.1

The procedure in the last paragraph of releasing one IAM and sending another 
when each additional digit is received is not a good procedure. If this 
situation is thought to be real, then it should be addressed in a better 
manner. Since the ingress side that sent the INVITE set a timer and expected 
more digits, it should certainly be possible to include that information in 
the INVITE.

It would also be possible for the egress gateway, besides knowing that 
en-bloc signaling is used, to know that it does not have a complete number. 
In fact, it requires this information in order to correctly format the IAM 
for en-bloc. It can not send an IAM with an incomplete number. If not, the 
egress gateway would have to apply the timeout mechanism to determine when 
the number was complete. In any case, there is only one IAM.

Mike Pierce
Artel

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Chiou, Mark" <[email-masked]>
Date: Wed, 5 Dec 2001 18:09:51 -0600

Comment on the below Section 3.6

It should be OK for gateway to keep track all INVITE request messages
due to CSeq number are different as per SIP spec. (Every INVITE request
message shall have different call leg, which is a combination of
Call-ID, CSeq, From and To.) In this scenario, the To content is
different from each other in the INVITE request message, so the 200 OK
response message will match to one and only one call leg. MGC/MG can
cancel the reset of the call legs.

Mark Chiou

Santera Systems Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 05, 2001 4:36 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [Sip] (no subject)

Sorry if these issues have been discussed, but I could not find evidence
on 
the list of any recent discussion.

I believe it is the right approach to avoid overlap signaling. It might
be 
possible to completely rule it out, given that the areas of the world
with 
non-uniform length numbers are being reduced and the originating side
can 
have the ability to make more intelligent decisions about how many
digits are 
needed in special cases and to apply timeouts only in a few cases.

Section 3.2 (Nit)

2nd paragraph is worded wrong. Should be: "In this case, when T10
expires, an 
INVITE with ..."" 

Section 3.3

In the 3rd paragraph, when a SAM is received, it should be made clear
that 
the new INVITE contains all received digits, not just the new ones.

Section 3.4

In the second paragraph, the reference to en-bloc is confusing. En-bloc 
requires that the full number contained in the signaling identify
exactly one 
destination, therefore, this situation (one number being a prefix of
another) 
could not occur. Overlap, as dialed by the originating party, has this 
problem. For example, in the past, some areas of the US used a dialing
plan 
that required a timeout after the 1+7-digit dialing to distinguish
between a 
7-digit number and a 1+10-digit number. In fact, this dialing plan is
being 
abandoned (or maybe all gone). In any case, it should be the
responsibility 
of the initial network element (or the originating IP device) to resolve
this 
type ambiguity since it is part of the local dialing plan, not a
function of 
the destination numbering. One destination number can never be a
"prefix" of 
another. True, a private number could be part of (or same as) a E.164
number, 
but they are always differentiated in other ways.

"Within some dialing plans in the PSTN, a phone number might be a prefix
of 
another one. This situation is not common, but it can certainly occur.
Where 
en-bloc signaling is used, this ambiguity must be resolved before the
digits 
are placed in the en-bloc signaling. If overlap signaling is used in
this 
situation, a different user than the one the caller intended to call
might be 
contacted if the timer expires when not intended."

In fact, this issue would seem to invalidate the statement in Section
3.7 
about multiple INVITEs that says that "one of the IAMs has an incomplete

number". If one number really could be the prefix of another, both IAMs
might 
have a complete (but different) number. This better not be possible.

On the other hand, the procedures for multiple INVITEs needs to deal
with the 
case in which the earlier INVITE with fewer digits is the right one and
the 
latter INVITE simply has extra unneeded digits dialed in error. The 
destination interworking would likely result in receiving a 200 OK for
both 
IAMs.

Section 3.6

It isn't clear how the CANCEL of other INVITEs should occur when a 200
OF is 
received. The gateway doesn't really know which ones "did not contain
enough 
digits". If it did, it should not have sent them. Also, it needs to
CANCEL 
all other INVITEs, not just all "previous" ones.

Section 3.7

The 2nd paragraph addresses why the INVITEs should not be forced to all 
follow the same path. The desire is to allow different "routing" to
possibly 
activate different services. However,  as described in Section 3.1,
overlap 
always begins by waiting for "the minimum amount of digits to route".
Because 
of this, and the apparent minimal use of overlap within SIP, it should
be 
acceptable to force all INVITEs containing more than this minimum to
follow 
the same route if this simplifies the operation.

Section 4.1

The procedure in the last paragraph of releasing one IAM and sending
another 
when each additional digit is received is not a good procedure. If this 
situation is thought to be real, then it should be addressed in a better

manner. Since the ingress side that sent the INVITE set a timer and
expected 
more digits, it should certainly be possible to include that information
in 
the INVITE.

It would also be possible for the egress gateway, besides knowing that 
en-bloc signaling is used, to know that it does not have a complete
number. 
In fact, it requires this information in order to correctly format the
IAM 
for en-bloc. It can not send an IAM with an incomplete number. If not,
the 
egress gateway would have to apply the timeout mechanism to determine
when 
the number was complete. In any case, there is only one IAM.

Mike Pierce
Artel