Subject: Re: [SIP] Overlap call setup

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

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

                                                              

 To:      Keith Robinson/MAIN/MC1@MCMAIN                      
                                                              
 cc:      [email-masked],                  
          [email-masked],                        
          [email-masked], [email-masked], 
          [email-masked]                             

 Subject: Re: [SIP] Overlap call setup                        

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

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
> Record-Route does not make sense in any non-200 response.

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

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

> (Lots of
> 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
> ("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.

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
> send on any subsequent digits and overlap sending would fail.

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
> suggested by J. Rosenberg
> 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
> 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
>
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML

--
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: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Jan 1988 19:50:11 +0200

Hello,

> Thats why I suggested a solution that would not rely on source routing.

I answer to this in my previous mail. I do not think that the proxy is
going to apply a different policy (proxies that the request will
traverse) when more digits are received.
If an INVITE to +1234 has to go thru proxy A, another INVITE to +12345
will have to traverse proxy A also. Thus, the Route will not change from
one request to the other.

Anyway, if a network is not performing load balancing between gateways
it can ignore the record-route. Its only purpose is to avoid multiples
INVITEs to arrive to different egrees gateways. If this happended,
multiples IAM would be generated rather than a IAM and several SAMs.

> a 484 (or possibly 404) and so generate a new call attempt.

Excantly. Thus, in this situation you would be using the multiple call
legs approach. That is a bid advantage. It works with gateways and with
vanilla SIP UAs. INFO does not.

> Also, is it
> its digits in 'overlap mode' anyway ?

I hope that the only SIP UAs that send digits in overlap mode are the
gateways towards the PSTN.

> Clarification of when to generate the ACM, along the lines of your posting,

Yes, I will do it.

Best regards,

Gonzalo