Subject: [Sip] How to distinguish a session refreshing Re-INVITE and a call resu ming Re-INVITE?

From: "Chen Zaifeng,SCNB R&D NNC(BJ)" <[email-masked]>
Date: Mon, 27 Dec 2004 11:23:22 +0800

Dear All:
Suppose that a SIP UA has been held by remote side, and during call hold it receives a Re-INVITE for session refreshing from the same remote entity. 
My question is:  How can the UA distinguish the intention of the Re-INVITE from the viewpoint of spec, as currently it is also waiting for a Re-INVITE for call resume?
Thanks!
Best Regards
Chen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 31 Dec 2004 01:50:49 +0100

If the SDP body of the re-INVITE changes your sendrecv status per RFC 3264 it 
is a re-INVITE for resume (or any other status change), if not it is a 
re-INVITE which refreshes the session only.

BTW: this is more a question for sip-implementors like written in the footer 
of this mail.

Regards
  Nils Ohlmeier

On Monday 27 December 2004 04:23, Chen Zaifeng,SCNB R&D NNC(BJ) wrote:
> Dear All:
> Suppose that a SIP UA has been held by remote side, and during call hold it
> receives a Re-INVITE for session refreshing from the same remote entity. My
> question is:  How can the UA distinguish the intention of the Re-INVITE
> from the viewpoint of spec, as currently it is also waiting for a Re-INVITE
> for call resume? Thanks!
> Best Regards
> Chen

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Dec 2004 22:00:27 -0500

> BTW: this is more a question for sip-implementors like written in the footer 

I don't disagree, but I have a different way of thinking about this.

Session refresh is not something special. If session timer is in use, 
then *every* reinvite and update is a session refresh, incidental to 
whatever else it does.

If you want to do a session refresh, and you don't want to do anything 
else, then you send a reinvite or update that doesn't, from your point 
of view, suggest changing anything. Even then, there remains a 
possibility that changes will be made by the other end. There is nothing 
you can do to prevent that.

Lets consider that case of a call between A and B, where session timer 
is enabled, A is the refresher. At some time B decides to put the call 
on hold, so sends a reinvite with a=sendonly, and A responds with 
a=recvonly. (Incidentally, this refreshes the session even though A is 
the refresher.)

At some later time, A decides it is time to refresh by sending a 
reinvite. Presumably A didn't *want* to be on hold. So I would expect it 
to send an offer with a=sendrecv. If B still wants to be on hold, it 
will respond with a=sendonly.

	Paul

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 31 Dec 2004 04:17:27 +0100

On Friday 31 December 2004 04:00, Paul Kyzivat wrote:
> Nils Ohlmeier wrote:
> > If the SDP body of the re-INVITE changes your sendrecv status per RFC
> > 3264 it is a re-INVITE for resume (or any other status change), if not it
> > is a re-INVITE which refreshes the session only.
> >
> > BTW: this is more a question for sip-implementors like written in the
> > footer of this mail.
>

Ok, ok, (as usual ;) I forgot to mention, that also the re-INVITE which 
changes the sendrecv status refreshes the session.
So basically every re-INVITE is a session refresher. And if the SDP changes 
the sendrecv status it also a resume. (The resume is a subset of the session 
refresher.)

Regards
  Nils Ohlmeier