[Serusers] append_branch And New totag Problem

[Corey S. McFadden]

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:
> > 1. Call originates from SIP PSTN GW (Tekelec unit)
> > 2. SER routes call to UA
> > 3. UA doesn't answer
> > 4. Failure route happens and call is diverted to Asterisk
> > 5. 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 at 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.