Greger,
Thanks for the response. It looks like there's a problem with the Tekelec card's SIP handling. According to Jiri @ IptelOrg we shouldn't have to do anything on the to-tags. He's e-mailing someone within Tekelec about fixing the bug. (How's that for a spirit of cooperation?!)
-Corey
On Tue, 13 Sep 2005, Greger V. Teigre wrote:
Corey, I'm not an Asterisk expert, but could you clearify one thing: Does SER change the To tag when forwarding to Asterisk or does Asterisk change the To tag? It is unclear from your email. I would suspect this problem arises on the Asterisk side. Many people have such a setup running, so I'm not sure why you have problems. I would expect any GW to get problems if the To tag is rewritten. According to the RFC, you should NOT rewrite To. g-)
Corey S. McFadden wrote:
Guys,
We're working with Tekelec to solve a problem we're experiencing with one of their SIP gateway cards. (We're working with a group that hadn't heard of SER before we talked to them, so this may or may not be correct.)
What happens is this:
- Call originates from SIP PSTN GW (Tekelec unit)
- SER routes call to UA
- UA doesn't answer
- Failure route happens and call is diverted to Asterisk
- Asterisk gets the call but the SIP PSTN GW doesn't ACK the OKs and hangs up.
The scenario works with a variety of UA hardware, so I didn't think anything was wrong on our side, but they're saying that on the first phase of the call the totag has one ID and then when Asterisk gets involved there's a different totag ID. (This is confirmed w/packet captures.) When the GW card gets the second totag it doesn't match a transaction and it is ignored.
So, my question is... can (and should) we rewrite the totags back to the original id? Can this be done w/textops? Is this a common problem?
Does this make sense?
Thanks for any help, -Corey
This message has been scanned for viruses and dangerous content, and is believed to be clean.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
This message has been scanned for viruses and dangerous content, and is believed to be clean.
********************************************* This message has been scanned for viruses and dangerous content, and is believed to be clean.