Subject: [Sip] INFO Use case

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Nov 2008 13:52:17 -0600

Let's imagine that there is a base DTMF package defined that supports  
the 12 basic keys. Now cisco makes a vendor specific package that is  
pretty much the same but includes key presses for the  "HOLD" button.   
Nortel does pretty much the same but calls it the "F1" button. Now  
SNOM wants to build a phone that supports both and in fact is  
operating in an environment with a Nortel PBX, Cisco Voice Mail, and  
Asterix SBC which understands both - the phone really needs to send  
both and they need to be one atomic action so they are not interpreted  
as the wrong thing or as double key presses.

It seems that things along the lines of the above will happen and need  
to be considered. I don't know if this means an INFO needs to carry  
more that one thing or not. The worst possible solution I can imaging  
to this is that SNOM builds a new package that combines the Cisco and  
Nortel package.

Cullen <in my individual contributor roll>

PS - I do not care if people want to solve this use case or not. I  
just mention it as something I view as somewhat likely to happen. I am  
happy with whatever get's decided. 
_______________________________________________
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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 18 Nov 2008 21:05:01 +0100

Questions:

1)	Do you achieve any better interoperability by preventing this
happening? Will SNON build something that is directly equivalent in
functionality to Cisco + Nortel

2)	If an individual vendor specifies their own package, then can we
control this except by expert review? And if we do that expert review,
do we provide a barrier to registration. At least if we have an open
registration we could keep an eye on the registration page and encourage
people who are registering similar things to cooperate on a combined
package.

And finally, I believe we are pushing in the direction of it is up to
the package specifiers to specify the interaction with any other
package, and therefore SIP will not specify any of "they need to be one
atomic action so they are not interpreted as the wrong thing or as
double key presses".

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Cullen Jennings
> Sent: Tuesday, November 18, 2008 7:52 PM
> To: SIP List
> Subject: [Sip] INFO Use case
> 
> 
> Let's imagine that there is a base DTMF package defined that 
> supports the 12 basic keys. Now cisco makes a vendor specific 
> package that is  
> Nortel does pretty much the same but calls it the "F1" 
> button. Now SNOM wants to build a phone that supports both 
> and in fact is operating in an environment with a Nortel PBX, 
> Cisco Voice Mail, and Asterix SBC which understands both - 
> the phone really needs to send both and they need to be one 
> atomic action so they are not interpreted as the wrong thing 
> or as double key presses.
> 
> It seems that things along the lines of the above will happen 
> and need to be considered. I don't know if this means an INFO 
> needs to carry more that one thing or not. The worst possible 
> solution I can imaging to this is that SNOM builds a new 
> package that combines the Cisco and Nortel package.
> 
> PS - I do not care if people want to solve this use case or 
> not. I just mention it as something I view as somewhat likely 
> to happen. I am happy with whatever get's decided. 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Nov 2008 14:20:38 -0600

On Nov 18, 2008, at 1:52 PM, Cullen Jennings wrote:

> package that is pretty much the same but includes key presses for  
> the  "HOLD" button.  Nortel does pretty much the same but calls it  
> the "F1" button. Now SNOM wants to build a phone that supports both  
> and in fact is operating in an environment with a Nortel PBX, Cisco  
> Voice Mail, and Asterix SBC which understands both - the phone  
> really needs to send both and they need to be one atomic action so  
> they are not interpreted as the wrong thing or as double key presses.
>
> It seems that things along the lines of the above will happen and  
> need to be considered. I don't know if this means an INFO needs to  
> carry more that one thing or not. The worst possible solution I can  
> imaging to this is that SNOM builds a new package that combines the  
> Cisco and Nortel package.

I'm thinking this is an argument against a vendor tree and in favor of  
a spec-required policy that allows minimal specifications.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Nov 2008 17:11:32 -0500

I'm not sure I understand the problem.  If Cisco and Nortel make a vendor-specific package, then by definition it is vendor specific.  If they wanted to make it useable by everyone, they would go through an RFC process, not a vendor-specific namespace.  And I don't know why they would define a vendor-specific package which reproduced the same set of buttons as a published DTMF one - I would think they'd only be for the new/different buttons that the published RFC didn't handle.

But anyway, lets say Snom is an environment with all 3 and has figured out the vendor-specific ones.  They're only talking to one UAS though, and will use whatever the UAS supports.  Snom would advertise all 3 packages in their Recv-Info header, if they supported all 3.  The far-end UAS would say what it can handle for that specific call.

