Subject: [Ecrit] Question about phone BCP

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Nov 2009 09:17:33 +0900

So SIP allows INVITEs with or without an SDP offer. As we all realize,  
this adds ways to use SIP but it allowed both the fast setup when the  
offer was in an INVITE and it allowed SIP to gateway to many other  
protocols where one needed to have an INVITE with no offer.

I have received complaints that Phone BCP currently profiles SIP to a  
subset of it by eliminating the option of an INVITE with no offer. I  
was wondering if there is  a strong reason that this was needed in  
Phone BCP.

Cullen <RAI AD>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 10 Nov 2009 19:21:25 -0500

It's a mistake.  I will fix it.

I can roll a new version tomorrow if that would help.

Brian

On 11/10/09 7:17 PM, "Cullen Jennings" <[email-masked]> wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Nov 2009 08:23:20 +0800

Hi Cullen,

My thoughts on this stuff are that the more ways that you have of doing it the less chance you have of stuff interoperating. I would prefer to see the absolute minimum set that must be supported in phone BCP.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings
> Sent: Wednesday, 11 November 2009 11:18 AM
> To: ECRIT
> Subject: [Ecrit] Question about phone BCP
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Nov 2009 09:29:43 +0900

> It's a mistake.  I will fix it.

Thanks - if you can submit a new version before next monday, that  
would be great.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Nov 2009 23:23:15 -0600

At 06:23 PM 11/10/2009, Winterbottom, James wrote:
>Hi Cullen,
>
>My thoughts on this stuff are that the more ways that you have of 
>doing it the less chance you have of stuff interoperating. I would 
>prefer to see the absolute minimum set that must be supported in phone BCP.

James

"Delayed offer" is a mandatory to implement part of SIP, per RFC 
3261. Are you wanting to officially update RFC 3261 for this 
minimizing optimization?

Further, there are a LOT of products out there that currently do 
Delayed offer, most of this is because customers/operators have 
demanded it be this way (as they believe they have greater control 
with Delayed offer that normal or early offer).

IMO there needs to be a consensus from those operators that this is 
worth bypassing their requirement (for Delayed Offer) for.

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Nov 2009 13:29:35 +0800

Hi James,

Thanks for the lecture.
My belief is that if you want stuff to just work the more simple it is the better. I actually see phone BCP was a SIP profile as a consequence I don't see why the UA can't insist on putting an SDP element in there. Surely RFC3261 says that a SIP proxy has to be able to deal with delayed offer, not that a client MUST send it?

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 11 November 2009 4:23 PM
> To: Winterbottom, James; Cullen Jennings; ECRIT
> Subject: Re: [Ecrit] Question about phone BCP
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Nov 2009 23:54:24 -0600

James

I'm not fan of delayed offer btw, and wish it didn't exist, but it 
been here for years, it's productized by most vendors, and to limit 
applicability in SIP to a subset of how it's been used for years 
would in fact limit widespread adoption of phonebcp, which is not 
your goal, I don't believe.

James

At 11:29 PM 11/10/2009, Winterbottom, James wrote:
>Hi James,
>
>Thanks for the lecture.
>My belief is that if you want stuff to just work the more simple it 
>is the better. I actually see phone BCP was a SIP profile as a 
>consequence I don't see why the UA can't insist on putting an SDP 
>element in there. Surely RFC3261 says that a SIP proxy has to be 
>able to deal with delayed offer, not that a client MUST send it?
>
>Cheers
>James
>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Nov 2009 13:58:20 +0800

Hi James,

My point was more that a proxy kind of doesn't have too much say in this matter, surely it can't reject and INVITE that contains an SDP body can it?

If we want Phone BCP to be adopted then more than likely clients will need to be modified so it could be added in then anyway. Perhaps the change is however bigger than I am presupposing.

Cheers
James

> Sent: Wednesday, 11 November 2009 4:54 PM
> Subject: RE: [Ecrit] Question about phone BCP
> 
> James
> 
> > > >prefer to see the absolute minimum set that must be supported in
> phone
> > > BCP.
> > >
> > > James
> > >
> > > > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > > Of
> > > > > Cullen Jennings

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 11 Nov 2009 00:17:16 -0600

At 11:58 PM 11/10/2009, Winterbottom, James wrote:
>Hi James,
>
>My point was more that a proxy kind of doesn't have too much say in 
>this matter, surely it can't reject and INVITE that contains an SDP 
>body can it?

no, INVITEs don't get rejected just for having an SDP message body.

I think with operators that don't want early/normal offers - if they 
do receive an SDP that wasn't supposed to be there (in the INVITE), 
they delete the SDP along the signaling path (probably as close to 
the UAC as possible) and insert the SDP offer where they normally 
would if there wasn't any SDP message body originally.

>If we want Phone BCP to be adopted then more than likely clients 
>will need to be modified so it could be added in then anyway.

I agree that new code is needed. but...

>Perhaps the change is however bigger than I am presupposing.

...I believe this will limit the applicability to only those 
environments (voice/video topologies?) that are configured to do 
early/normal offer, and not environments that still do delayed 
offer.  Those in the latter camp will likely simply choose to not do 
phonebcp, which is the "widespread deployments" point (below) that I 
believe we don't want to hinder.

James

---

From: Brian Rosen <[email-masked]>
Date: Wed, 11 Nov 2009 10:03:44 -0500

I think the bottom line in this case is simple and meets everyone's needs.
I'll rev phonebcp to remove the SDP requirement.  If the INVITE shows at the
ESRP without an offer, it should be accepted, the PSAP should accept it, and
follow normal offer/answer procedures.  I don't think we need to say that,
we just have to remove the requirement that the INVITE has an offer.

