Hi, In ETSI TISPAN, there is work on something called IMS based PSTN/ISDN emulation. In that network, the ISUP information can actually be originated/terminated inside the network (i.e. it's not simply tunneled through the IP network between the MGCs, or something like that), normally by an application server understanding the ISUP information. There are also rules about proxies removing ISUP information before forwarding messages to UAs and/or other networks.
My point is that the entities using the ISUP information may not have "media access", so in case a separate channel is used they would have to make sure that tunnel is relayed through those entities (in some cases they would have to terminate the channel, if the ISUP content is not meant to be forwarded), meaning they would have to modify SDPs etc. Regards, Christer > -----Original Message----- > From: Chris Boulton [mailto:[EMAIL PROTECTED] > Sent: 6. syyskuuta 2007 11:55 > To: Bram Verburg; Eric Burger > Cc: sip > Subject: RE: [Sip] INFO > > 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. > > 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. > > Chris. > > > > > > Information contained in this e-mail and any attachments are > intended for the use of the addressee only, and may contain > confidential information of Ubiquity Software Corporation. > All unauthorized use, disclosure or distribution is strictly > prohibited. If you are not the addressee, please notify the > sender immediately and destroy all copies of this email. > Ubiquity Software Corporation plc, a company registered under > the laws of England and Wales, Registration 2719723, > registered offices at Eastern Business Park, Building 3, Wern > Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom. > > > > _______________________________________________ > 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 > _______________________________________________ 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
