Andreas Byström wrote:
> Paul, I'm trying to find where in the spec (and which spec) I can see that
> it is OK to send an UPDATE without SDP body. Can you help me out? Have to
> convince some collegaues and cant find a good reference :)
Well, I'm not sure you will find anything that comes out in black and
white saying "you MAY send an UPDATE without an offer". I would flip
this, and ask where it says you *can't* send an UPDATE without an offer.
Looking at RFC3311, there are implications all over the place that an
UPDATE may not have an offer. For instance:
in 5.1:
o If the UPDATE is being sent after the completion of the initial
INVITE transaction, it cannot contain an offer if the caller
has generated or received offers in a re-INVITE or UPDATE which
have not been answered.
This strongly implies that UPDATE can be sent in situations where it
cannot contain an offer.
in 5.2:
If an UPDATE is received that contains an offer, ...
This would have been written differently if an update always contains an
offer.
And in RFC4028 (Session Timer) section 7.4 says:
A re-INVITE generated to refresh the session is a normal re-INVITE,
and an UPDATE generated to refresh a session is a normal UPDATE. If
a UAC knows that its peer supports the UPDATE method, it is
RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can
make this determination if it has seen an Allow header field from its
peer with the value 'UPDATE', or through a mid-dialog OPTIONS
request. It is RECOMMENDED that the UPDATE request not contain an
offer [4], but a re-INVITE SHOULD contain one, ...
Is that enough for you?
Paul
> Regards,
> // Andreas
>
>
>>-----Original Message-----
>>From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>>Sent: Monday, March 06, 2006 7:20 PM
>>To: Andreas Byström
>>Cc: [email protected]
>>Subject: Re: [Sip-implementors] Session Timer for B2BUA
>>
>>
>>
>>
>>Andreas Byström wrote:
>>
>>>So Paul if I understand correctly, it is OK to send an
>>
>>UPDATE request
>>
>>>with no SDP in it?
>>
>>Yes. In fact this is one of the ways specified for doing
>>session timer.
>>
>>
>>>What would be the expected response if the UA just
>>
>>continues with the
>>
>>>call? A 200 OK?
>>
>>Yes. If you are happy with the changes (however minimal)
>>proposed in the
>>UPDATE, then it makes sense to accept it with a 200. Its no-change if
>>everything is as before including having no session timer
>>before and not
>>establishing one as part of the update. If there had been a session
>>timer before, then an UPDATE necessarily either cancels the
>>old session
>>timer, or else renegotiates a new expiration for it.
>>
>>
>>>If the UA responds with 4xx, would that imply that the
>>
>>session should
>>
>>>be tearn down?
>>
>>By "session" I think you mean "invite dialog usage". The
>>answer depends
>>on the particular error code. See the recent draft from
>>Robert Sparks:
>>draft-ietf-sipping-dialogusage-01.txt.
>>
>> Paul
>>
>>
>>>Regards,
>>>// Andreas
>>>
>>>-----Original Message-----
>>>From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>>>Sent: Saturday, March 04, 2006 12:28 AM
>>>To: Andreas Byström
>>>Cc: [email protected]
>>>Subject: Re: [Sip-implementors] Session Timer for B2BUA
>>>
>>>
>>>
>>>
>>>Andreas Byström wrote:
>>>
>>>
>>>>Hi all!
>>>>
>>>>I have a question regarding how a B2BUA should handle session timer.
>>>>The current case is that a call between A and B goes via a
>>
>>B2BUA, the
>>
>>>>B2BUA uses session timers to be able to have somewhat
>>
>>secure billing,
>>
>>>
>>>There is no reason for a UA to *request* session timer. If UA
>>>(including
>>>a B2BUA) wants to verify the sip signaling path
>>
>>periodically it is free
>>
>>>to do so without the use of session timer.
>>>
>>>(OTOH, it is good for the UA/B2BUA to *support* session
>>
>>timer, in case
>>
>>>some proxy along the path needs it. But it needn't propose the use.)
>>>
>>>
>>>
>>>>but A and B does
>>>>not support Session Timer. So what will happen is that
>>
>>after time x is
>>
>>>>that B2BUA must refresh the session timer towards B (I consider it
>>>>enough to have session timer on one call leg). The problem
>>
>>is how to
>>
>>>>handle SDP data.
>>>
>>>
>>>If you don't use session timer, then after time x (any x
>>
>>you choose)
>>
>>>you
>>>can send any convenient message to A and/or to B. It
>>
>>doesn't have to be
>>
>>>reINVITE. For instance OPTIONS comes to mind. It will check
>>
>>continuity
>>
>>>just as well as reINVITE without the offer/answer issues.
>>>
>>>OTOH, if you insist on using session timer...
>>>
>>>
>>>
>>>>1) Only reInvite and Update is allowed to be used to refresh session
>>>>timers (as according to RFC4028), right?
>>>
>>>
>>>Yes.
>>>
>>>
>>>
>>>>If B2BUA would use reInvite, if it send a reInvite to B without any
>>>>SDP data, B migth add a SDP offer in the 200 OK response
>>>
>>>
>>>There is no *might*. B MUST include offer in the first reliable
>>>response.
>>>
>>>
>>>
>>>>which means I have to
>>>>have a SDP response in the ACK... and I cant really do this without
>>>>including A... which I dont want to do (cant send the 200
>>
>>OK to A to
>>
>>>>get SDP response since A did not trigger reInvite)
>>>
>>>
>>>You send a reINVITE to A with the offer from B. Wait for the answer
>>>from
>>>A and send that in the ACK to B. This is the standard 3pcc ploy. It
>>>works fine as long as it is only *re*INVITEs and they are responded
>>>promptly. (No alerting for the reinvite.)
>>>
>>>
>>>
>>>>2) Is there some way to send an reInvite, and indicate to
>>
>>the recipent
>>
>>>>(in this case B), that B should not insert a SDP offer in
>>
>>the 200 OK?
>>
>>>
>>>No. The offer is required.
>>>
>>>
>>>
>>>>The other option would be for B2BUA to refreash the session by
>>>>generating an Update to B when timer x triggers.
>>>>3) Is it allowed to send an UPDATE request without a SDP body?
>>>
>>>
>>>Yes. This is ideal for session timers, when they are needed. But it
>>>only
>>>works if the peer supports UPDATE.
>>>
>>>
>>>
>>>>Since there
>>>>is no ACK to 200 OK of a Update I guess it is not valid for
>>
>>B to add a
>>
>>>>SDP offer in 200 OK, which will prevent me from having the same
>>>>problems as in 2)...
>>>
>>>
>>>That is true.
>>>
>>>
>>>
>>>>4) What would be the expected behavior of a UA that
>>
>>receives an update
>>
>>>>without a SDP body? Just to keep the current voice/video session as
>>>>usuall?
>>>
>>>
>>>Yup.
>>>
>>> Paul
>>>
>>>
>>>
>>>>Thanks in advance!
>>>>// Andreas
>>>>_______________________________________________
>>>>Sip-implementors mailing list [email protected]
>>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>
>>>
>>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
