Subject: [Sip] SIPit 21: Question about offer answer

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Nov 2007 15:53:09 -0600

Here's one I don't know the answer to off the top of my head:

Right now, we can offer the same SDP we've offered before (not  
changing the o line). This is used, for instance, with session-timer  
when we want to use
a re-INVITE but don't really want to change the session.

However, the specs allow the answer to such a non-changed offer to be  
different from the previous answer.

What was the motivation? There were a few attendees at SIPit 21  
arguing that implementation would be simpler for them if this answer  
had to be a copy of the previous answer as well. Did we allow it to  
change just because we could? Or is there an application I'm not  
remembering that really needs this flexibility? If not, would we be  
willing to add this restriction?

RjS

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2007 20:17:15 -0500

Robert Sparks wrote:
> Right now, we can offer the same SDP we've offered before (not changing 
> the o line). This is used, for instance, with session-timer when we want 
> to use
> What was the motivation? There were a few attendees at SIPit 21 arguing 
> that implementation would be simpler for them if this answer had to be a 
> copy of the previous answer as well. Did we allow it to change just 
> because we could? Or is there an application I'm not remembering that 
> really needs this flexibility? If not, would we be willing to add this 
> restriction?

3PCC is a source of an almost unlimited set of corner cases. :-)

A 3pcc controller doing a transfer may well send an offerless invite to 
one UA and then send the offer it gets back to an entirely different UA 
than had been in the session before. So of course the answer will be 
entirely different.

There are probably other reasons, but I need more time to think of them.

	Thanks,
	Paul

---

From: [email-masked]
Date: Mon, 19 Nov 2007 20:38:48 -0500

From: Paul Kyzivat <[email-masked]>

Hmmm, "my" music-on-hold proposal does that, too.

Dale

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Nov 2007 08:15:09 +0100

Hi,

What if the offerer is not "prepared" to receive an updated answer (it
only included the "offer" because it had to)? How can it "reject" the
answer? 

I personally think that an unchanged o- line in the offer should not
allow the answer to change.

One could of course change the o- line in the offer - even if the offer
itself hasn't changed - and that would then allow the answer to be
changed.

Just some thinking...

Regards,

Christer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 20. marraskuuta 2007 3:39
> To: [email-masked]
> Subject: Re: [Sip] SIPit 21: Question about offer answer
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2007 09:21:33 -0500

> only included the "offer" because it had to)? How can it "reject" the

It can't. At best it can make a counter offer after the fact, or 
terminate the call after the fact.

But that clearly isn't a good policy. You should design your UA so that 
this isn't an issue. When you make an offer you must always be prepared 
for the answer be anything that is compatible with the offer.

> itself hasn't changed - and that would then allow the answer to be

Personally I think the o-line changing or not is just an extra 
complication that should never have been there as a factor. Whether the 
o-line changes or not isn't what matters. What matters is whether the 
rest of the SDP changes. At best the o-line is a hint about whether the 
rest changed or not, and simply introduces the potential error case 
where the SDP doesn't agree with what the o-line is hinting. (So what 
should you do if the o-line is unchanged but the SDP is changed?)

But as things are written, you are expected to make the o-line the same 
if the rest of the SDP is the same. The o-line in the offer has 
*nothing* to do with what is in the answer.

	Paul

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 21 Nov 2007 15:09:32 +1100

My view on this is that if you don't want to send SDP but you have to when
sending a re-INVITE, then send UPDATE without the SDP. Can we update session
timer to say that?

Hisham

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 21 Nov 2007 09:02:16 -0500

There is backward compatibility issues with it. There are some old UAs
which do not support UPDATE. But if they do,  and it can be figured out
from Allow header, then I agree that UPDATE is better than re-Invite for
session refresh.
 
Sanjay

________________________________

	From: Hisham Khartabil [mailto:[email-masked]] 
	Sent: Tuesday, November 20, 2007 11:10 PM
	To: Paul Kyzivat (pkyzivat)
	Cc: [email-masked]; Christer Holmberg
	Subject: Re: [Sip] SIPit 21: Question about offer answer

	My view on this is that if you don't want to send SDP but you
have to when sending a re-INVITE, then send UPDATE without the SDP. Can
we update session timer to say that?
	 
	Hisham

		> only included the "offer" because it had to)? How can
it "reject" the
		
		It can't. At best it can make a counter offer after the
fact, or
		terminate the call after the fact. 
		
		But that clearly isn't a good policy. You should design
your UA so that
		this isn't an issue. When you make an offer you must
always be prepared
		for the answer be anything that is compatible with the
offer. 
		
		> itself hasn't changed - and that would then allow the
answer to be 
		
		Personally I think the o-line changing or not is just an
extra
		complication that should never have been there as a
factor. Whether the
		o-line changes or not isn't what matters. What matters
is whether the 
		rest of the SDP changes. At best the o-line is a hint
about whether the
		rest changed or not, and simply introduces the potential
error case
		where the SDP doesn't agree with what the o-line is
