Subject: [Sip] SUBSCRIBE and From

From: [email-masked]
Date: Wed, 9 Jul 2008 14:54:21 -0400

We're revising draft-ietf-bliss-call-completion-02 in the
Call-Completion committee of BLISS.  It turns out that our design can
be simplified and made more robust toward various difficulties in the
Real World if the the recipient of a SUBSCRIBE request could take the
>From header of the request into consideration when determining the
entity/events that are to be sent in NOTIFYs.

But it does look like having a subscription affected by the From value
has not done before, so we're extending the practice of SIP, if not
the letter of the law.  Use of the From value is not described in RFC
3265, but as one member pointed out, "It doesn't say you can't,
either."

What do people think of this?

The use case:  We want to be able to correlate an incoming SUBSCRIBE
with a previous incoming INVITE from the same UA.  The original idea
was that the SUBSCRIBE should specify in some manner the Call-Id of
the INVITE, but it turns out that in real SIP networks, SBCs often
change the Call-Id, so the caller doesn't know the Call-Id that the
callee sees.  However, it's rather reliable that the From headers of
the two requests will match, as SBCs are likely to change both of them
in the same way.

Dale
_______________________________________________
Sip mailing list  https://www.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: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 9 Jul 2008 23:02:42 -0400

What if a Target-Dialog header was added to Subscribe by one of the UA?
Will the SBC modify the Call-Id in this header to match the call-id
between SBC and the other UA.

Sanjay

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of [email-masked]
>Sent: Wednesday, July 09, 2008 2:54 PM
>To: [email-masked]
>Subject: [Sip] SUBSCRIBE and From
>
>Call-Completion committee of BLISS.  It turns out that our 
>design can be simplified and made more robust toward various 
>difficulties in the Real World if the the recipient of a 
>SUBSCRIBE request could take the From header of the request 
>into consideration when determining the entity/events that are 
>to be sent in NOTIFYs.
>
>But it does look like having a subscription affected by the 
>From value has not done before, so we're extending the 
>practice of SIP, if not the letter of the law.  Use of the 
>From value is not described in RFC 3265, but as one member 
>pointed out, "It doesn't say you can't, either."
>
>The use case:  We want to be able to correlate an incoming 
>SUBSCRIBE with a previous incoming INVITE from the same UA.  
>The original idea was that the SUBSCRIBE should specify in 
>some manner the Call-Id of the INVITE, but it turns out that 
>in real SIP networks, SBCs often change the Call-Id, so the 
>caller doesn't know the Call-Id that the callee sees.  
>However, it's rather reliable that the From headers of the two 
>requests will match, as SBCs are likely to change both of them 
>in the same way.
>
>Dale
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 10 Jul 2008 21:31:29 +0300

Hi Dale,

the context-id solves this use case

in the draft: 
http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-00.txt
I have described how the context-id can solve the problem to "correlate 
the INVITE,
SUBSCRIBE request and recall INVITE in SIP Call completion scenario"

/Sal

---

From: [email-masked]
Date: Thu, 10 Jul 2008 22:48:37 -0400

From: Salvatore Loreto <[email-masked]>

   in the draft: 

We've discussed context-id in the design committee, and we've also
discussed having the SUBSCRIBE provide the Call-Id (or from-tag) of
the INVITE, which for our purposes is very similar to context-id.
Unfortunately, neither proposal works well in the "call completion"
context, for several reasons:

The vast majority of INVITEs will never be subject to call-completion,
and there is no way to predict in advance which ones will.  Thus, for
efficiency's sake, providers don't want to attach to each INVITE an
additional context-id.

One would hope to avoid the first problem by using the Call-Id or
from-tag of the INVITE as its context-id, but in practice, many calls
pass through SBCs which modify both of those.

In addition, for truly wide-scale use, we would have to get the
operators of SBCs to configure them to propagate the context-id, which
cannot be done immediately.

Dale

---

From: [email-masked]
Date: Thu, 10 Jul 2008 22:55:31 -0400

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>

That is a clever idea, although I'm nervous about overloading
Target-Dialog like that.

An SBC might not process Target-Dialog as well as we would want,
because the INVITE dialog would be terminated before the SUBSCRIBE
arrives, and the SBC may have forgotten about the Call-Id translation.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jul 2008 07:49:31 -0400

I agree that it is unreasonable to expect middleboxes to remember dialog 
ids and be able to translate them, after the dialog has ended.

But after listening to all of these problems, I wonder if it might be 
necessary to expect SBCs to do *something* that they might not currently 
do. And just recognize that this won't work until the SBCs are updated. 
In the end we can't work around all the damage SBCs do - they have some 
responsibility.

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 11 Jul 2008 15:12:59 -0400

From: Paul Kyzivat <[email-masked]>

Emotionally I agree with your position, but as a practical matter, we
want to have call-completion work without any change in the transit
networks (even though the transit networks are not truly
SIP-compliant).

Dale

---

From: Adam Roach <[email-masked]>
Date: Fri, 11 Jul 2008 14:42:20 -0500

On 7/11/08 6:49 AM, Paul Kyzivat wrote:
> necessary to expect SBCs to do *something* that they might not 
> currently do. And just recognize that this won't work until the SBCs 
> are updated. In the end we can't work around all the damage SBCs do - 
> they have some responsibility.

Paul is 100% correct -- if we limit any future protocol extensions to 
what will work through unmodified SBCs as they exist today, then we 
don't need to meet in Dublin. We're done. Shut the working group down 
and send everyone home. Dean and Keith, please be sure to turn the 
lights off on the way out.

Let's not the SBC tail wag the SIP dog to death.

/a

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Fri, 11 Jul 2008 15:55:57 -0400

Maybe new drafts should have an SBC behavior section which should call
out how the SBC should handle messages, similar to existing RFCs/drafts
which call out how UAC & UAS should handle messages.

Sanjay

>Behalf Of Adam Roach
>Sent: Friday, July 11, 2008 3:42 PM
>To: Paul Kyzivat (pkyzivat)
>Cc: [email-masked]
>Subject: Re: [Sip] SUBSCRIBE and From
>
>Paul is 100% correct -- if we limit any future protocol 
>extensions to what will work through unmodified SBCs as they 
>exist today, then we don't need to meet in Dublin. We're done. 
>Shut the working group down and send everyone home. Dean and 
>Keith, please be sure to turn the lights off on the way out.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jul 2008 16:09:31 -0400

I have the impression that at least some of the SBCs (e.g. the one who 
has representatives speaking in the forum regularly) are pretty well 
equipped to do something new that might be required, without a lot of 
hassle.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Sun, 13 Jul 2008 12:50:54 -0500

On Jul 11, 2008, at 2:42 PM, Adam Roach wrote:
>
> Paul is 100% correct -- if we limit any future protocol extensions  
> to what will work through unmodified SBCs as they exist today, then  
> we don't need to meet in Dublin. We're done. Shut the working group  
> down and send everyone home. Dean and Keith, please be sure to turn  
> the lights off on the way out.

I've had my hand on the light switch for months.

--
Dean

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 22 Jul 2008 17:33:09 +0200

But I think we all agree that there are some problems with existing SBCs. So if there is a SIP compliant solution for these problems, why not use it now? Of course we still would have to discuss if Dale's proposal is SIP compliant.

Finding guidelines for describing the behaviour of SBCs probably would take some time. 

Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Paul Kyzivat
> Gesendet: Freitag, 11. Juli 2008 22:10
> An: Adam Roach
> Cc: [email-masked]
> Betreff: Re: [Sip] SUBSCRIBE and From
> 
> extensions to