Subject: Re: [Sip] draft-ietf-sip-overlap-01

From: [email-masked]
Date: Thu, 6 Dec 2001 15:37:07 EST

In a message dated 12/5/01 7:10:38 PM Eastern Standard Time, 
[email-masked] writes:

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

The comment was regarding the apparently valid case in which a gateway sends 
multiple INVITEs containing different numbers of digits. It could get a 200 
OK for multiple of them. For example, the distant telephone number is 
12345678 but the originator dials 123456789. As in today's network, both will 
result in a call setup attempt, since the destination simply throws the extra 
"9" away. (If the destination has call forwarding or a hunt group, etc, both 
will in fact result in a successful call setup and ringing.)

As noted in Jonathan's recent e-mail, the 200 OK responses could in fact 
occur in either order. Yes, the gateway could keep track of all INVITEs it 
sent, and it might know how to associate responses with each INVITE, but it 
would not know which was the "better" one to keep. It can't simply decide 
that more digits is better. If it does in the case described above, it will 
likely keep the call that resulted in call forwarding and release the one 
that did not.

The simple solution is to not support overlap signaling within the SIP 
environment. (Note that it was decided to not support it in the US version of 
SS#7.)

Mike Pierce

_______________________________________________
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