> The fact that SIP-T says that SIP headers take precedence over the > ISUP/Q.931 means you can't send the INVITE and the IAM over > separate channels (for example a TCP or Sigtran tunnel for > ISUP) without opening a big can of worms. How do you > synchronize those messages at the receiving end; you'd need > both the INVITE and the tunneled IAM before you can send > something out on the PSTN side. > > [Chris Boulton] I am struggling to see what the difference is > between passing SIP-T using a potentially un-reliable INFO > and using a reliable channel. You synchronize the messages > in the same way you synchronize receiving the INFO.
For those messages that are today sent using INFO there is no difference. I was referring to messages being sent in INVITE/BYE/CANCEL/... > How do you even make sure > those two channels reach the same destination after passing > through proxies, NATs, SBCs, load balancers, etc.? > > [Chris Boulton] These are all issues that are (and will be) > considered in the MediaCtrl work in drafts like > http://tools.ietf.org/html/draft-boulton-sip-control-framework -05 (*note - new WG version to be submitted this week). It is already understood that the solution MUST work in these cases. I can't help feeling this would be a step back, in a way. I like to think of SIP-T as an interim solution to speed up the deployment of SIP technology by service providers who still have one leg (or two, actually) in the old SS7 world. Over time, as more and more core networks are migrated to SIP (IMS/TISPAN/...), the need for SIP-T will disappear. Apart from the infamous INFO method, I'm still not convinced anything is 'wrong' with SIP-T, and that it needs to be replaced. Especially since, as others have pointed out, it already seems to be on its way out. But I must admit that I haven't had a chance yet to read your draft thoroughly. I'll do that now... Bram _______________________________________________ Sip mailing list https://www1.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