Let's say the UAS supported all 3.  So the user presses a button.  Snom is now free to send it however it wants, because the other end supports all 3.  Since they knew what the packages were that they implemented, they would know they're for the same button, that the action is atomic, and that they should only send it in one of the packages.  Presumably Nortel or Cisco's vendor-specific package logic would handle such things appropriately - if not that's their problem - it's a vendor-specific package.  You reap what you sow. ;)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings
>

---

From: Eric Burger <[email-masked]>
Date: Tue, 18 Nov 2008 18:23:39 -0600

Interesting scenario. Good thing there is a B2BUA and not a proxy.  
This is because either:
    UA-SNOM is talking first the Nortel PBX, in which case it will see  
a Recv-Info: Nortel_DTMF from the UAS
    UA-SNOM is talking with the Cisco VM, in which case it will see a  
Recv-Info: Cisco_DTMF from the UAS
Or,
    UA-SNOM will see a Recv-Info: Acme_DTMF
because the SBC will be doing normalization.

The really interesting scenario is where the PBX is the B2BUA, and the  
signaling goes through the PBX. In this case it should take the  
packages from the VM and combine it with its own PBX packages. In this  
case
    UA-SNOM will see a Recv-Info: Nortel_DTMF, Cisco_DTMF

What is messed up with this situation is UA-SNOM has to know whether  
it is in "PBX mode" or "VM mode" to know which package to use. Worse  
yet, what happens if the phone says, "Well, the UAS is giving me the  
choice of Nortel or Cisco. I'll chose Nortel" and then proceed to be  
connected to the Cisco box. The Cisco box then barfs.

Of course, this is less harmful if the implementors went with
    Recv-Info: DTMF, Nortel_Extra_Keys, Cisco_Extra_Keys

Is this an argument for Send-Info?  If UA-SNOM says, "Send-Info: DTMF,  
Nortel_Extra_Keys" to Cisco, Cisco can say, "Oh no you don't." The  
down side: this would require real capabilities negotiation, which we  
said we wanted to punt.

On Nov 18, 2008, at 4:11 PM, Hadriel Kaplan wrote:

>
> I'm not sure I understand the problem.  If Cisco and Nortel make a  
> vendor-specific package, then by definition it is vendor specific.   
> If they wanted to make it useable by everyone, they would go through  
> an RFC process, not a vendor-specific namespace.  And I don't know  
> why they would define a vendor-specific package which reproduced the  
> same set of buttons as a published DTMF one - I would think they'd  
> only be for the new/different buttons that the published RFC didn't  
> handle.
>
> But anyway, lets say Snom is an environment with all 3 and has  
> figured out the vendor-specific ones.  They're only talking to one  
> UAS though, and will use whatever the UAS supports.  Snom would  
> advertise all 3 packages in their Recv-Info header, if they  
> supported all 3.  The far-end UAS would say what it can handle for  
> that specific call.
>
> Let's say the UAS supported all 3.  So the user presses a button.   
> Snom is now free to send it however it wants, because the other end  
> supports all 3.  Since they knew what the packages were that they  
> implemented, they would know they're for the same button, that the  
> action is atomic, and that they should only send it in one of the  
> packages.  Presumably Nortel or Cisco's vendor-specific package  
> logic would handle such things appropriately - if not that's their  
> problem - it's a vendor-specific package.  You reap what you sow. ;)
>
> -hadriel
>
>> need

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Nov 2008 02:05:18 -0500

Comments inline...

> From: Eric Burger [mailto:[email-masked]]
> Sent: Tuesday, November 18, 2008 7:24 PM
>

If a B2BUA "combines" packages it learned from the dialog on its other "side" with ones it itself supports, then it better well know what they do and how to handle them - in other words the B2BUA itself should support them.  If the B2BUA does not support the INFO-package concept/mechanism in this new draft, and blindly passes on what it got from each side as just an unknown header, things should work ok end-to-end, in theory, depending on how much the B2BUA hides the dialogs from each other. (more on that later)

In your scenario the B2BUA is a Nortel PBX, which supports its own Info package.  Ergo it understands the new Info package draft, and should know what its doing.  As it stands right now the draft's scope ends at the B2BUA, because it ends at the UAS.  Are you thinking we should specify what a B2BUA should do?

