Subject: RE: [SIP] Overlap call setup

From: "Keith Robinson" <[email-masked]>
Date: Thu, 1 Feb 2001 09:04:46 +0000

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: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 1 Feb 2001 10:36:08 -0500

Your flow is not what I had in mind.  I'll try to make myself clearer by
commenting on your flow.

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 10:10 AM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Keith Robinson; [email-masked]; Moloney, Joshua
> [MDN05:CT07:EXCH]
> Hi,
> >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.
> 
> 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.

[PTT]
No.  The GW NEVER sends 484 because as far as SIP is concerned, call routing
was successful if the call got as far as the GW.  Instead, a proxy returns
484.

> Then you start sending digits with INFO, ie. 
> 
> INFO [email-masked]
> more-digit: 23

[PTT]
Assuming it was a proxy that returned the 484, instead I send another
initial INVITE:

  INVITE [email-masked]
> 
> The GW returns 200, and we may send more INFOs with the rest of the
> digits.

[PTT]
Assume this time there were enough digits to route the call successfully to
a UAS at the GW.  It would return something like a 183 Session Progress to
provide a Contact and establish the call state machine.  The ingress GW
would send additional digits (and possibly encapsulated SAM messages) via
INFO.  The egress GW would start propagating the SAM messages once it had
enough digits to select next hop, but this process would be invisible to the
ingress GW.  The ACM would be sent back in a 180 or 183 interim response as
appropriate, and ANM would come back in the 200 OK.

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

---

From: "Keith Robinson" <[email-masked]>
Date: Thu, 1 Feb 2001 15:59:25 +0000

I agree with both of your statements.

In case (1), I do think it would be useful if the 484 message could indicate the
minimum number
of subsequent digits required, and perhaps the maximum, if the UAS knew such
things. This
would cut down the number of subsequent initial INVITEs.

In case (2), we need to specify the message that goes back to the ingress
gateway
indicating that SIP routing is complete so subsequent digits may be sent in INFO
messages.
I don't think this can be 200 OK as the call is not yet established, so a 1XX
response seems
the most appropriate.

This mechanism differs from that detailed in sip-isup-00.txt, but I do believe
it is more
appropriate.

Regards,
K. Robinson

"Tom-PT Taylor" <[email-masked]> on 01/02/2001 14:08:34

                                                              

                                                              

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.

> Sent: Thursday, February 01, 2001 4:05 AM
> Cc: [email-masked]; Moloney, Joshua [MDN05:CT07:EXCH]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 1 Feb 2001 11:37:05 -0500

A new response code would obviously be unambiguous, and may be necessary.
The problem doesn't arise in the tandem case, since you could have a rule
that ACM is sent back at the ingress side only when an encapsulated ACM is
received from the egress side.  The problem is to figure out appropriate
rules for generating ACM when the termination is to the SIP network.

> Sent: Thursday, February 01, 2001 11:22 AM
> To: Keith Robinson
> Cc: Taylor, Tom-PT [NORSE:B901:EXCH]; 
> [email-masked]; Moloney,
> Joshua [MDN05:CT07:EXCH]
> In this case I still think we could use another provisional response
> (eg. 186, or whatever available...), which would not generate an ISUP
> message, to inform the ingress GW that the call leg has been routed to
> the egress GW, but that additional digits are needed.
> 
> Then, when all the digits are sent, and the call has reached its
> destination on the PSTN side, 183 messages etc can be generated. I am
> not sure a GW would generate 183 messages by itself anyway, unless it
> "triggered" by an ISUP message, but 186 could be triggered by the GW.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> >I think there is a general consensus of opinion here (for 
> case (2)); the
> >question is what informational response to send back to the 
> ingress when an egress has
> >been selected. The problem I have with 183 is that following 
> the text in 7.2.3
> >of sip-isup-00.txt would cause an ACM to be generated at the 
> ingress which I don't think is what we
> >want o do at this point.
> > 
> > Regards,
> > 
> > K. Robinson
> > 
> > "Tom-PT Taylor" <[email-masked]> on 01/02/2001 15:36:08
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  To:      Christer Holmberg
> >           <[email-masked]>
> > 
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN,
> >           [email-masked], "Joshua Moloney"
> --------------------------------------------------------------
> ----------
> >                   Name: att1.htm
> >    att1.htm       Type: Hypertext Markup Language (text/html)
> >               Encoding: base64
> >            Description: Internet HTML
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 2 Feb 2001 09:12:39 -0500

Replies below.

> Sent: Friday, February 02, 2001 1:17 AM
> I see a couple of issues here.
> 
> 1. Even if the UAS returns Accept-Encoding: application/isup, 
> it doesn't
> mean that it is going to send an encapsulated ACM.

