Subject: [Sipping] AW: AW: Optional optimisation for SIP overlap to ISUP en-bloc (Ov erla p WG LC)

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 14 Jun 2002 11:23:15 +0200

Hello Mike
 
Some comments inline
 
Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet am: Donnerstag, 13. Juni 2002 23:17
An: Alexeitsev, D
Cc: [email-masked]; [email-masked]
Betreff: Re: AW: Optional optimisation for SIP overlap to ISUP en-bloc (Overla p WG LC)
In a message dated 6/13/02 4:20:10 AM Eastern Daylight Time, [email-masked] writes: 
2. If the egress gateway determines that the number contained in the INVITE is not a complete number and the PSTN it is connected to does not support overlap, the egress gateway SHOULD respond with a 484, Address Incomplete. If it receives a subsequent INVITE, it treats it as if it were the first one.   

[DA] I think it will be good to recommend the Ingress GW to keep the same Call-ID and From-tag for the new INVITEs even if they are belonging to the different SIP call setups in this case. It will be useful for accounting, provisioning and so on. 

[MAP] Absolutely, keeping the same Call-ID and From-tag (and whatever else associates the new INVITE with the previous) is an important part of the solution. I'm not sure what you mean by "even if they are belonging to the different SIP call setups". Could there be a case in which the ingress GW sends an INVITE with some of the digits, and then, when it gets more digits, it decides to release the first call attempt and start a new one? If so, this would be a "different SIP call setup". But I see this as not being needed, since the ingress GW should always wait for the minimum number of digits before sending the first INVITE, meaning that the destination has already been determined.  
 
[DA] I was talking about the SIP overlap to ISUP en bloc case where the SIP call setup attempts with incomplete number will be released by the egress GW with 484 response, thus technically ending the SIP call setup. In this case after the Ingress GW receives the SAMs it will send new INVITEs that actually will not have to have any correlation with the released previous ones, but for the provisioning, accounting it will be very important to correlate them as belonging to one ISUP call setup attempt.

3. If the egress gateway determines that the number contained in the INVITE is not a complete number or it can not determine its completeness and the PSTN it is connected to supports overlap, the egress gateway SHOULD generate an IAM following the procedures described in [3] containing the digits received in the INVITE. It MUST NOT send any response to this INVITE. 

[DA] Do you mean any final, provisional or both? 

[MAP] Yes, I believe that is what the draft says for this case, but there is some confusion on this. Part of the problem is that any response sent would likely get to the ingress gateway after the ingress GW has already sent another INVITE. The point I'm making is that the ingress GW should know what it is doing and not need any response. 
 
[DA] I believe that if the ingress GW gets the final response it can not just know what it is doing and shall follow the SIP protocol rules. If you are talking about call handling - that is exactly the point.
 
[MAP]   484 is used in case 2 above as a "final" response, since there is a mis-match between ingress and egress. Case 3 doesn't need any provisional response since the ingress GW is doing just fine and the 490 response (for one INVITE) occurs when the next INVITE arrives.   Even here, the response is there only to satisfy the protocol (terminate a transaction?). The call handling logic . 
 
[DA] Yes, the call handling doesn't need it, it is just the way SIP protocol works with overlap.

[MAP] I'm currious, do you know if overlap is an important capability within Germany? If so, do you see it as being required because of the variable length numbers or because of slow signaling systems at the destination? 
 
[DA] It is because of the open numbering plan in the ISDN/PSTN and it is absolutely required.

_______________________________________________
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