> connected to the Cisco box. The Cisco box then barfs.

First, the Cisco shouldn't barf. (though barfing does keep the weight down :)  It should reject the INFO, and in its response it gets a chance to put in what recv-info it does support, so Snom learns better.  That *is* your "Oh no you don't" re-learning exchange. :)

But I also don't understand how that could really happen to begin with, except for in one specific case.

The cases as I see them:
- If a B2BUA routes the call to Nortel, then Snom would get a Nortel recv-info.
- If it routes it to the Cisco, then SNOM would get a Cisco recv-info.
- If the B2BUA supported its own package, then one would think it would also eat the INFO requests for its own package and not forward them on.
- If the B2BUA forks the call as a proxy, the SNOM will get each recv-info on a separate early dialog, which is fine.
- If the B2BUA hides the details of the Nortel or Cisco dialog legs from Snom, I don't know how it would get the chance to tell Snom both packages at the same time to create such confusion, without knowing about this new Info draft thing to begin with.  It would have to know/understand the Info package draft to do such muxing/combining.  Once it knows the new draft, it would know to "route" the appropriate INFO message to the appropriate party, or reject it if that leg is gone.  No barfing.
- If the B2BUA moved the call discretely from Nortel to Cisco, and supported/understood this new Info-package draft, it would know it needs to update the Snom UA with the current packages in an in-dialog Invite/Update recv-info, because it truly no longer supports both packages.

- If the B2BUA moved the call discretely but did NOT know about this new Info draft thingy, then it could *indeed* be a problem if it blindly passed on the Nortel recv-info but not the later Cisco one.  And it wouldn't pass on the Cisco's recv-info only because it is hiding the dialog move from Snom.
However, send-info does nothing to prevent/help that.  And I should point out it is no worse than what we have now, which is manual configuration.
And it's no worse than a B2BUA blindly passing back Allow/Accept/Supported type headers for an initial dialog and not updating them later when it moves the dialog.
What the new draft DOES provide, is a way for Snom to learn the new info-packages supported by cisco when it sends a nortel INFO message and cisco responds with a different recv-info set.

> Nortel_Extra_Keys" to Cisco, Cisco can say, "Oh no you don't."

Again, the only case I can see Snom thinking X and the far-end UAS thinking Y is if something in the middle is hiding dialog changes.  If it's hiding those, then what triggers Snom to send a new send-info list, and what makes the B2BUA send that list to the Cisco?  Because whatever it is would just as well also mean Cisco gets a chance to send an updated recv-info list, and snom learns the change.
In the worst case, that happens when Snom sends an INFO cisco doesn't understand.

Am I not comprehending the problem case you guys are talking about?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Nov 2008 09:33:07 -0500

> - If the B2BUA moved the call discretely but did NOT know about this new Info draft thingy, then it could *indeed* be a problem if it blindly passed on the Nortel recv-info but not the later Cisco…

This is normal 3pcc transfer trouble, just like the problems of moving 
the media in such a case if the b2bua doesn't terminate media. That is 
why I called out this case earlier.

Its a little tricky when it doesn't know about the new draft. If it is 
switching the media then it will be doing a reinvite/update with the new 
endpoint anyway, and so will be getting a new recv-info. As long as it 
passes that transparently things should work out. Its more of a problem 
if it relaying the media, so that it doesn't intend to do a new o/a 
exchange, then its more problematic.

It *could* work, but there are a lot of "if"s.

The bottom line is that the b2buas will have to learn how to make this 
work. They will just need to get with the program and be ready before 
this stuff is deployed in endpoints.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Nov 2008 14:08:51 -0500

Right, but as I said this new Info-package draft does not make the problem any worse for this scenario than it already was.  And in fact it can make it better even for this scenario.  That's all we need to do.  I don't think there's a solution to solve this scenario for legacy or new Info usage, without having the B2BUA understand the draft, and once it does that we're ok anyway.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2008 9:33 AM
>
> Hadriel Kaplan wrote:
> > - If the B2BUA moved the call discretely but did NOT know about this new
> Info draft thingy, then it could *indeed* be a problem if it blindly
> passed on the Nortel recv-info but not the later Cisco one.  And it
> wouldn't pass on the Cisco's recv-info only because it is hiding the
> dialog move from Snom.
>