[PTT]
Agreed, and that is a nasty point.  It's related to the next one.

> 
> 2. Even if it the UAS GW would send an encapsulated ACM, it 
> is not sure
> that the UAC GW supports ISUP transparency in the first place. It may
> support only ISUP/SIP mapping, for example.

[PTT]
That one is easily solved, in two ways.  First, by hypothesis the UAC GW has
encapsulated the IAM in the initial INVITE.  It can also include an
Accept-Content: header.  In fact, this is essential so that the two ends can
negotiate stuff like ISUP version or the fact that one of them really wants
to propagate Q.931.

So, given that the UAS GW has received an encapsulated IAM, the
Accept-Content: header indicates that it did or did not find the
encapsulated content acceptable.  If it did find it acceptable, how do we
oblige it to keep up its end of the conversation?  I expect the behaviour
has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway
products have to indicate their conformity to that document.

> 
> I think that part of the problem, which is not related only to overlap
> dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA,
> and from a SIP point of view should act like an SIP UA. Maybe 
> it should
> be considered as a SIP node of its own, with GW specific functional
> requirements. The only thing we have now is how to map 
> between ISUP and
> SIP, but that is obviously not enough. ???
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
>

---

From: "Keith Robinson" <[email-masked]>
Date: Wed, 7 Feb 2001 14:19:48 +0000

I forgot to mention that I would not expect vanilla UAs to receive INFO either.
The digits received in the INITIAL would not address any endpoint
supported by the receiving UA so it generate 484/404. The preceding node would
then issue a new call attempt.

Regards,
K .Robinson
---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 07/02/2001 14:14
---------------------------

07/02/2001 14:12
Keith Robinson

To:   Gonzalo Camarillo <[email-masked]> @ MCEXT
cc:   [email-masked]@MCEXT,
      [email-masked]@MCEXT, [email-masked]@MCEXT,
      [email-masked]@MCEXT, [email-masked]@MCEXT

Subject:  Re: [SIP] Overlap call setup  (Document link: Keith Robinson)

Thanks for the reply. A few  points to clarify my thoughts:

On the issue of source routing, I am aware of the discussion that took (is still
taking ?)
place. My concern is not of a technical nature (it will work), it is of an
administrative nature; what
if an administration does not want soucre routing occuring in its domain for
security,
accounting reasons etc. It IS possible for a proxy to determine that an INVITE
is
an initial INVITE; it looks in the TO tag field and finds it blank which means
this MUST
be an initial INVITE as opposed to a subsequent INVITE on a call leg its
forgotten
about. So, a proxy MAY be configured to reject these INVITEs while still being
robust.
Thats why I suggested a solution that would not rely on source routing.

On the issue of vanilla UAs, I would not expect them to generate INFO; I would
expect them to get back
a 484 (or possibly 404) and so generate a new call attempt. Also, is it
realistic that a SIP UA is going to send
its digits in 'overlap mode' anyway ? Is it not more likely that a user is going
to enter the complete
digit string and then ask the UA to send this digit string; the digits either
decode to an endpoint somewhere
or translate to Number Unobtainable ?

The full address (or that received so far) could be carried in the INFO message
in a new header
or a parameter of the TO URL.

Having said this, I take your point about retaining state in a single SIP
message. If it is
mandated that SIP/PSTN gateways only ever signal en-bloc then the overlap
sending
issues are avoided.

Clarification of when to generate the ACM, along the lines of your posting,
would be useful.

I am still concerned that RFC2543bis-02 defines (very sketchily) overlap sending
in a
way that is flawed (using Request-URI). This needs addressing by the SIP
authors.

Regards,
K. Robinson

Gonzalo Camarillo <[email-masked]> on 06/02/2001 21:11:50

                                                              

 cc:      [email-masked],                  
          [email-masked],                        
          [email-masked], [email-masked], 
          [email-masked]                             

Hello,

Thanks for the pointer. Answers inline:

Keith Robinson wrote:
>
> Attached is an earlier posting I raised highlighting my concerns with some of
> the
> mechanisms outlined in the sip-isup document. This is the source of recent
> discussions.
>
> Regards,
>
> K. Robinson
> ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001
16:42
> ---------------------------
>
> 31/01/2001 16:34
> Keith Robinson
>
> To:   "Joshua Moloney" <[email-masked]> @ MCEXT
> cc:   [email-masked]@MCEXT
>
> Subject:  Re: [SIP] Overlap call setup  (Document link: Keith Robinson)
>
> I have recently been trying to get clarification on the implemenation of
> 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
> 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

