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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
