[Sip-implementors] Call Hold Resume issue , inactive answer after sendonly

Discussion:

Sander Rambags

2014-05-09 07:37:21 UTC

No media stream after putting call on an off hold.

1. Call connected between A and B.
2. A holds the call with a=sendonly.
3. B sends 200 ok with a=inactive
(In many cases this would be a=recvonly, but in some cases / vendors it
is a=inactive)
4. A resumes the call with a=recvonly
5. B sends 200 ok with a=inactive
So no media stream

My question:
A) Is the response in 3. according to RFC3264 ?
B) What must A sent when put call off hold ?
C) Other remarks on this issue ?

Rg
Sander

Vivek Batra

2014-05-09 14:04:24 UTC

Permalink

Yes it's as per RFC.
This is normal behavior which can be seen with most of the practical
deployment where UAS indicates *inactive* (neither capable of sending media
nor receiving in particular state).
In your step 4, why a=recvonly is sent, wouldn't it be a=sendrcv to get back
the held call?

Best Regards,
Vivek Batra

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Sander
Rambags
Sent: Friday, May 09, 2014 1:07 PM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] Call Hold Resume issue , inactive answer after
sendonly

No media stream after putting call on an off hold.

1. Call connected between A and B.
2. A holds the call with a=sendonly.
3. B sends 200 ok with a=inactive
(In many cases this would be a=recvonly, but in some cases / vendors it
is a=inactive) 4. A resumes the call with a=recvonly 5. B sends 200 ok
with a=inactive So no media stream

My question:
A) Is the response in 3. according to RFC3264 ?
B) What must A sent when put call off hold ?
C) Other remarks on this issue ?

Rg
Sander

Paul Kyzivat

2014-05-09 14:42:49 UTC

Permalink

Post by Sander Rambags
No media stream after putting call on an off hold.
1. Call connected between A and B.
2. A holds the call with a=sendonly.
3. B sends 200 ok with a=inactive
(In many cases this would be a=recvonly, but in some cases / vendors it
is a=inactive)
4. A resumes the call with a=recvonly
5. B sends 200 ok with a=inactive
So no media stream
A) Is the response in 3. according to RFC3264 ?

Yes, this is permitted.

Post by Sander Rambags
B) What must A sent when put call off hold ?

A should offer the state that it *wants* to be in. If it's user hasn't
requested hold then it should typically offer sendrecv.

Post by Sander Rambags
C) Other remarks on this issue ?

I don't understand the logic behind B's behavior here. Apparently it
only wants a 2-way conversation or nothing. But while it seems odd it
isn't "wrong".

You should look at RFC6637, especially section 5. It covers this general
subject.

Thanks,
Paul

Sander Rambags

2014-05-12 08:53:45 UTC

Permalink

RFC6637 ??? I don't think that's the one you mean.

Rg Sander

Brett Tate

2014-05-12 14:16:33 UTC

Permalink

Hi,

I assume that Paul intended to indicate RFC6337.

Post by Vivek Batra
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-
implementors-bounces at lists.cs.columbia.edu] On Behalf Of Sander Rambags
Sent: Monday, May 12, 2014 4:54 AM
To: sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Call Hold Resume issue , inactive
answer after sendonly
RFC6637 ??? I don't think that's the one you mean.
Rg Sander
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--
See why you should attend BroadSoft Connections 2014<http://broadsoftconnections.com/>

This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.

Paul Kyzivat

2014-05-12 15:40:47 UTC

Permalink

Post by Brett Tate
Hi,
I assume that Paul intended to indicate RFC6337.

Thanks Brett. Yes, 6337.

Thanks,
Paul

Post by Brett Tate