I do not see here a big problem for a UA. If the UA is a gateway, it
will handle the overlap signalling properly. If it is a pure SIP UA, it
will answer the first INVITE with a 484 (or  "Not found response") and
process the second INVITE properly.

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

There was a big thread about source routing. This kind of source routing
is fine. Current proxies handle it properly.

If a proxy sees an INVITe with a route header, it does not know if it is
the first INVITE or a re-INVITE. Thus, it will work properly.

Even if the proxy stores state and it receives a INVITE (non re-INVITE)
with a route header, it should honor it. Otherwise, the proxy is not
robust. This allows a call stateful proxy to lose state, re-boot and
still be able to route requests properly.

> 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

This contact header that is going to be used is the one present in the
183, not in the 484. This solves the problem of several IAMs al the same
time. If the answer was a 484, no IAM was sent. Thus, the next re-INVITE
with more digits can be very well handled by a different gateway.

>
> I would raise the question of whether the 484 response has any use in overlap
> sending
> (certainly in the case of ISUP) at all.

484 responses are not very useful in this scenario, but they might be
useful in anothers (when a UA can ask the user to type more digits, for
instance).

 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
> 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
> As before relies on source routing.

See comments above about this type of 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 ?

Why would you want to limit a call to one call leg??

> wasted IAMs generated).

Lots of IAMs?????

The situation where more than one (typically two) IAMs are generated is
when the 183 arrived to the ingrees gateway after it sent the first
re-INVITE. This situation is ulikely to happen anyway, because if you
receive subsequent digits so fast (faster than a RTT), you should
implement a timer, and not send LOTS of SAMs anyway.

> The mechanism should not send 5 (subsequent INVITE)
> until it has received an acknowledgement (probably not 100) from the first.

Again a timer configuration problem. You can, and your re-INVITE will
most likelt reach the same egrees gateway as the 1st one... but it might
reach a different one. Thus, the ingrees gateway should be aware of this
and be ready for canceling one of the TWO IAMs sent if this happen.

But again, this situation is not common.

> Alternatively,
> the Reason-Phrase could detail more specifically the exact progress of the
call
> 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.

YES.

> 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

The same way that nodes handling overlap signalling do not release the
call upon reception of a 484, they will not generate ACMs upon reception
of a 183 without SDP and without an ancapsulated ACM... we might want to
add this clarification to the draft.

>
> 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
> in a different context)

Stacking requests is not a good solution in this case. It leads to a lot
of problems that we certainly want to avoid.

> , or the INFO method is used.

If INFO is used any vanilla SIP UA should implement INFO in order tor
receive calls/sessions that use overlap signalling. One of the most
important requirements for overlap signalling in SIP was that a vanilla
SIP UA could handle it.

 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.

Again, we do not want to implement this in vanilla SIP UAs.

Best regards,

Gonzalo

