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
