Subject: Re: [SIP] Overlap call setup

From: "Keith Robinson" <[email-masked]>
Date: Tue, 6 Feb 2001 16:55:39 +0000

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.

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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 06 Feb 2001 23:11:50 +0200

Hello,

Thanks for the pointer. Answers inline:

> ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 16:42

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.

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

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

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

See comments above about this type of source routing.

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

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.

> INVITEs get to the appropriate UAS.

YES.

> Sect 7.2.3 indicates that a node receiving a
> 183 prior to generating

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.

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

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