hinting. (So what 
		should you do if the o-line is unchanged but the SDP is
changed?)
		
		But as things are written, you are expected to make the
o-line the same
		if the rest of the SDP is the same. The o-line in the
offer has
		*nothing* to do with what is in the answer. 
		
		       Paul
		
		>>    A 3pcc controller doing a transfer may well send
an
		>> offerless invite to 
		>>    one UA and then send the offer it gets back to an
entirely
		>> different UA
		>>    than had been in the session before. So of course
the
		>> answer will be
		>> Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
		> Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip

		_______________________________________________ 
		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: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Nov 2007 15:13:12 +0100

Hi,
 
RFC4028 already allows the usage of UPDATE, so I guess the issue is more
to make sure one doesn't send an unchanged offer unless he is ready to
receive a modified answer.
 
If I remember correctly the initial idea the session-timer was, that is
some entity in the path had lost state of the call, the re-INVITE would
re-initiate the call.
 
However, that is not the case anymore. As far as I understand, the
session-timer is only used to indicate that the session is still active,
and if no re-INVITE/UPDATE is received the session can be released.
 
You could do this even with...... INFO ;)
 
Regards,
 
Christer

	From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
	Sent: 21. marraskuuta 2007 16:02
	To: Hisham Khartabil; Paul Kyzivat (pkyzivat)
	Cc: [email-masked]; Christer Holmberg
	Subject: RE: [Sip] SIPit 21: Question about offer answer

	There is backward compatibility issues with it. There are some
old UAs which do not support UPDATE. But if they do,  and it can be
figured out from Allow header, then I agree that UPDATE is better than
re-Invite for session refresh.
	 
	Sanjay

		From: Hisham Khartabil
[mailto:[email-masked]] 

		My view on this is that if you don't want to send SDP
but you have to when sending a re-INVITE, then send UPDATE without the
SDP. Can we update session timer to say that?
		 
		Hisham

			> only included the "offer" because it had to)?
How can it "reject" the
			
			It can't. At best it can make a counter offer
after the fact, or
			terminate the call after the fact. 
			
			But that clearly isn't a good policy. You should
design your UA so that
			this isn't an issue. When you make an offer you
must always be prepared
			for the answer be anything that is compatible
with the offer. 
			
			> itself hasn't changed - and that would then
allow the answer to be 
			
			Personally I think the o-line changing or not is
just an extra
			complication that should never have been there
as a factor. Whether the
			o-line changes or not isn't what matters. What
matters is whether the 
			rest of the SDP changes. At best the o-line is a
hint about whether the
			rest changed or not, and simply introduces the
potential error case
			where the SDP doesn't agree with what the o-line
is hinting. (So what 
			should you do if the o-line is unchanged but the
SDP is changed?)
			
			But as things are written, you are expected to
make the o-line the same
			if the rest of the SDP is the same. The o-line
in the offer has
			*nothing* to do with what is in the answer. 
			
			       Paul
			
			>>    A 3pcc controller doing a transfer may
well send an
			>> offerless invite to 
			>>    one UA and then send the offer it gets
back to an entirely
			>> different UA
			>>    than had been in the session before. So of
course the

			Use [email-masked] for
questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Nov 2007 11:22:22 -0500

Hisham Khartabil wrote:
> My view on this is that if you don't want to send SDP but you have to 
> when sending a re-INVITE, then send UPDATE without the SDP. Can we 
> update session timer to say that?

I suppose we could, but you can only do that if both sides support 
UPDATE. Since its optional, those who implement session timer must be 
prepared to do it with reINVITE.

I really don't understand the issue here. If you send a reINVITE with 
unchanged SDP and you get back an answer that is changed, just deal with 
it. Why is this a problem?

	Paul

> Hisham
> 
>  
> On 21/11/2007, *Paul Kyzivat* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     Christer Holmberg wrote:
>      > Hi,
>      >
>      >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>      >> To: [email-masked] <mailto:[email-masked]>
>      >>    From: Paul Kyzivat <[email-masked]
>     <mailto:[email-masked]>>
>      >>
>      >> [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>      >> Use [email-masked] <mailto:[email-masked]> for new
>     developments on the application of sip
>      >>
>      >
>      >
>      > Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>      > Use [email-masked] <mailto:[email-masked]> for new
>     developments on the application of sip
>      >
> 
> 
>     Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>     Use [email-masked] <mailto:[email-masked]> for new developments
>     on the application of sip
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Nov 2007 18:29:38 +0100

Hi,
 
>it. Why is this a problem?

The problem is when you - for whatever reason - can't deal with it.

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 27 Nov 2007 14:43:46 -0500

> However, the specs allow the answer to such a non-changed 
> offer to be different from the previous answer.
> 
> What was the motivation? 

To cause 3PCC headaches if B2BUA refreshing/auditing with re-INVITE. ;)

If I recall correctly, it was mainly to allow for recovery and avoid
exceptions to the rfc3264 rules.