On Feb 23, 2009 11:34am, "M. Ranganathan" <[email protected]> wrote:
Chaitra wrote:
M. Ranganathan wrote:
Dale Worley wrote:
On Fri, 2009-02-20 at 15:46 +0530, Chaitra wrote:
This is regarding call forwarding an Inbound call from an ITSP to an SCS
user or PSTN numbers.
Consider the following scenario:
Inbound call made using bandwidth.com terminates on user 200 in SCS who
has set a call forwarding (if no response) forward to another PSTN number
(ring for 30 seconds)
Default serial fork expiration = 20
Are we sure that a 1xx response has been sent to the ISP within 32
seconds?
According to the flowchart on page 128 of RFC 3261, the callee has
"Timer B" time to send a 1xx response or the caller can consider the
call timed-out. According to the table on page 265, the default Timer B
value is 32 seconds.
Dale
It has been sent. However, if it never gets to the ITSP that could be
problematic. SipXbridge will not forward 100 but will generate one when
the inbound INVITE is consumed. A wireshark trace will tell the story.
Ranga
This issue is also reproducible if the inbound call is forwarded to an
internal extension for example,
Inbound call terminates on user 200 in SCS who has set a call forwarding
(if no response) to 202 in SCS (ring for 30 seconds)
Current Behavior:
Do not answer the call from 200 -->After 20 seconds the call is forwarded
to user 202 and 202 starts ringing.
Do not answer the call from 202 -->After around 10 seconds the call gets
disconnected.
A look into the logs,
In Frame 16 in the attached merged.xml, the INVITE from the outside
caller is sent to 200. In frame 25, sipXbridge sends the 180 ringing
response from user 200, out to the ITSP. In frame 29 proxy sends a CANCEL
to user 200 (ie after its 20 second limit).
In frame 44, an INVITE is sent to the forwarding destination 202. In
frame 52, 180 ringing response from 202 is sent out to the ITSP. In frame
56, the ITSP (216.82.224.202) sends a CANCEL before the forwarding
completes.
We have verified that the 180 ringing response from the users 200 and 202
are actually sent out of our router to 216.82.224.202
I have attached the wireshark traces taken on our SUT as well as on the
router.
The Attachments.zip file contains,
-merged.xml
-bandwidth_fwd_capture_taken_on_the_SUT.pcap
-bandwidth_fwd_capture_taken_on_RouterLevel.pcap
Thanks,
Chaitra
Chaitra,
(re posted to the list)
Chaitra,
Thanks for gathering the trace!
I concur that the 1xx responses ( including 100 ) are sent to the ITSP. I
dont see that sipxbridge is doing anything obviously wrong to cause the
ITSP to drop the call in 32 seconds.
I request independent review of the wireshark traces if any SIP Expert here
has the time to look.
Ranga
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
