Subject: RE: [SIP] Overlap call setup

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 1 Feb 2001 09:08:34 -0500

I see the disconnect here.  You are assuming that the first IAM gets
propagated through the egress gateway, so an ISUP state machine is set into
play.  I think the synthesis of our thinking is this:

(1) The first problem is to receive enough digits so an egress gateway can
be selected.  Until that happens, the digits have to be accumulated into
successive initial INVITE messages.

(2) Once an egress gateway has been selected, call routing is complete as
far as the SIP domain is concerned.  Hence it is legitimate to use the INFO
method to carry subsequent digits.

> -----Original Message-----
> From: Keith Robinson [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 4:05 AM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: [email-masked]; Moloney, Joshua [MDN05:CT07:EXCH]
> Subject: RE: [SIP] Overlap call setup
> 
> 
> 
> 
> If the SIP side of the gateway is retaining state then the 
> UAS side has to know
> that the subsequent
> digits have to be sent to the same call state machine (on the 
> ISUP side) as the
> original digits. If you
> choose a different UAS, and the INVITE containing susequent 
> digits is treated as
> a new call attempt
> by this UAS, how does it know which state machine on the ISUP 
> side to send the
> digits to. I'm thinking
> of a configuration where there exists a farm of UAS for 
> scalability and load
> distribution.
> 
> Originally, I did say that sending 484 and completely 
> forgetting about the call
> would work, I just don't think
> it is the best way; the original state machine on the ISUP 
> side would probably
> time out if it received no
> further digits and a new state machine created by the 
> subsequent INVITE would
> now handle the call.
> 
> In the case of 11.3 in the sip-isup document, then the 
> subsequent INVITEs must
> arrive at the same gateway,
> otherwise unnecessary IAMs are generated. This is pointed out 
> in the text.
> 
> Regards,
> 
> K. Robinson
> 
> 
> 
> 
> 
> 
> 
> "Tom-PT Taylor" <[email-masked]> on 31/01/2001 18:31:11
>                                                               
>                   
>                                                               
>                   
>                                                               
>                   
> 
> 
>                                                               
>                                                               
>                                                               
>  To:      Keith Robinson/MAIN/MC1@MCMAIN                      
>                                                               
>  cc:      [email-masked], "Joshua Moloney"           
>           <[email-masked]>                       
>                                                               
>                                                               
>                                                               
>  Subject: RE: [SIP] Overlap call setup                        
>                                                               
> 
> 
> 
> 
> 
> 
> 
> I think you've made one assumption I might question.  Assuming that
> subsequent INVITEs are being sent, containing all of the digits so far
> collected, so that they are self-contained: why is it 
> necessary that each
> ends up at the same UAS?  When the 484 is sent back, call 
> state should be
> cleared all along the path, even in the SIP-UAC side of the 
> ingress gateway.
> Only the ISUP side of that gateway and, I suppose, the 
> ISUP-SIP interworking
> function, should retain call state.
> 
> > -----Original Message-----
> > From: Keith Robinson [mailto:[email-masked]]
> > Sent: Wednesday, January 31, 2001 11:34 AM
> > To: Moloney, Joshua [MDN05:CT07:EXCH]
> > Cc: [email-masked]
> > Subject: Re: [SIP] Overlap call setup
> >
> >
> >
> >
> > I have recently been trying to get clarification on the
> > implemenation of
> > overlap sending; see attached for the discussion that has 
> taken place
> > so far.
> >
> > Certainly, the mechanism outlined (very sketchily) in
> > RFC2543bis-02 sect 4.2.1
> > is fundamentally flawed. The Request-URI cannot be used to
> > carry extra digits
> > as the Record-Route/Route mechanism would end up 
> overwriting the R-URI
> > and therefore the subsequent digits would be lost.
> >
> > This then leads to the idea of using the TO field as described in
> > sip-isup-00-00.txt;
> > however, I have the following issues with the mechanisms
> > described in this
> > document :
> >
> > As the TO field is different on each subsequent INVITE, then
> > it is a new call
> > leg
> > on an existing call id; RFC2543bis-02 sect. 11.5 does not
> > state what a UAS
> > should make of this. If you follow the logic in 11.5 you get
> > to case (3), but
> > here it only defines the behaviour  if the TO and FROM fields match.
> >
> > The 484 sent backwards kills that call attempt (but not the
> > state for that
> > Call-Id -
> > is this problematic for intermediate proxies ?) so subsequent
> > INVITEs will
> > actually be initial INVITEs. As these INVITEs must get to the
> > same terminating
> > UAS,
> > the originating  UAC will have to create a ROUTE header in an
> > initial INVITE
> > using ,
> > at least the CONTACT address from the 484. This implies the
> > use of source
> > routing, an
> > issue that I don't believe has been fully resolved, and even
> > if it is and
> > becomes part
> > of the base protocol some administrations may be reluctant to
> > admit initial
> > INVITEs
> > which try to circumvent their routing policy, so may reject
> > such INVITEs.
> >
> > Also on the above point, the CONTACT address in the 484 must
> > have the same
> > semantics as that in a 200 response so that a ROUTE header
> > can be built; however
> > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in
> > 4XX responses
> > indicates a location where additional error information can
> > be found. Indeed, in
> > a recent
> > thread entitled Announcements in SIP (401 & 407 Contact) J.
> > Rosenberg believes
> > that
> > Record-Route does not make sense in any non-200 response.
> >
> > I would raise the question of whether the 484 response has
> > any use in overlap
> > sending
> > (certainly in the case of ISUP) at all. If a node receives
> > insufficient digits
> > to decode than it will wait until it receives some more from
> > the preceding node
> > (or end of
> > dialling timers mature). If the preceding node receives
> > subsequent digits and
> > end of dialling
> > has not been detected then it will pass them on. If the 484
> > indicated the
> > minimum number of
> > digits before a decode could take place, then it would be
> > useful in cutting down
> > the number
> > of subseqent messages sent.
> >
> > Indeed, isup-sip-00.txt does cover the mechanism where a 183
> > is sent, and not a
> > 484.
> > The case in point is covered in sect. 11.3 (Example of SIP
> > bridging and overlap
> > signalling);
> > However, I have the following issues with this mechanism:
> >
> > As before relies on source routing.
> >
> > Relies on proxies sending requests on new call legs but
> > existing call-ids to the
> > same
> > downstream server; fine if you administer these proxies, what
> > if you don't ?
> > (Lots of
> > wasted IAMs generated). The mechanism should not send 5
> > (subsequent INVITE)
> > until it has received an acknowledgement (probably not 100)
> > from the first.
> > Alternatively,
> > the Reason-Phrase could detail more specifically the exact
> > progress of the call
> > ("Decoding Address"
> > in this case ?) so that the ACM is not generated unconditionally.
> >
> > Sect. 11.2 encourages gateways "to return a183 Session
> > Progress with a Contact
> > header as soon as they receive an INVITE that they are going
> > to handle and might
> > contain
> > an incomplete number". Presumably this is to allow the UAC to
> > build a ROUTE so
> > that subsequent
> > INVITEs get to the appropriate UAS. Sect 7.2.3 indicates that
> > a node receiving a
> > 183 prior to generating
> > an ACM should generate an ACM. Applied together these rules
> > may cause a prior
> > node to never
> > send on any subsequent digits and overlap sending would fail.
> >
> > I think an approach is required whereby subsequent digits are
> > sent on the same
> > call leg as the
> > initial INVITE; either multiple INVITEs are allowed before
> > 200 OK (already
> > suggested by J. Rosenberg
> > in a different context) , or the INFO method is used. In both
> > cases the TO field
> > will have to remain the
> > same so a new header (or message body type) is required to
> > convey the digits.
> > Also, replace the 484
> > with, say, 18X indicating the minimum number of digits
> > required, perhaps in the
> > Reason-Phrase header.
> >
> > Regards,
> >
> > Keith Robinson.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > "Joshua Moloney" <[email-masked]> on 
> 31/01/2001 10:49:33
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >  To:      [email-masked]
> >
> >  cc:      (bcc: Keith Robinson/MAIN/MC1)
> >
> >
> >
> >  Subject: [SIP] Overlap call setup
> >
> >
> >
> >
> >
> >
> >
> >
> > Greetings,
> >
> > I would like to ask for clarification regarding the 
> implementation of
> > Overlap.
> >
> > I'll begin by referring to paragraph 3, section 6.1.2 of
> > "draft-ietf-isup-sip-00":
> >
> > It is stated that INVITEs sent after the first one
> > (containing extra digits
> > in the 'To' field) are to be treated as new Call-Legs, seeing as the
> > contents of their 'To' headers differ. As such, there is no
> > relationship
> > between their CSeq values.
> >
> > If this is the case, how is it possible to ensure correct
> > digit ordering
> > over an 'unreliable' transport layer like UDP? It would seem
> > logical that
> > the call originator _would_ use contiguous CSeq values, as 
> it would be
> > 'aware' of the fact that the INVITEs are for the same call.
> >
> > I believe that this issue was raised on the SIP list on 19
> > November 1999 by
> > Gonzalo C and Jonathan R. The subject of the messages was
> > "Re: Comments on
> > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of
> > the exchange
> > appeared to be an agreement that CSeq ordering should be employed.
> >
> > However, does this in any way imply that under such 
> circumstances the
> > INVITEs would/should belong to the same Call-Leg? After all,
> > the concept of
> > Overlap does not seem to 'fit in' with the concept behind
> > multiple Call-Legs
> > anyway.
> >
> > If there has been a change in thinking behind the problem,
> > and the latest
> > draft is correct, please could you explain how the ordering
> > problem will be
> > overcome. If not, perhaps the draft needs modification to
> > include these
> > considerations...
> >
> >
> > Regards,
> >
> > Josh Moloney
> >
> >
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 01 Feb 2001 17:09:46 +0200

Hi,

>propagated through the egress gateway, so an ISUP state machine is set
>into play.  I think the synthesis of our thinking is this:
> 
>(1) The first problem is to receive enough digits so an egress gateway
>can be selected.  Until that happens, the digits have to be
>accumulated into successive initial INVITE messages.
> 
>(2) Once an egress gateway has been selected, call routing is complete
>as far as the SIP domain is concerned.  Hence it is legitimate to use
>the INFO method to carry subsequent digits.

Let's assume the following case (hopefully I understood you correctly):

You want to call 12345 on the PSTN side, and in the first INVITE you
only send the first digit, ie.

INVITE [email-masked] 

The GW returns 484, which you ACK.
Then you start sending digits with INFO, ie. 

INFO [email-masked]
more-digit: 23

The GW returns 200, and we may send more INFOs with the rest of the
digits.

Now:

1. How do we know when the call is established? Since we have sent a
final response to the INVITE, we can't send a 200 OK to it.

2. When all the digits have reached the PSTN network, there may be some
early media/alerting messages etc. to be sent, but again - since the GW
has sent a final response to the INVITE, 18x provisional responses can't
be sent.

What do you think about the following: Instead of sending 484, the GW
sends some provisional response (ie. 186 More digits needed). Then we
use INFO messages(s) to provide the rest of the digits, and when all
digits have reached the PSTN side, and the call can be established, we
receive the 200 OK to the INVITE.

Regards,

Christer Holmberg
Ericsson Finland