Subject: [SIP] Overlap call setup

From: "Joshua Moloney" <[email-masked]>
Date: Wed, 31 Jan 2001 10:49:33 -0000

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: "Keith Robinson" <[email-masked]>
Date: Wed, 31 Jan 2001 16:34:08 +0000

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,

Regards,

Josh Moloney

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 31 Jan 2001 13:31:11 -0500

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