Re: INFO Use case

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
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> Cullen Jennings
>>
>> 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 protected] for questions on current sip
>> Use [email protected] for new developments on the application of sip
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip