Thank you for the very quick response Paul!
And I agree that the 5 examples that you listed are correct according to
RFC3264.
The example in RFC4317 Section 3.2 however lists the sequence
0) A offers sendrecv, B answers sendrecv ; media established
1) A offers sendonly, B answers sendrecv <- this is questionable!
As I understand the standards B should only have the options of recvonly or
inactive in case 1 and yet RFC4317 shows otherwise.
So is this an error in RFC4317 or should I expect this condition in my
software?
The answer in 1) suggests that A can receive media which is NOT what was
offered!
The reason this came up is when my phone A is calling my software B I would
expect the following sequence
0) A offers sendrecv, B answers sendrecv ; media established
1) A offers sendonly, B answers recvonly ; pressed hold button on A
(hold)
2) A offers sendrecv, B answers sendrecv ; pressed hold button an A
again (un-hold)
But instead I get
0) A offers sendrecv, B answers sendrecv ; media established
1) A offers sendonly, B answers recvonly ; pressed hold button on A
(hold)
2) A offers sendonly, B answers recvonly ; pressed hold button an A
again (un-hold)
It seems the phone gets "stuck" in the sendonly state once I return
recvonly.
By what you are saying, this is a bug in the phone because in offer 2) it
should offer what it *wants* which in this case is sendrecv not sendonly.
Is this correct?
Thanks again
Bill
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: February 16, 2006 1:46 PM
To: Bill Moats
Cc: [email protected]
Subject: Re: [Sip-implementors] Discrepancy with RFC3264 call hold scenario
andRFC4317
Bill,
There is a set of rules, which you quote, for what may be in an answer
depending on what is in the offer. But that does not constrain what may
be in a subsequent offer relative to the same stream. E.g.:
0) A offers sendrecv, B answers sendrecv
1) A offers sendonly, B answers recvonly
2) B offers inactive, B answers inactive
3) A offers sendrecv, B answers sendonly
4) B offers sendrecv, A answers sendrecv
In (0) a normal call is established. In (1) A puts the call on hold. In
(2) B gets tired of waiting and also puts the call on hold. In (3) A
tries to take the call off hold and finds out he has been held. In (4) B
takes the call off hold so A and B can talk again.
The trick is that each side keeps the state that it *wants* to be in. It
puts that into offers. In answers it puts the min(what it wants, what it
is permitted based on the offer).
Paul
Bill Moats wrote:
Hello all, I have been surfing your SIP forum for quite a while and
have found it extremely useful. I hope that you can shed some light on
my current call hold problem. I have been implementing a SIP protocol
stack using SDP and have run into problems when dealing with a phone
going on hold.
RFC3264 Section 6.1 says:
"If a stream is offered as sendonly, the corresponding stream MUST be
marked as recvonly or inactive in the answer."
RFC3264 Section 8.4 also says:
"If the stream to be placed on hold was previously a sendrecv media
stream
it is placed on hold by marking it as sendonly. If the stream to be placed
on hold was previously a recvonly media stream, it is placed on hold by
marking it inactive.
This means that a stream is placed "on hold" separately in each
direction. Each stream is placed "on hold" independently. The
recipient of an offer for a stream on-hold SHOULD NOT automatically
return an answer with the corresponding stream on hold. An SDP with
all streams "on hold" is referred to as held SDP."
In my mind, it seems to me that RFC3264 is very clear on how to deal
with ANY offer that is marked a=sendonly. You can 1)set the port to 0
to reject the offer 2) respond with a=recvonly
3) respond with a=inactive.
You certainly can NOT respond to a sendonly stream with sendrecv!!!
However, if my software responds to a=sendonly with a=recvonly the
phone I have will only continue to offer a=sendonly from that point
on. But then I read RFC4317 Section 3.2 which lists an example in
which an offer a=sendonly is responded to with no direction attribute
(which implies sendrecv!). The section of interest is below:
[Second-Offer]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=sendonly
m=audio 49174 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=recvonly
[Second-Answer]
v=0
o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
m=audio 49172 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=sendonly
Is this not a violation of the statement from RFC3264 Section 8.4!!!!
Or is there some other mechanism to define why this happens? Is this
possibly an error in RFC4317? Is the phone I am using non-compliant?
Any assistance or advice you could give on the subject would be
greatly appreciated!
Thanks in advance
Bill
_______________________________________________
Sip-implementors mailing list [email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
