Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Hi,

>Your proposal is along the lines of what I've written a couple of times now.

Excellent. Feel free to share some updated draft text reflecting that, so we can have a look at it, and discuss it on the list, BEFORE the Vancouver f2f meeting.

>What James Polk and I are thinking is that we could use the "remote" parameter in Alice's INVITE set to "null" to indicate that she supports the INSIPID draft.

True, now I remember that.

>If that is not there, then behavior falls back to Kaplan.

Yes.

>Likewise, the response will either echo the received value (per Kaplan) or include a different value in the reply along with placing the received UUID in the remote parameter (per INSIPID).

Awesome.

>I think that's workable, but it does make the endpoint more complicated to implement since it has to change behavior based on what it believes the remote end supports.

I don't think it makes things more complicated. The Kaplan mechanism is as easy as it gets. You only need to store a value and use it - in the same way use store e.g. the Call-Id header field value.

>And it still does not address the issues one will see with a Kaplan device calling another Kaplan device and having the call transferred to another 
>device.  (In that case, one end will think that the Session-ID is one value, while the other end thinks it is a different value.

The intention is NOT to improve the Kaplan solution. What doesn't work today, won't work tomorrow.

>I'm still puzzled over the insistence of going forward with the Kaplan draft or trying to be backward-compatible with it, given we know it will not always yield an end-to-end Session ID.)

People use it for what it does. 

Regards,

Christer

> -----Original Message-----
> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On 
> Behalf Of Christer Holmberg
> Sent: Saturday, September 14, 2013 10:33 AM
> To: Hadriel Kaplan; James Polk
> Cc: Atle Monrad; insipid@ietf.org; Gonzalo Camarillo
> Subject: Re: [Insipid] Timing for publishing 
> draft-kaplan-insipid-session- id
> 
> Hi,
> 
> Does anyone have issues with my suggestion below? I believe it could 
> be a rather straight forward solution. Paul, James & co get what they 
> want, and the backward compatibility folks get what they want :)
> 
> The only question is how a sender indicates that it support the 
> INSIPID mechanism. From a pure SIP protocol perspective, I believe a 
> media feature tag would be the most feasible mechanism. Now, Hadriel 
> have indicated that some intermediaires may remove feature tags. 
> However, in this case, maybe that would actually be a GOOD thing, 
> because it would automatically take care of the case where there are 
> intermediares that don't support the INSIPID mechanism in the path :)
> 
> What do people think? If needed, I am willing to provide text.
> 
> Regards,
> 
> Christer
> 
> ________________________________________
> From: insipid-bounces@ietf.org [insipid-bounces@ietf.org] on behalf of 
> Christer Holmberg [christer.holmberg@ericsson.com]
> Sent: Thursday, 12 September 2013 4:12 PM
> To: Hadriel Kaplan; James Polk
> Cc: Atle Monrad; insipid@ietf.org; Gonzalo Camarillo
> Subject: Re: [Insipid] Timing for publishing 
> draft-kaplan-insipid-session- id
> 
> Hi,
> 
> >>> I've always stated we editors of the jones draft will make the
> solution as backwards compatible with the kaplan draft as
> >>> possible, but that a 2 value ID will run into problems with a 
> >>> single
> value implementation, and that should be obvious to
> >>> everyone who thinks about it for a second.
> >> That said, we have received ZERO comments to our latest proposal 
> >> that
> we think actually accomplishes this no matter
> >> the version of the endpoint that initiates or receives the SIP
> message... zero... and that's really disheartening.
> >
> > Ummm... what latest proposal?  I may have missed an email somewhere.
> 
> One of my early proposal was that, if either endpoint supports Kaplan, 
> we simply won't use the 2 value ID.
> 
> So, if the one sending the INVITE only supports Kaplan (we need to 
> define how that is determined), the receiver does not add the 2nd 
> part, copies the received value into the response, and uses that in 
> any subsequent request/response within the session.
> 
> And, if the receiver only supports Kaplan (the sender will figure this 
> out since the receiver won't add the 2nd part), then only one part 
> will be used in each request/response through the session.
> 
> Now, that takes care of backward compatibility as far as the endpoints 
> are concerned. However, there could of course be an intermediary that 
> doesn't support the INSIPID mechanism, but the question is whether that matters.
> 
> Regards,
> 
> Christer
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid