Subject: Re: Questions.1

From: Scott Petrack <[email-masked]>
Date: Tue, 31 Aug 1999 09:56:14 -0400 (EDT)

(my) answers embedded in the text. I, for one, welcome this discussion; it
reinforces for me that using SIP was a wise choice. 

On Mon, 30 Aug 1999, Lawrence Conroy wrote:

> 
> > ...snip...
> >        b. both methods must be supported anyway: In SIP, you may
> >issue new requests with an old call-id, and we have a requirement to
> >enable third-party monitoring, which implies a requirement to have new SIP
> >call-legs to refer to an ongoing PSTN call.
> )
> 
> Um... This Is PINT, not SIP. The reactions a node may get in practice may
> be different, IMHO.

I said "you may issue new requests with an old call-id...." I didn't say
that the server has to respond positively. How the server responds depends
on a lot of things, in SIP and in PINT. If the request can not be
serviced, a server can respond '606 Not Acceptable'. We have written
explicitly into the draft that there are times when a PSTN phone call
cannot be ended, and so even a BYE can be responded to by 606 Not
Acceptable. 

One point I have been trying to make is that while of course certain
requests cannot be met, and must be responded to with a 606 response, I
would find it sad if a server gave this response to a request for the sole
reason that it didn't like the Call-ID used. Such a server is not a very
good server, it seems to me. "I could have let you monitor that call if
you had asked me in this other manner, but the request you sent, whose
meaning is unambiguous and clear, is unacceptable to me until you send
me a new call-id." 
I myself give an analogous response to my daughter when she doesn't say
'please,' but in a more formal relationship if the meaning is perfectly
clear I feel decent manners compels me to do the best I can. 

> I do have a question for clarification on what happens if you "issue new
> requests with an old call-id". Comments gratefully received.
> --------
> In PINT, if a PINT Client sends a BYE message with a (CallID, To and From)
> tuple that matches a prior Invitation, then this may be rejected by the
> recipient Gateway. This is because it may not be possible to cancel a
> service request after it has been submitted to the IN/GSTN for processing.
> 

Agreed.

> Also note that, in PINT, it may not be acceptable to receive a new INVITE
> for the same CallID; the service request may have been submitted to the
> IN/GSTN, in which case it may not be possible to change the request. Thus,
> although SIP allows a Re-INVITE to change the parameters of a session, this
> may not be practical with PINT.

It is perfectly practical with PINT, it just might be a problem for your
implementation (which is perfectly reasonable).

"The same call-id" is nothing more than a syntactic device. It
simply is a "compressed" form of the session description. If you truly
mean that the new INVITE would have been accepted if it had used a
different call-ID and the full SDP (but because it used this "compressed"
form - which enables avoiding the parsing of SDP a second time - it was
rejected), I think that you should consider the many ways to improve the
service you are building. Suppose I send an INVITE with an Expires: of 10
minutes (meaning "camp on busy for the next 20 minutes, after that I'm not
interested"), and then later you change your mind and want to shorten the
time or cancel it. 

Whether or not this is a useful service, and whether or not you wish to
support it for 1000 reasons, is of course entirely yours to decide. 
It is entirely reasonable for an implementation to refuse
requests that it cannot fulfill. 

{
To return to the subscribe/notify case we were discussing before, nothing
prevents you from rejecting the request with a 606 Not Acceptable error
and including a Warning like:

Warning: 307 foo.bar.net Use new call-ID and full SDP please

I just find this silly. Your server recognized the call-leg, otherwise
it would have sent a 481 error, but doesn't have the SDP corresponding to
it?

If you return a 606 Not Acceptable because you truly can't change a
parameter, that's fine. But if the change in parameter is re-setting 
Expires: to 0, I believe that you need to be able to support such a
change.
}

> [As an aside, I rather wonder what the effect will be if a "straight" SIP
> Re-INVITE is sent to a SIP VoIP/PSTN Gateway, as there it may not be easy
> to change the PSTN side of a call.]
> 

Well, it depends on what is being changed, I suppose, and what the
capabilities of the gateway are.

> In effect, one can consider such Re-Invitations within SIP as a combination
> of an implicit BYE followed immediately by a new INVITE (using the same
> CallID but a higher CSeq).
> ----
> Question - should PINT Gateways treat a Re-Invite in this way (i.e. they
> have been asked to cancel an earlier service request and to accept a new
> one)?
>
No, I don't think so at all. Normally, a BYE will terminate a call. The
call will hang up, you will hear a click and no more voice, etc. This is
not the same as merely changing the parameters of a session. It is sort of
like saying that a call transfer is a combination of an implicit BYE and
then a new INVITE. The end effect may be "similar", but it might not be
the same. For example, if the call costs 10cents for the first minute and
5 cents for each minute afterwards, the difference might be substantial.

Once again, if you want to implement things in your server this way, that
is entirely your perogative. But this has nothing to do with the semantics
of the messages.
 
> If so, should the Gateway treat the BYE implicit within the Re-Invite in
> the same way as an explicit BYE (i.e. to reject the message if the earlier
> service invocation cannot be cancelled)?

Somehow, I can see that things seem much simpler to me than to you. To
change the parameters of a request are to re-issue the request with the
changed parameters. If your server can't fulfill the request to change, it
sends back a 606 Not Acceptable. 

Whether you respond to a re-issued INVITE the same way as you respond to a
BYE is up to your implementation. 

---------
This message came from the IETF PINT Working Group Mailing List.