Andreas Byström wrote:
> Thanks for your response Paul!
>
> If I want to verify that a specific session is still up, the OPTIONS request
> is not enough, right? If I use options each 3rd minute, and the UA restarts
> in these 3 minutes, there is no way for the B2BUA to know if a specific call
> is up or not? So I guess I'm stuck with using either OPTIONS or reInvite...
Andreas - this depends a bit on what you mean by "session".
If you mean "dialog", then sending the OPTIONS request within the dialog
will achieve what you want.
If you mean the "invite dialog usage", then the OPTIONS won't do it. In
that case you are stuck using reINVITE or UPDATE.
If you are only interested in whetehr the UAS is functional, then an
OPTIONS to the contact from the dialog, send out of dialog, should do.
(But that gets related to GRUU.)
> Has anyone got a clue about how wide support for OPTIONS reqiest is
> supported? Almost every UA?
I think so.
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