> Also, replace the 484
> with, say, 18X indicating the minimum number of digits required, perhaps in
the
> It is stated that INVITEs sent after the first one (containing extra digits
> contents of their 'To' headers differ. As such, there is no relationship
> 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
> 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
> 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
>
>   ------------------------------------------------------------------------
>                   Name: att1.htm

--
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 8 Feb 2001 17:50:13 -0000

I think this is a good proposal.

I would suggest that the overlap capability is offered in the INVITE and
accepted in the response from the UAS. Otherwise we get problems (e.g. user
on standard SIP client dials under-length number by mistake, PSTN gateway
sends IAM and returns response to UAC, but now the PSTN is waiting for more
digits so we do not get failure until something times out.)

I think the idea of including the number of digits to send in a reponse was
not that the UAS would know the total number of digits needed, but that it
might know 'I need at least 3 more digits to route this'. If it signalled
this information back, the UAC could wait 'till it had got 3 more digits and
we would save two messages, that's all.

Regards,

Mark Watson
Nortel Networks

> Sent: 06 February 2001 07:52
> Cc: Keith Robinson; Taylor, Tom-PT [NORSE:B901:EXCH]; Moloney, Joshua
> [MDN05:CT07:EXCH]
> I had a look through the thread, and I still have one issue.
> 
> I do NOT think that we can assume that the PSTN GW will know how many
> digits are needed to route a call to the PSTN end-user, so I 
> don't think
> we can use provisional responses to "ask" for more digits. Yes, the GW
> may know how many digits it needs to route the call to the next PSTN
> switch, but it doesn't know how many digits that switch needes, etc...
> 
> So, my proposal would be:
> 
> 1. When the INVITE has been routed to the GW UAS, the only 
> response sent
> back is 100. That would, of course, assume that we have to add Contact
> and/or Record-Route headers in the 100 response...
> 
> 2. Then, the UAC would use INFO to send more digits to the UAC, which
> would forward them as SAMs. No, the GW would not "ask" for 
> more digits,
> but does it really have to? If the UAC wants to send more 
> digits, it can
> do so anyway, so...
> 
> 3. THEN, when the GW receives ACM from the PSTN side, it would send a
> 18x provisional response back to the UAC. The UAC would now 
> know that no
> more digits are needed to route the call. Of course, we can get a
> "please enter your code"-message, and be asked to provide digits, but
> that is another issue.
> 
> We should remember that the GW SIP UAS may not even know that 
> the UAC is
> sending more digits, because it may send them in encapsulated ISUP
> messages. In that case, however, the GW SIP UAS will not know 
> it's SAMs,
> so it couldn't make a decission on if to send 186 "Gimme more 
> digits" or
> not...
> 
> 
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Christer Holmberg wrote:
> > 
> > Hi,
> > 
> > Keith Robinson wrote:
> > >
> > >Christer wrote ;
> > >
> > >>Again, we assume that the GWs support ISUP transparency, 
> because if the
> > >>GW only supports ISUP/SIP mapping it will not be able to 
> know if to
> > >>generate an ACM when the 18x is received - even if the GW 
> would be smart
> > >>enough to notice that there is SOME ISUP message in the 
> 180 response.
> > >
> > >Surely, if a GW is mapping ISUP to SIP (and vice versa) 
> then there must >be rules to dictate which SIP messages map 
> to which ISUP messages and in >what context. In fact, aren't 
> these the rules we are debating ? The point >being that even 
> if a GW is ONLY performing SIP/ISUP/SIP mapping
> > >then it STILL MUST know when to genrate the ACM as part of 
> the mapping >function, REGARDLESS of transparency.
> > 
> > Yes, and since it may not be possible to have rules when a 
> 180 should
> > generate a ACM, and when it should not. So, in the case of overlap
> > dialing, when the 18x is only used to "ask" for more digits, my
> > suggestion was to use a specific provisional response code 
> that would
> > not generate an ACM.
> > 
> > Then, when we want an ACM to be generated, no matter if ISUP
> > transparency is supported or not, we would send a 180 Alerting.
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > >
> > > Regards,
> > >
> > > K. Robinson.
> > >
> > > Christer Holmberg <[email-masked]> on 
> 05/02/2001 11:10:49
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  cc:      Tom-PT Taylor <[email-masked]>,
> > >           [email-masked], Joshua Moloney
> > > Again, we assume that the GWs support ISUP transparency, 
> because if the
> > > GW only supports ISUP/SIP mapping it will not be able to 
> know if to
> > > generate an ACM when the 18x is received - even if the GW 
> would be smart
> > > enough to notice that there is SOME ISUP message in the 
> 180 response.
> > >
> > > Personally, I still think that a separate provisional 
> response code
> > > (I've been using 186 as an example) should be used, and 
> any UAC (SIP
> > > phone or PSTN GW) supporting overlap dialing must understand the
> > > response. And, if the UAC knows it has already sent all digits,
> > > receiving a 186 could, for example, cause it to send a 
> CANCEL to the
> > > INVITE, instead of waiting for the ISUP digit timers to expire and
> > > receive a 486 final response.
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > > Keith Robinson wrote:
> > > >
> > > > In the absence of receiving an encapsulated ACM, the ingress
> > > > gateway could generate its own ACM when it receives a 
> 180 Alerting; this
> > > > response must mean it is safe to assume call routing is complete
> > > > and caters for terminations within a SIP network. 
> Thought needs to be
> > > > given to scenarios where a non-200 final response is 
> received, say 486
> > > > Busy, as in these cases 180 Alerting, probably, 
> wouldn't be generated.
> > > >
> > > > Regards,
> > > >
> > > > Keith.
> > > >
> > > > "Tom-PT Taylor" <[email-masked]> on 
> 02/02/2001 14:12:39
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  To:      Christer Holmberg
> > > > > From: Christer Holmberg 
> [mailto:[email-masked]]

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 08 Feb 2001 10:17:08 -0800

I hope we aren't burdening the spec to cover all cases. In the case of two 
trunking gateway/softswitch complexes setting up a call between each other, 
I don't think we need too worry too much about their capabilities. Each 
complex will have all the local understanding they need.

At 09:50 AM 2/8/2001, Mark Watson wrote:

>accepted in the response from the UAS. Otherwise we get problems (e.g. 
>user on standard SIP client dials under-length number by mistake, PSTN 
>gateway sends IAM and returns response to UAC, but now the PSTN is waiting 
>for more digits so we do not get failure until something times out.)
>
>I think the idea of including the number of digits to send in a reponse 
>was not that the UAS would know the total number of digits needed, but 
>that it might know 'I need at least 3 more digits to route this'. If it 
>signalled this information back, the UAC could wait 'till it had got 3 
>more digits and we would save two messages, that's all.
>
>Regards,
>
>Mark Watson
>Nortel Networks
>
> [<mailto:[email-masked]>mailto:[email-masked]] 
>
> [<mailto:[email-masked]>mailto:[email-masked]] 
>

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 28 Feb 2001 12:03:40 -0000

Brian,

You wrote:

> This is still not a reason to do overlap.  Collect all of the digits
> at the UA (or at the gateway) and send them en bloc.  If the 
> terminating
> CPE doesn't have enough to connect, send PSPD treatment.  If it does
> connect.  If the caller doesn't know how many digits to 
> provide, they're
> hosed anyway.
> 

Of course the caller knows how many digits they have. The problem occurs
when they have no way to indicate end-of-dialling to their equipment.

Of course whenever we can we will collect all the digits and go en-bloc from
there, but there remain cases where we simply cannot determine
end-of-dialling.

Our experience has universally been that our customers (service providers)
are not happy with using an inter-digit timer to guess when end-of-dialling
has occured - hence the need for overlap.

Believe me, I do not *want* to support overlap. If there was any way of
avoiding the requirement altogether, I would do so. The unfortunate fact is
that there exist scenarios where overlap is the only way of meeting our
customers requirements.

<snip>

> The only reason this persists in the PSTN is because of the inability
> of terminating equipment to communicate with the network and the
> unwillingness of operators to make up for it with manual provisioning.
> 

Yes, and the fact that the manual provisioning required is, in certain
cases, completely impractical, or even impossible because the operator does
not have the information about number lengths in the PBXs.

> Would you suggest that we overlap from SIP UA to PSTN as well?

If you mean a 'real' UA (rather than a PSTN gateway), then no. I expect that
true SIP UAs will provide a means for the user to indicate end-of-dialling,
or indeed require the user to indicate end-of-dialling.

Regards,

Mark

> >    
> >    > The only place that overlap sending gets used heavily is calls
> >    > into an international gateway switch (which should 
> know how many
> >    > to collect anyway because it has country code tables 
> and can send
> >    > en bloc from there).
> >    
> >    Overlap sending is certainly used on almost all calls in the UK -
> >    admittedly not because it has to, but more because it has always
> >    been done that way.
> 
> Convert from overlap to en bloc at the gateway.  Noone is questioning
> whether a gateway should accept SAMs, just don't propagate 
> them through
> the SIP network.
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>

---

From: "Keith Robinson" <[email-masked]>
Date: Wed, 28 Feb 2001 14:42:36 +0000

Hello,

<snip>

>has occured - hence the need for overlap.

Is this because of concern of the delay in setup ?
As discussion on this thread has shown,supporting overlap within the SIP model,
whether using the
INFO method or multiple INVITEs,  is going to lead to a lot more processing than
just the sending of the extra digits, E.g., waiting for responses, processing
ACKs,
AAA procedures, all of which may  be a bigger drag on setup than
waiting for an EOD timer to mature. Add to that the administrative issues of
making sure
that networks to which yours connects supports the SIP procedures necessary to
make overlap work
the way your network wants it to work and we introduce a lot of extra complexity
for no discernable gain.

Regards,

Keith.

"Mark Watson" <[email-masked]> on 28/02/2001 12:03:40

                                                              

 To:      "[email-masked]'" <[email-masked]>,    
          "Mark Watson" <[email-masked]>          
                                                              
 cc:      [email-masked](bcc: Keith                  
          Robinson/MAIN/MC1)                                  

Brian,

<snip>

Regards,

Mark

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 28 Feb 2001 11:54:00 -0500

Could we bring this issue to a head:

Could we ask that those with strongly held opinions compose an email that
states:
	How you want endpoints with dial pads to address another SIP
endpoint:
		One that is a pure SIP device (a SIP phone)
		One that is a gateway to the PSTN 
	What you want changed, in what RFCs or Drafts
	Why your way is the best way

If we can reach consensus quickly, great.  If not, we will
	Schedule some time at the meeting to discuss
	If necessary, form a design team or other subgroup to work it out

Brian

> Sent: Wednesday, February 28, 2001 9:43 AM
> To: Mark Watson
> Cc: [email-masked]'; Mark Watson; [email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.