Comments inline... > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2008 7:24 PM > > 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
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? > 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. 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. > 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." 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 _______________________________________________ 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
