At 01:19 AM 4/4/2003, Mike wrote:
I'm trying to get SER to work properly with the call forwarding feature of an ATA-186. The ATA-186 forwards calls (#90number#) by doing a BYE with an "also" header. SER doesn't seem to do anything with this at all, and the call just sits in limbo until everybody hangs up.
Call forwarding on busy/no-answer works, but I think that's because the ATA is doing a refer instead.
Any clue where I should be looking for this? Is SER supposed to support this BYE/also method, and I have something misconfigured, or is there additional work that needs to be done to support this?
I'm not sure what exactly happens from your narration. The terminology is little a bit new to me -- forwarding means imho sending a 3xx reply to an INVITE and not BYE requests. A message dump would help me to understand.
Anyway, I don't think that is an issue related to SER -- it is about end-device features.
-Jiri
On Fri, 4 Apr 2003, Jiri Kuthan wrote:
At 01:19 AM 4/4/2003, Mike wrote:
I'm trying to get SER to work properly with the call forwarding feature of an ATA-186. The ATA-186 forwards calls (#90number#) by doing a BYE with an "also" header. SER doesn't seem to do anything with this at all, and the call just sits in limbo until everybody hangs up.
Call forwarding on busy/no-answer works, but I think that's because the ATA is doing a refer instead.
Any clue where I should be looking for this? Is SER supposed to support this BYE/also method, and I have something misconfigured, or is there additional work that needs to be done to support this?
I'm not sure what exactly happens from your narration. The terminology is little a bit new to me -- forwarding means imho sending a 3xx reply to an INVITE and not BYE requests. A message dump would help me to understand.
I apologize for the terminology, I'm still learning.
Here is a dump of what the ATA sends when I try to do a #90 transfer. To put it in context, there's a call from PSTN 6105551212 into gateway 209.120.198.3, that was sent to the SER server at 209.120.196.55, and forwarded to 6526@209.120.196.55. What I did was flash, #90696969#, which is supposed to initiate a call transfer to 696969@sip.idv.net:
U 209.120.199.48:5060 -> 209.120.196.55:5060 BYE sip:6526@209.120.196.55 SIP/2.0 Route: sip:6105551212@209.120.198.3:5060 Via: SIP/2.0/UDP 209.120.199.48:5060 From: sip:6526@sip.idv.net;tag=3150544293 To: sip:6105551212@209.120.198.3;tag=37B594A8-2548 Call-ID: E5D90DDA-559F11D7-8505F29A-D0DE03A9@209.120.198.3 CSeq: 2 BYE User-Agent: Cisco ATA v2.15 ata18x (020927a) Also: sip:696969@sip.idv.net;user=phone Requested-By: sip:6526@sip.idv.net Content-Length: 0
Anyway, I don't think that is an issue related to SER -- it is about end-device features.
Maybe not an "issue" with SER, but I guess what I need is a way for SER to get this BYE message, see the Also: and initiate another INVITE to the correct station, handling it like a new call?
- Mike