Random musings on the possibility that the iCall s/w induces redirect behavior during call-setup (w/ the caveat that I'm assuming Iphone/AT&T uses the standard GSM stuff)...
I'm not sure of the date on this document (GSM Air-Interface), but see table 7.7 (Call control) where I don't see anything in the messaging that looks like a redirect message during call setup.
If you look at this ISUP docs you won't see anything there either. ISUP/TUP/etc are pretty basic call setup once the endpoint is known. Usually MAP/TCAP is used by the originating entities to do more sophisticated stuff (like finding the ultimate terminating endpoint, whether an artefact of call-forwarding, ported number, wireless roaming, etc.)
Now, ISUP is just call setup, and there's more in-call functionality (like sending DTMF digits, putting call on hold, etc) in the call control of the Air Interface. But, if ISUP doesn't support it (on the MSC->BSC interace) then it's not surprising that the Air interface doesn't either.
Ergo, even assuming the ability of iCall to interfere w/ the IPhone GSM stack behavior, no obvious ability to redirect an incoming call at the terminating point during call-setup. So, not betting the farm on that possibility.
"Of course, it is a SIP feature" should have been associated w/ 1), rather than 2). SIP allows the terminating endpoint to redirect via the 3xx responses. ISUP (AFAIK) does not. The GSM air-interace (AFAIK) also does not.
I'd have to review some specs, but I'm very curious how they acheive "Transfer inbound calls from a regular cell call to WiFi instantly and seamlessly." There are a few explanations I can think of, but they strike me as very doubtful, or trivial in the case of 0).
0) You set up call forwarding at the carrier level, to forward to the iCall number. Trivial and not free of charge.
1) the iCall s/w is able to detect an incoming cell call setup, and induce the iPhone's Air-interface stack to issue a call-forwarding response back to the origination. I'd have to check the Air-interface specs to see if that's even possible.
2) There is some extra-GSM standard messaging on the Iphone/AT&T network to allow a third-party (ie. the iCall) to initiate change/transfer of the terminating endpoint of an existing call. That would be funcationalily I've never seen in GSM. Of course, it is a SIP feature.
The Engineers figured a way to send text messages over SS7 to communicate with each other while testing/ integrating
This would be before my time, but are you implying that they sent messages in the SCCP payload? or within ISUP? ie, before there was a TCAP and MAP layer. I'm just assuming that ISUP was the first thing created in the effort to move ISDN signalling off the voice channels, and that TCAP/MAP/etc came about some time later.
Xenophobia? Stupid beliefs? Jeez, you people sure are defensive.
I could have included that the IS-41 MAP layer includes SMS messaging and would be subject to the same problems. In fact the paper mentions that similiar problems apply to the CDMA air interface. Maybe, I should have said that, but my point was that the core MAP/SS7 network suffers from the exact same problem that the air interface apparently suffers from, for much the same reason.
As someone whose actually worked in several cellular protocol environments, in several countries(and on several operating systems, no less!), I don't actually have a particular preference or bias,..., except against morons that reflexively cry "xenophobia" when someone points out critical features of a protocol.
(ps. If I had said that "AmeriKKKan" usage of IS-41 suffers from the same problem, would you have been happy?)
Several years ago I was involved in solving a similiar problem in the GSM/MAP/SS7 backbone network of a major European cellular provider/broker. In that case, there was an problem because the SMS messaging is carried in the MAP "signalling" layer, which resulted in the waste of the vast majority of the bandwidth that was meant to be used to handle subscriber management, roaming, authentication, etc. The network (which provided roaming between 100+ sizable European, Asian, and North African carriers) was being saturated with internet-generated SMS text messaging. Essentially, we were only able to block the traffic, having little control over its generation and/or entry into the network.
Clearly the people that designed the air interface made the same poor architectural decision.
"The network can not trust the customer's agent to mark the packets honestly and MUST rewrite the QoS at the border."
Is this true, in general, that networks are now (potentially) un-prioritize incoming traffic, by resetting TOS/Precedence settings in the IP headers? Is this typical at the customer-to-ISP edge, or ISP-to-Backbone Network also?
Anyone know how to go about building one of these?
Do a google search on 'PRI Tester' and you'll find dozens of hand held devices that run about $3K. I'd like a laptop with a ISDN PCMCIA card running just a simple stack to sniff what the other end is transmitting.
I don't even want to think about how long I had to look for one commonsensical post. I guess threads like these really bring out the anarchists (socialist anarchists, no doubt).
(and I'm about as opposed to accumulation of government power as anybody could ever want to be)
There are already a bunch of L4 implementations out there with varying degrees of availibility and licensing and some using version 4 of L4 ABI are due out soon...
I actually covered for this teacher one day for the class in question. I can attest to the veracity of the post. There was exactly one dude who took the time to ask me questions about their current project.
All of which makes your "troll" comments pretty silly.
Slashdot Mirror
I'm not sure of the date on this document (GSM Air-Interface), but see table 7.7 (Call control) where I don't see anything in the messaging that looks like a redirect message during call setup.
If you look at this ISUP docs you won't see anything there either. ISUP/TUP/etc are pretty basic call setup once the endpoint is known. Usually MAP/TCAP is used by the originating entities to do more sophisticated stuff (like finding the ultimate terminating endpoint, whether an artefact of call-forwarding, ported number, wireless roaming, etc.)
Now, ISUP is just call setup, and there's more in-call functionality (like sending DTMF digits, putting call on hold, etc) in the call control of the Air Interface. But, if ISUP doesn't support it (on the MSC->BSC interace) then it's not surprising that the Air interface doesn't either.
Ergo, even assuming the ability of iCall to interfere w/ the IPhone GSM stack behavior, no obvious ability to redirect an incoming call at the terminating point during call-setup. So, not betting the farm on that possibility.
"Of course, it is a SIP feature" should have been associated w/ 1), rather than 2). SIP allows the terminating endpoint to redirect via the 3xx responses. ISUP (AFAIK) does not. The GSM air-interace (AFAIK) also does not.
0) You set up call forwarding at the carrier level, to forward to the iCall number. Trivial and not free of charge.
1) the iCall s/w is able to detect an incoming cell call setup, and induce the iPhone's Air-interface stack to issue a call-forwarding response back to the origination. I'd have to check the Air-interface specs to see if that's even possible.
2) There is some extra-GSM standard messaging on the Iphone/AT&T network to allow a third-party (ie. the iCall) to initiate change/transfer of the terminating endpoint of an existing call. That would be funcationalily I've never seen in GSM. Of course, it is a SIP feature.
This would be before my time, but are you implying that they sent messages in the SCCP payload? or within ISUP? ie, before there was a TCAP and MAP layer. I'm just assuming that ISUP was the first thing created in the effort to move ISDN signalling off the voice channels, and that TCAP/MAP/etc came about some time later.
I could have included that the IS-41 MAP layer includes SMS messaging and would be subject to the same problems. In fact the paper mentions that similiar problems apply to the CDMA air interface. Maybe, I should have said that, but my point was that the core MAP/SS7 network suffers from the exact same problem that the air interface apparently suffers from, for much the same reason.
..., except against morons that reflexively cry "xenophobia" when someone points out critical features of a protocol.
As someone whose actually worked in several cellular protocol environments, in several countries(and on several operating systems, no less!), I don't actually have a particular preference or bias,
(ps. If I had said that "AmeriKKKan" usage of IS-41 suffers from the same problem, would you have been happy?)
Several years ago I was involved in solving a similiar problem in the GSM/MAP/SS7 backbone network of a major European cellular provider/broker. In that case, there was an problem because the SMS messaging is carried in the MAP "signalling" layer, which resulted in the waste of the vast majority of the bandwidth that was meant to be used to handle subscriber management, roaming, authentication, etc. The network (which provided roaming between 100+ sizable European, Asian, and North African carriers) was being saturated with internet-generated SMS text messaging. Essentially, we were only able to block the traffic, having little control over its generation and/or entry into the network.
Clearly the people that designed the air interface made the same poor architectural decision.
Wow. Are the terrorists really on track to kill 100 Million people this century?
"The network can not trust the customer's agent to mark the packets honestly and MUST rewrite the QoS at the border."
Is this true, in general, that networks are now (potentially) un-prioritize incoming traffic, by resetting TOS/Precedence settings in the IP headers? Is this typical at the customer-to-ISP edge, or ISP-to-Backbone Network also?
Anyone know how to go about building one of these?
Do a google search on 'PRI Tester' and you'll find dozens of hand held devices that run about $3K. I'd like a laptop with a ISDN PCMCIA card running just a simple stack to sniff what the other end is transmitting.
Yeah, yeah, yeah, I'll look around on my own.
(and I'm about as opposed to accumulation of government power as anybody could ever want to be)
There are already a bunch of L4 implementations out there with varying degrees of availibility and licensing and some using version 4 of L4 ABI are due out soon...
I actually covered for this teacher one day for the class in question. I can attest to the veracity of the post. There was exactly one dude who took the time to ask me questions about their current project.
All of which makes your "troll" comments pretty silly.
The first thought that occurred to me was: Who is going to be the ISP? The cellular provider probably.
Obviously you've only used the service and never had to put in any work to support it. Trust me, it doesn't just spring out of thin air