That makes it less "proscriptive" from James W.'s point of view, resolves
Cullens comment, and doesn't change anything from James P's perspective.

It was a mistake, we never intended to rule out delayed offer.

Brian

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Nov 2009 00:10:44 +0900

> It was a mistake, we never intended to rule out delayed offer.

I think this sounds like the right plan to keep moving stuff forward  
quickly. Thanks

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 15 Nov 2009 18:37:37 +0100

In answer to this thread I would note two things (RFC 3261 says):

   A UAS providing an offer in a 2xx (because the INVITE did not contain
   an offer) SHOULD construct the offer as if the UAS were making a
   brand new call, subject to the constraints of sending an offer that
   updates an existing session, as described in [13] in the case of SDP.
   Specifically, this means that it SHOULD include as many media formats
   and media types that the UA is willing to support.  The UAS MUST
   ensure that the session description overlaps with its previous
   session description in media formats, transports, or other parameters
   that require support from the peer.  This is to avoid the need for
   the peer to reject the session description.  If, however, it is
   unacceptable to the UAC, the UAC SHOULD generate an answer with a
   valid session description, and then send a BYE to terminate the
   session.

1)	The above could result in the UAC automatically generating a BYE request on reception of the SDP offer and therefore the emergency call failing. If we are going to allow this behaviour, then we should include a warning of the potential effects.

2)	In this case the PSAP now has to generate the SDP offer. What are our recommendations on what that offer should contain. How do we know it was a voice terminal that generated the call, and how do we cater for the potential that it was a real time text terminal that generated the call, or at least the case where the user wished to use real time text. (So much easier if the user actually indicates what they want). 

regards

Keith 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Winterbottom, James
> Sent: Wednesday, November 11, 2009 5:30 AM
> To: James M. Polk; Cullen Jennings; ECRIT
> My belief is that if you want stuff to just work the more 
> simple it is the better. I actually see phone BCP was a SIP 
> profile as a consequence I don't see why the UA can't insist 
> on putting an SDP element in there. Surely RFC3261 says that 
> a SIP proxy has to be able to deal with delayed offer, not 
> that a client MUST send it?
> 
> Cheers
> James
> 
> 
> > "Delayed offer" is a mandatory to implement part of SIP, 
> per RFC 3261. 
> > Are you wanting to officially update RFC 3261 for this minimizing 
> > optimization?
> > 
> > > > So SIP allows INVITEs with or without an SDP offer. As we all 
> > > > realize, this adds ways to use SIP but it allowed both the fast 
> > > > setup when the offer was in an INVITE and it allowed SIP to 
> > > > gateway to many other protocols where one needed to 
> have an INVITE with no offer.
> > > >
> > > > I have received complaints that Phone BCP currently 
> profiles SIP 
> > > > to a subset of it by eliminating the option of an 
> INVITE with no 
> > > > offer. I was wondering if there is  a strong reason 
> that this was 
> > > > needed in Phone BCP.
> > > >
> > > > Cullen <RAI AD>
> > > >
> > > >

---

From: Brian Rosen <[email-masked]>
Date: Tue, 17 Nov 2009 10:03:54 -0500

I am about to release the update, and wanted to address this.

First of all, I intended to change MUST include an offer to MAY.  I could
change it to SHOULD, but then I need text for when it wouldn't.  I could use
the basic argument that emergency calls come in many different media, and
the PSAP doesn't know what the UAC wants, but that is not exactly new news.

The text referenced talks about an update of an existing session.  Strictly
speaking, the text that says MUST include an offer is talking about the
initial INVITE.  Is this really an issue?  If the UAC doing the reINVITE
doesn't specify something the UAS receiving the INVITE can handle (as
represented by the original offer/answer), then there is the possibility the
call would fail. Seems reasonable to me, and discussed well enough in 3261,
which is referenced by phonebcp.  Do we need to make it more obvious?

If the original INVITE contains no offer, than the PSAP may well have to
offer several audio, several video and a text codec or two.  Is that not
obvious?  A full featured video device may well offer all of that normally,
so it's not that weird.  I guess a device expecting only one or two audio
codecs might have to plow through a lot of dreck, but it's supposed to be
able to do that.  I'd actually think that fact that such an offer may push
the 2XX over a packet may be more onerous than all the SDP to wade through.

If I need to open up -framework, a line or two about this issue wouldn't be
a bad idea.

Brian

On 11/15/09 12:37 PM, "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

> 1) The above could result in the UAC automatically generating a BYE request on
> reception of the SDP offer and therefore the emergency call failing. If we are
> going to allow this behaviour, then we should include a warning of the
> potential effects.
> 
> 2) In this case the PSAP now has to generate the SDP offer. What are our
> recommendations on what that offer should contain. How do we know it was a
> voice terminal that generated the call, and how do we cater for the potential
> that it was a real time text terminal that generated the call, or at least the
> case where the user wished to use real time text. (So much easier if the user
> actually indicates what they want).
> 
> regards
> 
> Keith 
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 18 Nov 2009 11:31:49 -0600

>the PSAP doesn't know what the UAC wants, but that is not exactly new news.

at the same time, if some of us can't keep up with how things 
generally are (and for what reason they are that way), others will 
really struggle to understand.

>which is referenced by phonebcp.  Do we need to make it more obvious?

more obvious to others not so skilled in the art is always a good 
thing on this topic, IMO

>offer several audio, several video and a text codec or two.

that's the advice of 3261 already. But will folks read 3261? Most 
will, but it is a big doc to digest all the subtleties. Perhaps 
giving the section number for the stated behavior in 3261 would help.

>Is that not