Hey,
I've got all my call forwarding stuff setup in ser using the avpops module and everything works as expected. I can dial a sequence and store the call forwarding numbers in the database and when calls come I can retrieve the info and change the RURI using avp_pushto. The problem is this, and I'm wondering if I'm missing something or I need to goto our transit gw vendor.
- 12223334444 & 12223334445 are PSTN numbers - 13334445555 is a SIP number registered with ser
1. inbound call : 12223334444 -> 13334445555
2. ser receives the invite and checks the avpops table
3. ruri is re-written to contain 12223334445 and a route() statement is called to forward the call back out the PSTN gateway
4. the transit gw never responds to the invite because the Cseq field follows that of the previous invite the transit gw sent to us and it's not expecting an invite.
5. the inbound call is finally cancelled and the transaction ends as expected.
Should I be doing something else before I rewritehostport and forward back to PSTN or is it something the vendor should be doing but that's not happening?
Any insight is appreciated.
-Evan
Hi Even,
I would say it's a problem on GW side. I saw people complaining in similar situation about Asterisk which detects as "loop" the second INVITE. Maybe is your case also. Can you get some logs from the GW?
Best regards, Marian
Evan Borgstrom wrote:
Hey,
I've got all my call forwarding stuff setup in ser using the avpops module and everything works as expected. I can dial a sequence and store the call forwarding numbers in the database and when calls come I can retrieve the info and change the RURI using avp_pushto. The problem is this, and I'm wondering if I'm missing something or I need to goto our transit gw vendor.
- 12223334444 & 12223334445 are PSTN numbers
- 13334445555 is a SIP number registered with ser
inbound call : 12223334444 -> 13334445555
ser receives the invite and checks the avpops table
ruri is re-written to contain 12223334445 and a route() statement is called to forward the call back out the PSTN gateway
the transit gw never responds to the invite because the Cseq field follows that of the previous invite the transit gw sent to us and it's not expecting an invite.
the inbound call is finally cancelled and the transaction ends as expected.
Should I be doing something else before I rewritehostport and forward
back to PSTN or is it something the vendor should be doing but that's not happening?
Any insight is appreciated.
-Evan
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers