On 10/1/15 8:56 AM, Sabyasachi Samal wrote:
Hi Guys,
I am having a basic query related to SIP flow.
1. Suppose two users are in a SIP call and RTP is continuing.
2. The called party swithed off abnormally.
What will be the flow after that?
Whether the RTP continues to send few times and then calling party will
send the BYE or CANCEL?
Please suggest.
I suppose it depends on how the change is detected.
Do you mean that the called party device is powered down without any
opportunity to take any cleanup actions?
If so, then I would expect some or all of the following:
- calling device continues sending media, at least for awhile.
- the RTP packets can't be delivered.
- ICMP messages will probably be sent back toward calling device
- if the ICMP messages are received, some recovery actions may begin
- the calling device won't be receiving any RTP. It will perhaps
consider this a temporary error condition
- if RTCP was in use, the lack of RTCP messages from the called device
will eventually be noted. After long enough the media stream will
be closed.
- the calling user will probably notice he is hearing no audio and
begin to think something is wrong. After awhile he may hang up.
- once the calling UA realizes something is possibly wrong, it
could decide to test the sip signaling channel via an UPDATE or
reinvite. Or it might be tested anyway due to a session timer.
- sent sip signaling won't be acknowledged. The requests will
timeout. They will be retried, but eventually will be abandoned.
- after a timeout of signaling the calling UA should eventually
send a BYE. It will also fail. After being retried without success
the dialog will be abandoned.
The calling UA could have a policy to drop the call sooner, after one or
more of the above events.
Thanks,
Paul
On Wed, Sep 23, 2015 at 7:23 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
One more thing...
On 9/23/15 3:23 AM, Eize Slange wrote:
To answer your questions/comments with respect to my given scenario:
- I also think that the first INVITE isn't lost but already
being processed inside the SIP-stack. This because it's
a lab network and so lost packet is rare...
If this is also in code under your control then you might want to
investigate if there is a bug in it, that is causing it to forget
the reinvite when it gets the update.
It would be interesting to know if the 500 is being returned as a
result of processing the 1st reinvite or the retransmission of it.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Regards,
Sabyasachi
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
