Subject: Re: [SIP] Overlap call setup

From: Taichi Fu <[email-masked]>
Date: Wed, 07 Feb 2001 02:07:55 -0800

Hi, Gonzalo,

Some comments on three points in discussion.

(1)
>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.

One potential issue of this is 183 without SDP can also be interpreted as PSTN gateway (and the media gateway it associates with) needs to play (local) ringback for a SIP to PSTN call toward PSTN side phone for the cases the ringback cannot come from the remote SIP phone.

This can be resolved using a different Reason Phrase as Keith already indicated or another status code (186). To me it is better if a SIP status code always has unique semantics.

(2) 
>Why would you want to limit a call to one call leg??
If I understand correctly, the issue of multiple call legs appear becauses of definition of call leg. In the case of multiple INVITE with different To headers with accumulated digits (as your sip-isup draft suggested), if we relax that definition slightly: two messages belong to the same call leg if the number in one To header is a prefix of the number in another and the other conditions of the definition are met. To limit its impact, we can allow this change only on a SIP device (proxy) that interfaces with a PSTN gateway if possible (for pure SIP networks, the rfc definition is still followed). This way CSeq is useful.

I agree to have multiple call legs is fine in theory, but it is kind of against intuition to me and it might add some implementaion overhead too.

(3) INFO or To header for subsequent digits
I agree with your thoughts on using TO instead of INFO. However one obvious advantage of INFO is the saving of one message (ACK).
 
Regards,
Taichi

>Tue, 06 Feb 2001 23:11:50 +0200 
>Gonzalo Camarillo wrote:
>
>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
>
>
>
>
>
>    Previous message: [SIP] Overlap call setup 
>    Next message: [SIP] Re: Location information 
>    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 
> 

_______________________________________________
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: Wed, 07 Feb 2001 17:28:07 +0200

Hello,

> One potential issue of this is 183 without SDP can also be interpreted as PSTN gateway (and the media gateway it associates with) needs to play (local) ringback for a SIP to PSTN call toward PSTN s…

This is wrong. If local alerting has to be performed the proper 1xx
response is 180 Ringing. This has been pointed out several times in the
mailing list.

> This can be resolved using a different Reason Phrase as Keith already indicated or another status code (186). To me it is better if a SIP status code always has unique semantics.

We discussed this idea also, and finally 183 seems OK for this
(providing a contact header for the gateway handling the call).

> If I understand correctly, the issue of multiple call legs appear becauses of definition of call leg. In the case of multiple INVITE with different To headers with accumulated digits (as your sip-i…

I do not think tha streching teh definition of a call leg for a
particular interworking case is a good idea. I rather let the definition
as it is. We do not need to change it.

> I agree to have multiple call legs is fine in theory, but it is kind of against intuition to me and it might add some implementaion overhead too.

There are scenarios where a single call can have multiple call legs.
Multiple call legs are present in SIP since the beginning. I do not
think we should discuss them now.

> I agree with your thoughts on using TO instead of INFO. However one obvious advantage of INFO is the saving of one message (ACK).

If we take into account all the problems related to the use of INFO, a
message saved is not a big gain.

Regards,

Gonzalo

---

From: Taichi Fu <[email-masked]>
Date: Wed, 07 Feb 2001 13:26:15 -0800

Gonzalo,

One more question and comment inline.

Regards,
Taichi

> response is 180 Ringing. This has been pointed out several times in the

Be a bit more general, is it also possible to play some local
announcement (other than ringing) to PSTN side after received 183
without SDP? If so, how to differentiate? To interpret 183 without SDP
as 'dialing incomplete so no ACM yet' only is a rather strong assertion
and I see no advantage of it over a dedicated response code or reason
phrase.

> think we should discuss them now.

It should be clear from this thread thay it is in the context of overlap
signalling that I am not so in favor of multiple call legs. It is kinds
of artificial. After all, all those To headers convey just one number
and to me semantically to group them into one call leg is cleaner to
understand and to implement. Anyway, it is not a big issue and to have a
general consensus is probably more important than to find the optimal.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Jan 1988 19:13:33 +0200

Hello,

> and I see no advantage of it over a dedicated response code or reason

Early media is being discussed right now, so things might change. Right
now, 183 with no SDP does not imply playing any announcement to the user
other than "Session in progress".

Gonzalo

---

From: Taichi Fu <[email-masked]>
Date: Sat, 10 Feb 2001 10:08:53 -0800

Gonzalo,

Thanks for your explanation.
Taichi 

At 07:13 PM 1/1/88 +0200, Gonzalo Camarillo wrote:
>Early media is being discussed right now, so things might change. 
So I guess we need either a new response code, a special formulated 183 for (local) early media or else. Hope to see a general consensus.

>Right now, 183 with no SDP does not imply playing any announcement to the user
If so hope to see the following statement be added in Section 7.1.5 of rfcbis2 (if it is not already there):
'183 with no SDP must (should ?) not play any announcement (early media) to the user.

Also 'no early media if 183 w/o SDP'  seems not exactly to be the same as 'no ACM if 183 w/o SDP'. But that is only my conjecture.